When an integration breaks, the conversation that follows is predictable. Finance says the data that arrived was wrong. IT says the data left their system correctly. The vendor says their API is working as documented. The implementation partner says they built what they were asked to build.

Everyone is telling the truth. And the problem still isn't fixed.

What lives in the gap

Modern finance operations run across a landscape of systems that were never designed to talk to each other: an ERP, a procurement platform, an AP automation tool, a banking connector, a reporting layer. Each was chosen to solve a specific problem. None of them were chosen with the others in mind.

The integrations between them were built later, by different people, under different assumptions, with different levels of documentation. Some were built by vendors. Some by implementation partners. Some by internal IT. Some by a consultant who left two years ago.

The gap isn't a place on an org chart. It's the space between all of those systems and all of those owners — and when something goes wrong in that space, it belongs to everyone and no one.

How the cost accumulates

The most visible cost is the fix itself: the hours spent diagnosing, the emergency escalation, the late close. But the visible cost is usually the smallest part.

The larger cost is what happens before anyone declares a problem:

  • The manual patches that appear around integration failures. Someone in AP who re-keys records that didn't transfer. A finance analyst who maintains a spreadsheet to reconcile two systems that should agree automatically. An IT admin who runs a weekly script to catch records the integration dropped.

  • The decisions made on bad data. If an integration is silently dropping or misrouting records, the reports downstream reflect that. Forecasts are off. Accruals are wrong. Variance analyses point in the wrong direction. These costs don't show up in an incident ticket.

  • The risk carried by the people who know. When integration reliability depends on one or two people who understand the quirks, the risk isn't just operational — it's personal. Those people know that something fragile is running, and they carry the anxiety of it.

Why the gap persists

The gap persists because fixing it doesn't fit cleanly into anyone's scope. It requires someone who understands the finance process well enough to know what the data should look like, the technical architecture well enough to understand where it's going wrong, and the vendor landscape well enough to know what's actually possible.

Most organizations have people who can do one of those things. Very few have people who can do all three — and who are also accountable for the outcome rather than just the deliverable.

Closing the gap

Closing the gap doesn't always mean a large project. In many cases, the first step is simply understanding what's actually moving between systems: what was sent, what arrived, what the integration thinks happened, and what the downstream systems recorded.

That audit frequently reveals that the gap is smaller and more specific than it looked — a handful of failure modes, a few mapping errors, a monitoring gap that lets problems go unnoticed. Fixing those, and putting someone accountable for the landscape in place, closes most of the real exposure.

The more expensive version is waiting until the gap becomes visible. At that point, the cost is no longer just fixing the integration — it's also reconstructing what the correct state should have been.