Most ERP integration budgets are built the way the vendor presents them: a middleware subscription line, a one-time build line, and a thin ongoing maintenance assumption. In reality, the second and third lines move together, grow with message volume, and are the ones that overrun. Integration costs are frequently called the least predictable line in an SAP program, with 30 to 50 percent overruns common, and the mechanics are similar on Oracle Fusion.
What follows is a 2026 teardown of the three cost layers a controller actually signs for when integrating against SAP S/4HANA or Oracle Fusion: iPaaS subscriptions, custom API build and run, and the ongoing data synchronization that nobody prices on day one. The figures below are the ones that belong in a board paper when the question is whether to keep integrating against a legacy ledger or replace it.
The Three Layers Hiding in One Integration Line
An ERP integration is three different purchases bundled under one project name. The first is middleware: SAP Integration Suite or Oracle Integration Cloud, sold on consumption. The second is build: the custom APIs, iFlows, adapters and transformations your team or systems integrator writes on top of that middleware. The third is run: the ongoing cost of keeping those integrations in sync as master data drifts, schemas change and new entities get added.
Each layer has a different cost driver. Middleware scales with message volume. Build scales with the number of distinct systems and the depth of the field mapping. Run scales with how often either side of the sync changes. Treating them as a single number is how finance signs off on an integration budget that triples by year two. The pattern repeats across every major platform, and we have covered the ownership question in more depth in two-way sync ownership.
Layer One: SAP Integration Suite and Oracle OIC in 2026
SAP Integration Suite is priced on a messages-per-month basis for its Cloud Integration capability. SAP sells message volumes in annual tiers, with per-thousand pricing decreasing as committed volume increases. Published figures range widely; one commonly cited band is a fraction of a cent to a few cents per message depending on tier and contract vintage. The move from the older connections model to the messages model has produced cost increases of 20 to 60 percent for high-volume estates.
Two mechanics make the headline rate deceptive. A message is any outgoing packet from an integration flow, so a splitter step that fans out a hundred records counts as a hundred messages, not one. And a payload larger than 250 KB is sliced: a 1 MB document is charged as roughly five messages. Order volumes, EDI documents and master-data syncs multiply fast.
Oracle Integration Cloud bills differently and worse for intermittent workloads. OIC uses a message-pack-per-hour model where one pack covers 5,000 messages per hour on a new license, or 20,000 per hour under BYOL. The instance is billed 24 hours a day from provisioning, so an idle OIC instance accrues a minimum of one pack per hour whether anything runs or not. A minimum Enterprise configuration with one message pack and no disaster recovery was modeled at about $11,304 per year before a single message is processed.
For a sense of what message volume turns into on an invoice, OIC Standard runs approximately $0.6246 per message in 5,000-pack terms and OIC Enterprise roughly double that. A typical entry-level deployment at 125,000 messages per month lands around $2,500 to $3,500 monthly on Standard and $5,000 to $7,000 on Enterprise, with Enterprise required for the B2B, EDI and SAP adapters many finance workflows depend on.
Layer Two: What a Custom API Build Actually Costs
Middleware moves bytes; it does not know what your general ledger means. The build layer is the per-system work that turns a message into a journal entry: the field mapping, the chart-of-accounts crosswalk, the duplicate detection, the retry logic, the idempotency keys that keep an AR cash application from double-posting on replay.
Public industry estimates for per-integration development run $50,000 to $100,000 per system connection, inclusive of platform licensing allocated to that build. Labor is the dominant input. US-posted rates for SAP S/4HANA contractors cluster between $55 and $90 per hour, with BTP and integration architects running $100 to $150, and integrator bill rates on large transformation programs reaching $175 to $300. Oracle Fusion partner rates sit in a similar band, with partners and global SIs charging $200 to $350 per hour.
Three design choices move the build number more than the hourly rate does. First, how clean the chart of accounts is on the receiving side (we have written about why a chart of accounts migration is not a copy job). Second, how many custom fields each side added before the project started, which turn each mapping into a conditional. Third, whether the integration is one-way or two-way. A two-way sync at least doubles the mapping work and introduces conflict resolution rules that have to be owned by a human on at least one side.
| Integration type | Build (high) | Maint/yr (high) | 3-yr TCO (high) |
|---|---|---|---|
| ERP-to-SaaS (NetSuite, Dynamics) | 120 | 40 | 200 |
| SAP S/4HANA (single) | 200 | 60 | 320 |
| Oracle ERP Cloud | 180 | 55 | 290 |
| Multi-ERP (SAP + NetSuite + CRM) | 500 | 150 | 800 |
| Enterprise program (10+ systems) | 1200 | 350 | 1900 |
Layer Three: The Ongoing Synchronization Line Nobody Prices
The line that gets cut from the business case is the one that actually determines total cost of ownership. Keeping data synchronization live after go-live covers schema drift when either vendor pushes an update, re-mapping when a new entity or legal structure is added, exception handling when a sync fails midway, and the reconciliation work that proves the two systems still agree at month end.
Industry breakdowns put ongoing integration maintenance at $75,000 to $150,000 annually for a mid-market Oracle Fusion footprint, before any new build. On the SAP side, cumulative hidden costs commonly include $50,000 to $200,000 annually in cloud consumption overages for storage and message processing beyond the base allocation, and $10,000 to $250,000 per modification when a scope item slips into customization. The ranges are wide because the drivers are internal, not vendor-set.
There is a secondary ongoing cost that rarely appears on the integration line but is caused by it: the manual reconciliation work the finance team absorbs when the two systems disagree. If the AR agent in a downstream system commits a cash application the ERP has not yet seen, somebody opens a ticket. The AP side is worse. Approval thresholds, duplicate invoice checks and three-way match all have to be enforced by whichever system owns the control, and the handoff is where exceptions live. We have covered the mechanics in AP agent approval thresholds.
What the Three Layers Add Up To at Scale
Stacked up, the three layers put the integration portion of an SAP S/4HANA or Oracle Fusion program well into six figures annually for a mid-market deployment, and seven figures for a global one. At the implementation level, a core Finance-only Oracle Fusion deployment typically runs $400,000 to $800,000 in partner services, with Finance plus SCM reaching $800,000 to $1.5 million. SAP tends to run higher at every scale.
Those are implementation totals, not integration-only, but the integration share within them is the fastest-growing component because it compounds. Every new acquired entity, every new sales channel, every billing-model change touches the integration layer first. This is also where legacy ERP economics starts to shift against the incumbent — a point we have analyzed separately in the true cost of keeping your legacy ERP alive.
How to Pressure-Test an Integration Line Before Signing
Three questions change the number materially. First, what is the committed message volume and what is the overage rate above it? SAP overages run three to five times the contracted per-message rate, and buyers routinely underestimate volume by 40 to 60 percent. The right answer is a bottom-up volume model built on actual transaction counts, payload sizes and splitter behavior, not a vendor sizing worksheet.
Second, who owns the field mapping when both systems change? Put the two-way sync ownership decision on paper before the SOW is signed, and name the human who decides when a schema change gets propagated.
Third, what is the ongoing run-rate assumption and what does it cover? If the integration maintenance line is below $75,000 for a non-trivial footprint, it has been priced optimistically or the scope excludes the work that will actually appear. The erp.io platform is architected to collapse these three layers into a single governed surface, with the ledger kept deterministic and the agents reading from it rather than through brittle middleware. For teams weighing whether to keep integrating or replace, migration with reconciliation proof is designed to give controllers the daily evidence a board paper needs.
What Belongs in the Board Paper
A defensible integration budget for SAP S/4HANA or Oracle Fusion in 2026 should carry three separate numbers, not one. Middleware subscription with a modeled message volume and a stated overage rate. Build cost per connected system, with the per-system figure justified by the number of fields mapped and the direction of the sync. And an ongoing synchronization line sized to the drift rate of both systems, not to a vendor template. If any of those three lines looks too clean, it is probably the one that will overrun first.
The deeper question is whether that integration spend is buying leverage or just preserving the status quo. A controller signing a three-year middleware commitment to keep an aging ledger integrated with newer systems is paying to defer a decision, not to make one. The teardown above is meant to make the deferred cost legible so the comparison with the alternative — a single platform where the integration layer does not exist as a line item — can be made on real numbers.