The Dirty Secret of ERP "Integration": Someone Always Reconciles Manually

Every ERP vendor sells you on seamless integration. What they don’t tell you is that someone on your team spends Friday afternoon proving that the number in System A matches the number in System B. That person is the integration. And they’re expensive, exhausted, and one resignation away from a crisis.

There’s a ritual that plays out in finance departments at companies across every industry, every month, without fail. Someone pulls a report from the billing system. Someone else pulls a report from the GL. They compare them. They find the differences. They investigate. They make adjusting entries. They document why the systems disagreed. Then they close the books and start the whole thing again next month.

This ritual has a name: reconciliation. It has a dedicated software category. It generates entire consulting practices. And it exists, almost entirely, because the systems that are supposed to work together don’t actually share a data model. They share data — through APIs and connectors and scheduled sync jobs — but they don’t share a model. The difference is everything.

What integration promises and what it delivers

When a software vendor says their product “integrates with” another product, they mean one of a few things. At the most basic level, they mean their system can import a CSV export from the other system. A step up from that, they mean there’s an API connection that can push or pull records. At the most sophisticated level, they mean a near-real-time bidirectional sync that keeps specific fields aligned between the two systems.

None of these is the same as having one system. And the failure modes are proportional to the gap between what was promised and what exists under the hood.

API-based integrations fail silently. A webhook times out; no one gets an alert; the two systems drift. A field in one system gets renamed in an update; the mapping breaks; records stop syncing. A company updates its customer data in the CRM but the change doesn’t propagate to the billing system because that field wasn’t included in the sync configuration. These aren’t edge cases. According to MuleSoft’s annual Connectivity Benchmark Report, enterprises manage an average of 900 applications, and more than a third of those aren’t integrated at all.¹ Among the ones that are, integration maintenance consumes a significant portion of IT budgets annually.

The reconciliation economy

The reconciliation software market exists because the integration market can’t solve what it’s creating. Tools like BlackLine, FloQast, and Trintech are genuinely useful — they systematize the reconciliation process, reduce the time it takes, and improve audit trails. They’re also a multi-billion-dollar business built on top of a problem that shouldn’t exist in the first place.²

The logic runs like this: because your ERP and your billing system are separate, the accounts receivable balance in one will occasionally disagree with the accounts receivable balance in the other. Because those disagreements are inevitable, you need a process to find them and resolve them. Because that process is complex and error-prone when done manually, you need software to help. So you add another system — a reconciliation system — to manage the disagreements between your other systems. This is not progress. It’s complexity compounding.

A 2022 study by Ventana Research found that 60% of companies still close their books in more than six business days, and the primary cause cited was the time required to reconcile data across disconnected systems.³ The same study found that finance professionals spend an average of 30% of their time on data gathering and reconciliation — time that could otherwise go to analysis, forecasting, and decisions.

The person who holds it together

Every finance team running a fragmented stack has the person. The one who built the reconciliation spreadsheet. The one who knows which numbers to trust and which to verify. The one who gets called when the month-end numbers don’t tie. They are invaluable, irreplaceable in the short term, and a single point of failure for the organization’s financial integrity.

The problem isn’t that this person exists. The problem is that this person’s job — in its entirety — is compensating for the architectural decision to run multiple systems. Their expertise is in understanding the gaps between the systems, not in financial analysis. Their value to the organization is defensive, not generative. And when they leave — which they eventually do — the institutional knowledge of how the systems interact, where the exceptions live, and why certain entries look the way they look walks out the door with them.

This is the integration trap in human form.

What a different model looks like

The alternative isn’t better integration. Better integration is still two systems trying to agree. The alternative is an architecture where the question “does the AR balance in the billing system match the AR balance in the GL?” is structurally impossible to ask — because there’s only one AR balance, derived from one source, governed by one set of rules.

When a transaction posts, it posts once, to one system, and every view of that transaction — whether you’re looking at the subledger, the GL, the report, or the dashboard — is reading from the same underlying record. Reconciliation isn’t a process you run. It’s a property of the architecture.

That’s not a utopian idea. It’s an engineering decision. And it’s one that the industry has largely chosen not to make, because the current model generates recurring revenue from the complexity it creates.

Sources