An apparel brand at $40M ran the exercise on a whim. Software line items first: ERP, WMS, the ecommerce platform, the marketplace tool, the planning app, the returns portal. Then everything that existed only to make those six talk to each other.

The glue was 54% of the total.

Nobody had bought it that way. Each connector was a small yes attached to a bigger yes. The iPaaS subscription came with the ERP project. The custom sync came from a warehouse migration. The two contractors on retainer came from the sync breaking. Every piece was justified. The category never was, because the category never appeared on a single line anywhere.

What counts as glue

Most brands, asked what integration costs, name the iPaaS subscription. That is typically a third of it.

The full list:

Direct platform spend. The iPaaS or ETL subscription, priced on tasks, rows or operations, which means it scales with your volume rather than your value.

Per-connector fees. Premium connectors for the systems that matter — the ERP, the EDI network, NetSuite — are frequently a separate line from the base subscription and frequently the larger one.

Build. Every flow someone specified, built and tested. Usually invisible because it was absorbed into a project budget with a different name.

Maintenance and breakage. The largest line and the one nobody forecasts. APIs version, a field changes type, a partner rotates a credential, a sync silently drops records for nine days.

The human monitor. The person whose morning starts by checking whether the overnight sync ran. Rarely their job title, always their first hour.

Reconciliation. The recurring work of establishing which system is right when two disagree. Month-end inventory reconciliation is glue cost wearing an accounting costume.

Latency cost. Decisions made on data that is fifteen minutes or six hours old. Oversells, double-allocations, and a planning cycle that runs on a snapshot.

Integration cost, $40M brand, six connected systems:

  iPaaS subscription (volume tier)            = $34,000/yr
  Premium connectors (ERP, EDI, WMS)          = $21,600/yr
  Contractor retainer (0.4 FTE equivalent)    = $58,000/yr
  Internal ops time on sync monitoring
    (1 hr/day × 250 days × $52/hr loaded)     = $13,000/yr
  Month-end reconciliation
    (16 hrs × 12 × $58/hr)                    = $11,100/yr
  Amortised build (4 flows over 3 yrs)        = $29,000/yr
  ─────────────────────────────────────────────────
  Annual integration spend                    = $166,700

  Combined license cost of the six systems    = $142,000

The reconciliation and monitoring lines are the ones that never appear in a software budget, because they are paid in salary rather than invoices. They are real money regardless.

Why it grows the way it does

Integration cost does not scale with the number of systems. It scales with the number of pairs that have to agree, which is a different and much worse curve.

Systems	Potential integration points
3	3
4	6
5	10
6	15
8	28

Not every pair gets built, but the ones that matter are the ones connecting the systems that hold overlapping state — and overlapping state is exactly what makes them expensive. Two systems that both believe they know current inventory need continuous reconciliation. Two that share nothing need almost nothing.

That gives you a sharper question than “how many tools do we run”. Ask instead how many systems hold a copy of inventory, and how many hold a copy of the order. Those two numbers predict integration cost better than the tool count does, because that is where the disagreements live.

The failure that costs the most is the quiet one

Loud failures are fine. A sync that errors out gets noticed and fixed by lunchtime.

The expensive failure is partial. A flow that processes 96% of records and silently drops the rest. Inventory that syncs correctly except for one location. A field that started arriving as a string and now writes null without complaint.

These persist for weeks because every dashboard is green. They surface as a symptom in a different department — an oversell, a stockout on something the system said was in stock, a reconciliation that will not close — and by then the causal chain back to the integration is cold. Most brands never attribute the cost correctly, which is precisely why the integration layer keeps getting funded as if it were cheap.

Two habits help more than they should, given how simple they are. Alert on volume anomalies rather than only on errors: a flow that normally moves 4,000 records and moved 3,100 last night has failed even though nothing threw. And run a scheduled three-way check on the state that matters most — usually on-hand inventory — rather than discovering the drift at month end.

When middleware is the right answer

None of this is an argument that integration is bad. Some of it is correct and permanent, and knowing which is which prevents an overcorrection that costs more than the original problem.

Middleware earns its keep in three situations.

Connecting things that should stay separate. Your accounting package, your 3PL’s WMS, a marketplace’s API — these belong to other parties and are not consolidating into anything. A clean, monitored integration is the right answer and always will be.

Absorbing volatility at a boundary you do not control. When a partner changes their API on their schedule, having that churn hit one well-understood layer rather than five direct point-to-point connections is a genuine architectural benefit.

Buying time deliberately. A temporary bridge during a migration is a legitimate use, provided it has an end date that someone owns. The failure is not building the bridge; it is that the bridge outlives the migration by four years because nobody was accountable for removing it.

The distinction that matters is between integration at the edges and integration in the middle. Connecting to a party outside your business is structural. Connecting two systems inside your business that both think they own inventory is a design decision you made and can unmake.

The audit, step by step

The number is worth having even if you change nothing, because it converts an architectural argument into a budget conversation.

1. List the systems. Every piece of software that holds operational state. Not the whole SaaS bill — the systems that know something about products, inventory, orders, customers or money.

2. Mark which hold a copy of inventory, and which hold a copy of an order. These two columns are the ones that generate reconciliation cost. Count them.

3. List every flow between them. Direction, frequency, what it carries, and what breaks downstream if it fails. Most teams discover flows nobody remembers commissioning.

4. Attach the direct costs. Subscription, connector fees, any contractor retainer. These come off invoices and take an hour.

5. Attach the human costs, honestly. Time spent monitoring, time spent on breakage in the last twelve months, time spent on month-end reconciliation. Ask the people who do it rather than estimating, because the estimate is always low.

6. Attach amortised build. What was spent building the current flows, spread over a realistic life.

7. Compare to license spend. The ratio is the finding.

Reading the ratio:

  Glue < 20% of software spend
    → healthy; work is maintenance discipline

  Glue 20-40%
    → watch it; identify the two most expensive pairs

  Glue > 40%
    → architectural, not operational.
      No monitoring improvement fixes this.

Who should own it

The organisational failure underneath the financial one is that integration usually has no owner.

It is not IT’s, because it is operational. It is not operations’, because it is technical. It ends up with whoever built the last flow, which means ownership changes with staffing and documentation degrades with each handover. The person checking the sync each morning is rarely the person who could fix it, and the person who could fix it is often a contractor who bills by the hour and has no incentive to make themselves unnecessary.

Two things help. Name an owner for the integration layer as a system, with the same expectations you would apply to any production service: monitoring, documented flows, a runbook, and a known recovery path. And put the integration cost on one budget line so it is visible as a category, because a cost spread across six line items in four departments is a cost nobody will ever be asked to reduce.

The three real options

Reduce the pairs. Most brands can remove a system without losing capability, usually one adopted to solve a problem that a platform they already own now handles. Each removal takes out more integration cost than license cost, and that ratio is the argument.

Professionalise it. If the architecture is right and the glue is simply unmanaged, treat it as production software: monitoring, alerting, a named owner, documented flows, a runbook. This does not reduce spend, but it converts unpredictable breakage into predictable maintenance, which is worth real money in avoided fire-fighting.

Consolidate the state. The structural fix. Integration cost comes from multiple systems holding copies of the same truth. When inventory, orders, purchasing and EDI live in one system of record, the pairs that needed continuous reconciliation stop existing — not because the sync got better, but because there is nothing to sync.

That is the case for a commerce operating system rather than a stack plus middleware. Endless Commerce holds orders, inventory, purchasing, planning and native EndlessEDI on one source of truth, so the retail partner connection, the multi-location stock position and the order record are the same data rather than three systems reconciling nightly. Integrations to the things that stay separate — a 3PL, an accounting package, a marketplace — remain, because they should. What goes away is the internal glue holding together systems that were only ever apart for historical reasons.

Run the number

You cannot make any of these decisions without the figure, and almost nobody has it.

List every system. Then list, honestly, everything that exists only to connect them — subscriptions, connector fees, contractor time, the hour a day someone spends checking, the month-end reconciliation, the amortised build. Put the total next to your combined license spend.

If glue is over 40% of software, the architecture is the problem rather than the execution, and no amount of better monitoring will fix it. If it is under 20%, you are in reasonable shape and the work is maintenance discipline.

The brand in the opening paragraph was at 54%. They had assumed they had a tooling budget problem. What they had was six systems all convinced they knew the current stock position, and a quarter of a million dollars a year spent helping them argue about it.