ERP Integrations: An Architecture Playbook for 2026

ERP integrations almost never fail at go-live. Go-live has a war room, a rollback plan and everybody's attention. They fail in month eighteen, when the consultant who wrote the mapping has moved on, a supplier changes a field format, and an order flows through with a silently wrong tax code for six weeks before finance catches it in a reconciliation.

That delay between breakage and detection is the defining characteristic of this work. Unlike a web application, where a failure is loud and immediate, a broken integration often keeps running. It produces records. They are just wrong. By the time anyone notices, the bad data has propagated into three downstream systems and a quarter of reporting.

This playbook is for the architects and engineering leaders who have to design something that survives that eighteenth month. It covers the four patterns that actually exist, the canonical-model question you cannot dodge, the unglamorous reliability work that separates a robust integration from a fragile one, and an honest assessment of where AI genuinely changes the economics — which is a narrower band than vendors suggest, but a real one.

Why ERP Integrations Fail in Year Two, Not Year One

Three forces compound over time. The first is undocumented business logic. Every integration accumulates special cases — this customer's invoices need a different rounding rule, that region's orders skip a validation step — and each one is implemented under deadline pressure by someone who intends to document it later. Two years on, nobody can distinguish deliberate logic from an accident, so nobody dares change anything.

The second is schema drift on both sides. Your ERP gets patched, a SaaS system you integrate with deprecates a field, a third party changes an enumeration value. These changes are announced, usually in a release note nobody on your team reads, and they rarely break the integration loudly. They break it quietly, mapping an unrecognised value to a default.

The third is the accumulation of point-to-point connections. What starts as ERP-to-CRM becomes ERP-to-CRM, ERP-to-warehouse, ERP-to-billing, CRM-to-billing, warehouse-to-billing — and each new system multiplies the connection count rather than adding to it. At around six systems the topology becomes genuinely unmappable, and the honest answer to "what happens if we change this field?" becomes "nobody knows."

The designs that survive share one property: they make failure loud. Reconciliation runs that compare record counts and key totals across systems on a schedule, alerting on divergence rather than waiting for finance to find it. This is unglamorous and it is the single highest-return investment in the entire programme.

The Four Integration Patterns and When Each Is Right

Vendor material presents a dozen options. Architecturally there are four, and most real estates use two or three in combination.

• Point-to-point — direct connections between system pairs. Fastest to build, worst to operate at scale. Appropriate for a genuinely small, stable estate that will not grow.
• Hub-and-spoke via an integration platform (iPaaS) — every system connects to a central broker that handles routing, transformation and retries. The default choice for mid-sized estates.
• Event-driven — systems publish domain events to a log; consumers subscribe. Best decoupling, highest design discipline required, and the strongest fit when you need an auditable history of what changed and when.
• Batch file exchange — scheduled extracts, transfers and loads. Dated, still correct for high-volume periodic movements such as nightly financial postings where real-time adds cost and no value.

The mistake is treating these as a maturity ladder where event-driven is the destination. Nightly general-ledger postings do not benefit from an event stream. A real-time inventory check does not belong in a batch file. Pick per data flow, not per programme.

Point-to-Point: Fast, Cheap, and a Trap

Point-to-point is where nearly every estate starts, and there is nothing wrong with that. Two systems, one connection, a week of work, a clear owner. The trap is that each individual decision to add one more direct connection is locally rational and globally catastrophic.

The arithmetic is unforgiving. Three systems need three connections. Six systems need fifteen. Ten systems need forty-five. Each connection carries its own authentication, error handling, retry logic, field mapping and monitoring, and each is maintained by whoever happened to build it.

The practical warning sign is not the count but the question. When someone asks "if we change the customer ID format, what breaks?" and the answer requires a week of archaeology, you have passed the threshold. At that point the migration to a hub is no longer an architectural preference — it is a prerequisite for changing anything at all.

iPaaS: What You're Really Buying

An integration platform gives you connectors, a transformation engine, retry and dead-letter handling, monitoring, and a visual interface that lets non-engineers see what is running. That last item is more valuable than engineers typically credit, because it moves routine mapping changes off the engineering backlog.

What you are not buying is an understanding of your business logic. The connector handles authentication and the wire format. It does not know that orders from your German subsidiary need a different tax treatment. That logic still has to be written, tested and owned by someone, and it is where the effort actually goes.

Evaluate on three axes. First, connector depth for your specific systems — a connector that covers 60% of an API's surface will force you into custom work for exactly the endpoint you need. Second, the testing story: can you run an integration against a sandbox in CI, or is testing a manual click-through? Third, pricing shape, which is usually per task or per message and therefore scales with transaction volume rather than with value. Model it at three years of projected growth; the platform that is cheapest today is frequently not cheapest at scale.

Event-Driven ERP Integrations

In an event-driven design, the ERP publishes facts — order.created, invoice.posted, inventory.adjusted — to a durable log, and any system that cares subscribes. Adding a consumer requires no change to the producer, which is the entire point.

The operational advantages are substantial. The event log is an audit trail by construction. Replay becomes possible: when a downstream system has been writing bad records for a week, you fix the consumer and replay the window rather than reconstructing state by hand. And a slow consumer no longer blocks a fast producer.

The cost is discipline. Events are a public contract and must be versioned as carefully as an external API. Consumers must be idempotent, because at-least-once delivery means duplicates are guaranteed, not hypothetical. And you now operate a distributed system with the debugging characteristics of one — a single business process spans multiple services and correlating it requires tracing you have to build deliberately.

Many older ERP systems do not emit events natively, which means change-data-capture on the database or polling an API and synthesising events at the edge. Both work. Both add a component that needs an owner, and CDC in particular couples you to an internal schema the vendor may change without notice.

The Canonical Data Model Question

Should every system translate to and from one shared internal representation of a customer, order and product? Or should each integration translate directly between its two endpoints?

A canonical model reduces the number of mappings from N-squared to 2N and gives the organisation a shared vocabulary. Its failure mode is committee paralysis: six months of workshops producing a model so general it fits everything and describes nothing, with every real integration carrying a pile of extension fields to compensate.

The pragmatic middle path works better in practice. Define canonical models only for the three or four entities that genuinely cross more than two systems — usually customer, product, order and invoice. Let everything else map directly. Version the canonical models and require additive-only changes, so a new consumer never forces a rewrite of existing producers.

Keep the canonical model close to your business, not to any one vendor's schema. If your canonical customer is just your ERP's customer table with different field names, you have added a translation layer with none of the benefit, and you will pay for it the day you replace that ERP.

Master Data and the Identity Problem

Underneath every difficult integration is the same question: is this the same customer? Your CRM has "Acme Corp Ltd", your ERP has "ACME CORPORATION LIMITED", and your billing system has both as separate accounts with different addresses. No integration pattern solves this. It is a data governance problem wearing an engineering costume.

The decisions that have to be made explicitly, before any code:

• System of record per entity — exactly one system owns customer master data, one owns product master data, and so on. Write it down. Ambiguity here guarantees conflicting updates.
• Identity strategy — a global identifier issued by the master system and stored as a cross-reference in every other system, rather than matching on name or email at runtime.
• Conflict resolution — when two systems update the same record, whose write wins, and is the loser logged or silently discarded? Silent discards are how data quietly diverges.
• Deletion and retention semantics — a hard delete in one system meeting a soft delete in another is a reliable source of orphaned records and compliance findings.
• Data quality gates — what happens to a record that fails validation? A quarantine queue with a human owner beats both rejecting it silently and letting it through.

Teams that skip this step build technically excellent integrations that faithfully propagate bad data at high speed. The integration is not the problem; it is working exactly as designed.

Where AI Actually Helps ERP Integrations

Start with where it does not. AI does not replace the integration itself. A language model in the hot path of an order flow adds latency, cost and non-determinism to something that must be exactly right every time, and an ERP transaction is precisely the wrong place for a probabilistic component. The value sits either side of the transaction, not inside it.

The first genuine win is field mapping during build. Given two schemas and sample records, a model produces a credible first-pass mapping in minutes — work that historically took an analyst days of reading documentation and comparing sample payloads. It is a draft requiring review, not a finished artefact, but it compresses one of the most tedious phases of the project substantially.

The second is documentation of what already exists. Point a model at an existing integration's transformation code and it will produce readable documentation of what each rule does, which is enormously valuable in exactly the year-two scenario this guide opened with. It will not tell you why the rule exists, but it removes the archaeology from the what.

The third is anomaly detection on the data flowing through. A model trained on normal patterns of volume, value distribution and field population catches the six-week silent failure in six hours. This is where the return is largest, because the cost being avoided is data corruption that has already propagated, and it is far easier to justify than any build-time saving. Teams already investing in enterprise AI development usually find this the cheapest high-value place to start.

AI Agents for Exception Handling and Reconciliation

Every ERP integration generates exceptions: a record that fails validation, an order referencing a product that does not exist downstream, a payment that will not match an invoice. In most organisations these accumulate in a queue that someone works through manually, and the queue is always longer than anyone wants to admit.

This is genuinely good agent territory, because each exception is a bounded investigation with a clear success criterion. An agent can pull the record, query both systems for related data, check against the documented rules, and either propose a resolution with its reasoning or escalate with the context already assembled. The human decides; the agent does the twenty minutes of lookup that preceded the decision.

Two constraints make the difference between useful and dangerous. Keep the agent advisory for anything with financial consequence — it proposes, a human approves, and the approval is logged. And give it read access to the systems it investigates rather than write access, so the worst outcome of a wrong conclusion is a bad suggestion rather than a bad transaction. Estates running this well typically start with one exception category, measure the resolution time before and after, and expand only where the numbers hold. The same design principles apply as in any agentic workflow deployment: narrow scope, human approval gates, and full auditability.

Reconciliation is the adjacent case. Rather than a nightly job that reports a count mismatch, an agent can investigate the mismatch — identify which records differ, classify the cause, and present a summary. That turns a morning of investigation into a five-minute review, and it makes daily reconciliation affordable where it previously was not.

Idempotency, Ordering and the Boring Reliability Work

Every message will be delivered more than once. Not might — will. Networks time out after the receiver has already processed the message, retries fire against successful operations, and replays happen during recovery. If processing the same order twice creates two orders, the integration is broken and you have not noticed yet.

Idempotency is the answer and it means every operation carries a stable key derived from the business event, with the receiver tracking processed keys and discarding repeats. It has to be designed in. Retrofitting idempotency into a running integration means reconciling the duplicates already created, which is considerably more expensive than building it correctly.

Ordering is the second trap. Most queues guarantee ordering only within a partition, so an update can overtake the create it depends on. Either partition by the entity key so all events for one order stay ordered, or make consumers tolerant of out-of-order arrival by carrying a version and ignoring stale updates. Assuming global ordering because it held during testing is a failure waiting for production load.

Then the rest of the unglamorous list: exponential backoff with jitter, dead-letter queues that a named person actually monitors, circuit breakers so a downstream outage does not cascade, and correlation IDs propagated through every hop so a single business transaction can be traced end to end. None of this is interesting. All of it is the difference between an integration that survives and one that gets rewritten.

Batch vs Real Time: Choosing Per Flow

Real-time is not a virtue in itself. It costs more to build, more to operate, and it is harder to reason about. Choose it where the business genuinely acts on the information within minutes.

Inventory availability shown to a customer at checkout is real-time — a stale number costs you an oversell and a refund. Pricing updates are usually near-real-time. Order status that a customer can see should be real-time or close to it, because the alternative is a support call.

General-ledger postings are batch. Nobody makes a decision on a partial day's ledger, month-end close works on complete periods, and batch gives you a natural reconciliation boundary. Payroll is batch. Most analytical extracts are batch. Making these real-time adds operational surface for no decision-making benefit.

A useful test: ask what action a human takes when the number changes, and how quickly. If the honest answer is "they look at it next Tuesday," a nightly batch is the correct engineering decision, and defending it saves real money.

Security, Audit Trails and Segregation of Duties

ERP integrations move financially material data, which puts them squarely in scope for audit. Integration accounts are also frequently the most over-privileged credentials in an organisation, because it was easier to grant broad access during implementation than to enumerate the exact permissions needed.

Scope each integration credential to the specific operations it performs, rotate secrets automatically, and never share one account across integrations — when something goes wrong you need to know which flow did it. Prefer short-lived tokens over static API keys wherever the ERP supports it.

Log every transformation and every write with enough detail to reconstruct what happened: source record, target record, rules applied, acting credential, timestamp. Auditors ask for this, and it is also your own fastest path to a root cause. Retain it for at least as long as your financial retention policy requires.

Segregation of duties is the one that surprises engineering teams. If an integration can both create a vendor and approve a payment to that vendor, you have automated a control violation. Map each integration's permissions against your controls matrix before go-live, not during the audit that finds it.

What ERP Integrations Actually Cost

The proposal covers build. The budget needs to cover build plus a standing operational allocation, because integrations are living infrastructure that degrade without maintenance.

Build cost scales with the number of distinct entity flows and the quality of the APIs on both sides, far more than with the number of systems. A modern REST API with good documentation and a sandbox might be a couple of weeks per flow. A legacy ERP reached through database views and flat files, with no test environment, can be five times that for the same business outcome — and the test environment question is worth asking before you sign anything, because its absence changes the shape of the whole project.

Ongoing cost is the line most often omitted. Expect to spend meaningful engineering time every year on schema changes from both sides, exception handling, performance tuning as volumes grow, and platform upgrades. A reasonable planning figure is 15–25% of the original build effort annually, and the estates that skip this are the ones rewriting everything in year three.

The cost of not doing it well is harder to see and usually larger: manual reconciliation hours, decisions made on stale data, and the occasional expensive incident where wrong data reached a customer or a regulator. If you need a number for a business case, count the hours your finance team currently spends reconciling systems each month.

A Migration Path Off Point-to-Point

Nobody gets to start clean. The realistic question is how to move an existing tangle toward something maintainable without a stop-the-world rewrite.

Start by mapping what exists, including the connections nobody owns. A week spent producing an honest inventory — every flow, its owner, its schedule, its failure mode — is the highest-value week in the programme, and it usually finds two or three integrations still running that everyone assumed were decommissioned.

Then stop the bleeding: mandate that every new integration goes through the hub, with no exceptions for urgency. Without this rule you migrate existing flows while new point-to-point connections appear behind you.

Migrate existing flows by value, not by ease. The flow that breaks most often, or carries the most financially material data, goes first — that is where the return is. Run old and new in parallel with output comparison until you have several weeks of clean matches, then cut over. Parallel running feels slow and is the only way to migrate financial data without a reconciliation crisis.

Accept that some point-to-point connections should stay. A stable, low-volume, well-documented connection between two systems that will never talk to anything else is not worth migrating. Architectural purity is not the goal; maintainability is. For estates where this becomes a larger modernisation programme, it usually sits alongside broader custom software development work rather than standing alone.

How to Evaluate an Integration Partner

Ask what happens in year two. A partner who talks only about delivery and go-live is selling you a project; you need an estate that keeps working. Ask specifically how they handle schema changes from the vendor side, and what their monitoring and reconciliation approach is.

Ask to see a runbook from a previous engagement, redacted. The quality of operational documentation tells you more about how an integration will age than any architecture diagram. Ask how they test — integration tests against sandboxes in CI is the answer you want; "we test in the UAT environment" means manual clicking.

Ask who owns it afterwards. Many programmes deliver competently and leave no internal capability behind, which means every subsequent change is a new statement of work. Agree knowledge transfer as a deliverable with acceptance criteria, not as a goodwill gesture at the end. If you want a second opinion on an architecture or a proposal you have already received, talk to us — we will tell you what we would change and why.

Frequently Asked Questions

What are the main types of ERP integrations?

Four patterns cover essentially every case: point-to-point direct connections, hub-and-spoke through an integration platform (iPaaS), event-driven publish-subscribe over a durable log, and scheduled batch file exchange. Most real estates use two or three together, chosen per data flow rather than per programme — nightly ledger postings suit batch, while inventory availability at checkout needs real-time.

How long does an ERP integration project take?

Duration scales with the number of distinct entity flows and the quality of the APIs on both sides, not with the number of systems. A single flow against a well-documented modern API with a sandbox might take a couple of weeks; the same business outcome against a legacy ERP reached via database views and flat files, with no test environment, can take five times longer. Ask about the test environment before estimating anything.

Should we use an iPaaS platform or build custom integrations?

Use an iPaaS when you have several systems, standard connectors exist for most of them, and you want routine mapping changes off the engineering backlog. Build custom when your transformation logic is genuinely complex, when per-message pricing becomes prohibitive at your volume, or when latency requirements are tighter than the platform can meet. Many estates use both — the platform for standard flows, custom code for the two or three that are unusual.

What is idempotency and why does it matter for ERP integrations?

Idempotency means processing the same message twice produces the same result as processing it once. It matters because duplicate delivery is guaranteed, not hypothetical — networks time out after successful processing, retries fire against operations that already succeeded, and replays happen during recovery. Without it, a retried order message creates a second order. It must be designed in; retrofitting requires reconciling duplicates already created.

Can AI automate ERP integrations end to end?

No, and putting a language model in the transaction path is a bad idea — it adds latency, cost and non-determinism to something that must be exactly right. AI helps meaningfully on either side of the transaction: drafting field mappings during build, documenting existing transformation logic, detecting anomalies in the data flowing through, and investigating exceptions before a human decides. Keep anything with financial consequence advisory, with a logged human approval.

How do we handle master data conflicts between ERP and CRM?

Decide a single system of record per entity and write it down — one system owns customer master data, one owns product, and so on. Issue a global identifier from the master system and store it as a cross-reference everywhere else, rather than matching on name or email at runtime. Define explicitly whose write wins on conflict, and log the losing write rather than discarding it silently, which is how data quietly diverges.

What does ongoing ERP integration maintenance cost?

Plan for roughly 15–25% of the original build effort per year, covering schema changes from both sides, exception handling, performance tuning as volumes grow, and platform upgrades. Estates that budget nothing for this are the ones rewriting everything in year three. For a business case, the comparison figure is the hours your finance team currently spends each month reconciling systems manually.

How do we detect a broken ERP integration before finance does?

Run scheduled reconciliation that compares record counts and key totals across systems and alerts on divergence, rather than waiting for a month-end discrepancy. Add anomaly detection on volume and value distributions to catch the failures that produce records which are present but wrong. Propagate correlation IDs through every hop so a single business transaction can be traced end to end when something does look off.

When should we move from point-to-point to a hub architecture?

When the question "if we change this field, what breaks?" takes a week to answer. The connection count is a rough proxy — three systems need three connections, six need fifteen, ten need forty-five — but the real signal is that nobody can predict the blast radius of a change. At that point migrating is a prerequisite for changing anything, not an architectural preference.