The integration debt nobody puts in the ERP business case
Licences, implementation and training all get a line. Integration rarely does — and it is usually where the money goes. Why the cost is invisible early, and how to size it honestly.
Every ERP business case we have reviewed has a line for licences, a line for implementation, and a line for training. Almost none has an honest line for integration — and integration is usually where the money goes.
This is not because people are careless. It is because integration cost is genuinely hard to see at business-case stage, and the structure of a typical procurement actively hides it.
Why the number is invisible early
An ERP business case is built when the estate is described at the level of system names: finance, payroll, CRM, warehouse, the bespoke thing in operations. At that resolution, integration looks like a small number of arrows on a diagram, and a small number of arrows costs very little.
The cost lives one level down, in the questions the diagram does not ask. For each arrow: what entity is moving, at what volume, how often, in which direction, with what identity resolution, under whose definition, and what happens when the far end is down. Each of those questions can turn a single arrow into weeks of work.
The diagram is not wrong. It is just drawn at a resolution where the expensive things are invisible.
Four costs that arrive later
Identity reconciliation. Two systems each have a customer record. They do not agree on what a customer is, they have no shared key, and both contain duplicates created by different rules. Somebody has to define matching logic, decide precedence, and handle the cases where the logic is ambiguous — and that last part is a business decision, not a technical one, so it moves at committee speed.
Definitional drift. Finance's revenue and sales's revenue differ, legitimately, because they are recognised at different moments. When both feed a single ERP, one definition wins and the other team's reports change. The engineering effort is small. The organisational effort is not, and it lands mid-project when people notice their numbers moved.
The bespoke system nobody scoped. Every estate has one — usually built by someone who has left, undocumented, running something operationally critical. It appears in the business case as one arrow. It is frequently the single largest integration item, because before you can integrate it you have to understand it.
Failure behaviour. The happy path is a fraction of the work. What happens when a message fails validation, when a batch half-completes, when the ERP is mid-upgrade, when a downstream system replays a day of events — these determine whether the integration is trustworthy, and they are where the effort concentrates. A pipeline with no failure design is not finished; it is untested.
The shape of the surprise
The pattern we see is not a uniform overrun. It is a specific asymmetry:
| Phase | What the plan assumes | What tends to happen |
|---|---|---|
| Core configuration | The bulk of the effort | Usually broadly on track — the product does what it says |
| Standard integrations | Straightforward, well-understood | Mostly fine, with identity reconciliation as the wildcard |
| The bespoke and the edge cases | A small tail | Absorbs a disproportionate share of the remaining time |
| Failure and reconciliation work | Rarely itemised | Discovered during UAT, when the timeline has no slack left |
The consequence is that projects look healthy for a long time and then stop looking healthy very suddenly, because the difficult work was scheduled last and the easy work was scheduled first. That sequencing is natural — you configure before you integrate — but it means the risk profile is back-loaded while the confidence profile is front-loaded.
What to do at business-case stage
You cannot cost integration precisely before discovery. You can, however, avoid pretending the number is small.
Inventory at the entity level, not the system level. List the entities that must cross a boundary — customer, product, order, invoice, employee, cost centre — and for each, name the system of record. Disagreements about the system of record are the future integration cost, visible early.
Rank by identity difficulty, not by volume. The expensive integrations are the ones where records must be matched without a shared key. A high-volume feed with a clean key is cheap. A low-volume feed requiring fuzzy matching against duplicated history is not.
Put a real number on the bespoke system. If nobody can explain how it works, the honest estimate is a discovery spike, not a figure. Budget the spike explicitly and re-plan after it.
Budget failure design as a line item. Retry, replay, reconciliation and alerting are not polish. Sizing them at zero guarantees they are built under time pressure at the end.
Sequence one hard integration early. Deliberately pull the nastiest integration forward into the first delivery phase. It is uncomfortable and it is the single most useful thing you can do, because it converts your largest unknown into a known while the schedule still has room to absorb the answer.
The buy-versus-build framing is usually wrong
Teams often present this as a choice between buying a product and building a platform, with integration treated as a cost of the buy option. In practice both options carry it. A bespoke platform still has to talk to the payroll system and the bank.
The real difference is where the constraint sits. A product imposes its data model on you, and integration cost is the price of reconciling your reality with that model. A custom build lets you fit your reality, and the cost moves into the things a product would have given you free — permissions, audit, reporting, upgrade paths.
Neither is cheaper in general. The useful question is which set of constraints you would rather live with for the next decade, given how unusual your processes genuinely are. Most organisations believe they are more unusual than they are; a minority are genuinely unusual and are badly served by being told to standardise.
Questions that expose the real number
Vendors are not usually being evasive about integration cost. They genuinely do not know it either, because it depends on the state of your estate. But the questions you ask determine how much of the uncertainty surfaces before signature rather than after.
"Show me the API response for one of our actual records." Not the documentation, not a sample. A real call against a real record, ideally during the evaluation. The gap between documented and actual behaviour is where a surprising amount of the effort lives.
"What is your identity model for customers, and what happens when two records match on everything except one field?" This is the identity reconciliation question, asked in a form that cannot be answered with a generality.
"Which of these integrations have you built before, and can I speak to that client?" A vendor who has done your exact integration three times is a materially different proposition from one who is confident it will be straightforward.
"What does your product do when a downstream system is unavailable for four hours?" Queue, drop, retry, alert, or fail silently — all are real answers, and only some are acceptable. Silent failure is the one that costs you a month of data reconciliation eighteen months later.
"Who owns the integration after go-live?" If the implementation partner disappears at handover and the product vendor considers integrations out of scope, you own it, and you should staff accordingly.
The purpose of these is not to catch anyone out. It is to move the discovery earlier, where it is cheap. A vendor who answers them well has demonstrated something more useful than a polished demo, and one who cannot answer them has told you where your contingency needs to sit.
How we approach it
Our enterprise platform work starts with the entity-level inventory rather than the system diagram, because that is where the cost is legible. Where integration is the dominant risk, we scope it as its own workstream under integration and APIs rather than folding it into implementation, so that it has a visible budget and cannot quietly absorb contingency meant for something else.
We have delivered this pattern in both directions — bespoke ERP builds where the organisation's processes genuinely warranted it, and advisory work where the honest recommendation was to buy a product and spend the saved money on integration. The case studies cover several of each.