Five ways ERP integrations quietly fail
Duplicate orders, silent failures, synchronous coupling, unmapped edge cases and no reconciliation — the five patterns behind most integration incidents we are called into.
An integration rarely fails loudly on day one. It fails quietly, months later, and someone finds out from a customer. These are the five patterns we see most often when we are brought in to fix one.
1. No idempotency, so retries create duplicates
The classic sequence: the shop posts an order to the ERP, the ERP is slow, the call times out, the shop retries — and the ERP has already created the order. Now there are two. The fix is not a longer timeout. It is an idempotency key: every message carries a unique external reference, the receiver stores it, and a second delivery of the same key returns the original result instead of creating anything.
This one design decision eliminates an entire category of incident, and it has to be there from the start because retrofitting it means reconciling the duplicates already created.
2. Synchronous coupling, so one slow system stalls another
If checkout waits for the ERP to confirm an order, then an ERP maintenance window becomes an outage on your shop. Put a queue between them. The shop writes to the queue and returns immediately; a worker delivers to the ERP with retries and backoff. The customer never sees the ERP’s availability.
The same applies in reverse for stock updates: pushing forty thousand SKU updates synchronously into a web store during business hours will hurt both systems.
3. Failures with nowhere to go
A surprising number of integrations log errors to a file nobody reads. When the ERP starts rejecting orders because a mandatory field changed, nothing tells anyone. Three weeks later, finance notices a gap.
Minimum viable observability: queue depth, error rate and last-successful-sync per flow, on a dashboard, with an alert that routes to a person. If a message exhausts its retries it belongs in a dead-letter queue that someone reviews daily — not in a log line.
4. Mapping that ignores the awkward cases
Field mapping usually gets written from the happy path. Then production produces the rest: partial deliveries, credit notes, orders with mixed VAT rates, customers who exist in the ERP twice, discounts the shop applies per line and the ERP applies per document, returns that arrive before the invoice has been posted.
The cure is dull and effective — take a sample of real historical data including the odd cases, walk it through the mapping with the people from both departments, and write down the rules nobody had documented. It is the cheapest week in the whole project.
5. No reconciliation, so drift accumulates
Even a well-built integration will eventually miss something: a message lost during an infrastructure incident, a record edited directly in one system, a manual correction that never propagated. Without a reconciliation job, that drift accumulates silently.
A nightly comparison — order counts and totals, stock quantities per SKU, invoice status — that either corrects automatically or raises an exception is not glamorous work, and it is what turns "the systems agree" from a hope into a verified fact each morning.
A note on Romanian compliance
If you are integrating in Romania, e-Factura submission through the ANAF SPV deserves the same treatment as any other flow: idempotent submission, stored response, status polling, retries and a visible queue of documents that failed validation. The most common failure we see is treating it as a fire-and-forget upload, then discovering weeks later that a batch was rejected.