The integration tax: when your three-vendor stack costs more than your ERP.

ERP doesn’t live alone. Almost no mid-market business runs one and only one operational system, but the cost of connecting them rarely makes it onto the selection scorecard.

The default mid-market stack is ERP plus CRM plus WMS plus EDI plus e-commerce plus BI. Five integration surfaces, sometimes more. Each one is a place where data has to flow, schemas have to match, and somebody has to be responsible when the bridge fails at 2am. The TCO blowout almost always hides here, and almost nobody scores it during selection.

The selection blind spot

ERP selection compares ERPs. Apples to apples on license, services, training, support. The scorecard runs through standard categories: financials, manufacturing, distribution, reporting. The vendor that scores highest wins.

What’s not on the scorecard: the cost of connecting the new ERP to everything else you already run. That cost shows up later, in the second budget cycle, then the third. It’s the line item that nobody owns and everybody has to pay.

Where the cost compounds

Integration cost lives in four places, and each one has its own rhythm of growth.

Custom mappings. One per integration, and the data shapes never quite line up. Your ERP’s customer record has 47 fields. Your CRM’s customer record has 51, of which 31 overlap. Somebody has to write the rules for what flows in which direction, what wins on conflict, and what gets dropped on the floor. Now multiply by every entity. Every pricing tier change and every new field added to either system requires the mapping to be revisited.

Middleware platforms. If you’re running more than two integrations, you’re running a middleware platform whether you intended to or not. iPaaS subscriptions land somewhere between $25,000 and $100,000 per year for a mature platform with the connectors you actually need. Cheaper alternatives exist. They’re cheaper because somebody on your team is doing the work the platform would have done.

Engineering time. The initial build is the visible cost. The perpetual maintenance is the invisible one. Every quarter brings a connector update, an API version change, a partner who added a required field. The engineer who built it leaves, and the documentation was written by someone whose interest in the integration ended at go-live.

Failure ownership. When the bridge fails at 2am, whose pager? The ERP vendor blames the WMS. The WMS blames the integration partner. The integration partner blames a recent ERP change. You spend an hour on a war room call, the order ships late, and the customer notices.

What gets underestimated

Even teams that budget for integration tend to underestimate four specific failure modes.

Schema drift. An EDI partner adds a field to the 850 spec. Your shopping cart adds a promotional code that flows into orders. Suddenly all your maps need updating, and the team that wrote them moved on six months ago.

Throughput surprises. A batch job that worked beautifully at 10,000 records chokes at 50,000. The system that handled morning sync just fine fails at end-of-quarter when volume triples. Most integrations never get tested at peak load until peak load actually arrives.

Idempotency gaps. A retry posts an invoice twice. A duplicate order goes to fulfillment. A status update overwrites a change someone made manually in between. Building integrations that handle retries safely is not hard. Building them by default, before the first incident teaches you why, is rare.

Auth rotations. Someone rotates the API key, the secret, the certificate. They forget to tell the integration team. The bridge stops working at 4pm Friday. The fix is fast. The fact that nobody knew it was going to break is the actual problem.

What to do during selection

None of this is a reason to avoid integrating. You’re going to integrate either way. The question is whether you’re scoring the cost honestly or pretending it doesn’t exist until the invoice arrives.

• Score the integration tax separately. A column on the selection scorecard for every system the new ERP has to talk to, with a real estimate of the build and run cost.
• Demand reference customers running the same surrounding stack. Not just “customers in your industry.” Customers running ERP plus your specific CRM plus your specific WMS. Those references will tell you where the bridges are weakest.
• Get an integration architecture sketch before signing. Not after kickoff. The vendor and the partner should be able to draw the boxes and arrows on a whiteboard, including which side owns each transformation, which side handles retries, and how monitoring works.
• Set a TCO reserve at 30 to 50 percent of license and services. For integration work specifically, separate from the implementation contingency. If you don’t spend it, great. If you do, you knew it was coming.
• Plan for what happens when integration architecture decisions don’t survive contact with reality. See When to walk away from an ERP project.

The walk-away signal

Any ERP demo that doesn’t include the surrounding stack is selling you a unit, not a system. The systems that get evaluated in isolation are the systems that disappoint in production, because production is never an isolated system.

The vendors who can’t talk fluently about your CRM, your WMS, and your EDI partners are the ones who will charge you to learn during your implementation.

The cheapest ERP isn’t the cheapest stack. Score the bridge before the destination.