Why Your ERP Is Not Your Operating System

Executive Summary

The ERP vendor sold you a system of record. What your finance function needs is a system of action. The system of record captures what happened: transactions posted, balances calculated, reports generated. The system of action determines how things happen: who does what, in what order, to what standard, by when, and what happens when something goes wrong.

Every finance function has a system of action. In most organizations, it is informal — built from accumulated habits, email threads, personal relationships, and the institutional knowledge of long-tenured staff. This informal operating system works until it does not: when key people leave, when the company adds entities, when volume doubles, or when the auditors ask “can you show us the process?” and the answer is “Sanjay knows how it works.”

The operating system is the missing layer between what the ERP does and what the finance function needs. Building it is not a technology project. It is a design project — documenting workflows, defining decision rules, and creating the coordination mechanisms that make the function run predictably regardless of who is at the desk.

The Gap Between ERP and Operations

Here is what happens in a typical month-end close. The ERP produces the trial balance. Someone emails the trial balance to the controller. The controller reviews it in a spreadsheet. The controller identifies items that need investigation. The controller assigns investigations via email or WhatsApp. Team members investigate and report back — some via email, some verbally, some by updating a shared sheet. The controller makes adjustments. Someone posts the adjustments to the ERP. The ERP produces the updated trial balance. Repeat until the controller is satisfied.

Notice what the ERP did: produced trial balances and posted adjustments. Notice what the operating system did: everything else. The communication, the assignment, the tracking, the follow-up, the coordination — all happened outside the ERP through informal channels that nobody designed and nobody controls.

This gap exists in every finance function. The size of the gap determines the function’s efficiency, quality, and scalability. A small gap means most coordination happens through structured channels. A large gap means the function runs on informal communication that breaks when people change, volume grows, or complexity increases.

What Currently Fills the Gap

Email: The default coordination tool. Approvals, task assignments, status updates, exception discussions — all buried in inboxes that only the recipient can search. When the recipient leaves, the coordination history leaves with them.

Spreadsheets: The close checklist spreadsheet, the vendor master tracker, the reconciliation status sheet. Each spreadsheet is a process that the ERP cannot handle. Each has a single maintainer who updates it manually.

Chat applications: WhatsApp groups for the finance team, Slack channels for cross-functional coordination. Faster than email but even harder to search, track, and audit.

Tribal knowledge: “Sanjay knows which vendor invoices always need manual adjustment.” “Priya knows the order the close tasks should be done in.” “The CFO knows why that GL account always has a balance.” This knowledge is the most valuable and the most fragile component of the informal operating system.

Three Layers of a Finance Operating System

Layer 1: Process layer. Documented workflows for every recurring activity. Each workflow specifies: trigger (what starts the process), steps (what happens in what order), ownership (who does each step), handoffs (how work moves between people), SLAs (how quickly each step should be completed), and outputs (what the completed process delivers). The ERP handles transactions within each workflow. The process layer connects workflows into an end-to-end system.

Layer 2: Decision layer. Documented decision frameworks for every recurring judgment call. When the team encounters an exception, the decision framework specifies: classification (what type of exception is this), criteria (what factors determine the resolution), authority (who can make this decision), and documentation (what must be recorded). This layer converts key-person-dependent decisions into structured frameworks that qualified team members can follow.

Layer 3: Communication layer. Defined channels for different types of information. Status updates go through the task management system, not email. Exceptions go through the exception log, not WhatsApp. Escalations follow a defined path with time-based triggers. Approvals route through the workflow system with audit trails. Each type of communication has a designated channel, a defined format, and a tracking mechanism.

Building the Operating System

Start with your five highest-volume processes. For each process, document the current workflow (including all the informal steps that happen outside the ERP), identify the gaps between what the ERP handles and what the team handles manually, and design the coordination layer that fills those gaps.

The coordination layer might be a dedicated workflow tool, a project management platform adapted for finance processes, or even well-designed shared documents with clear ownership and update rules. The technology matters less than the design. A well-designed process tracked in a shared document outperforms a poorly designed process tracked in an expensive platform.

Build the operating system incrementally. Start with the month-end close (highest impact, most visible). Then expand to AP processing, then tax compliance, then reporting. Each process you formalize reduces dependence on informal coordination and makes the function more predictable, scalable, and auditable.

The ERP’s Role in the Operating System

The ERP is not the enemy. It is essential — the authoritative source for financial data, the engine for transaction processing, and the foundation for reporting. What it is not: a workflow tool, a communication platform, a task manager, or a decision framework.

In the operating system architecture, the ERP occupies the data layer. The operating system layers (process, decision, communication) sit above it and interact with it. The ERP provides the data. The operating system determines what to do with the data, who does it, and how the work flows from start to finish.

Some modern ERPs include workflow modules that bridge this gap partially. Use them where they work well (approval routing, for example). But do not force the ERP to be the operating system. An ERP forced into operating system duties becomes a customization-heavy, expensive-to-maintain system that does neither job well.

Five Signs Your Function Lacks an Operating System

1. Processes depend on people, not documentation. When someone leaves, their successor spends months learning “how we do things here” through oral tradition rather than documented processes.
2. Exceptions are handled through ad hoc communication. There is no exception log, no classification system, and no defined resolution path. Each exception is a fire drill.
3. The same mistakes recur. Root causes are identified but not systematically addressed. The fix is “be more careful” rather than “change the process.”
4. New team members take months to be productive. Because training is oral rather than documented, and the informal operating system takes months to absorb.
5. The CFO is the central coordinator. Instead of focusing on strategy, the CFO spends significant time on operational coordination — following up on tasks, tracking close progress, resolving bottlenecks — because no system does this automatically.

Continue Reading