ERP–E-Commerce Integration: Stock and Order Synchronization

Why does ERP–e-commerce integration hurt so often?

Because the two systems live in different worlds: ERP loves consistency and batch processing; e-commerce loves immediacy and always-on. The integration architecture's job is to match these two rhythms without losing data or breaking the customer experience. This article collects proven patterns for stock, price and order flows — and the mistakes made most often.

A requirement map by flow

The order flow: no loss, no duplicates

The most critical line is orders, where two failures are unforgivable: a lost order and a doubly processed one. The answer is a combination of two patterns. Outbox: as the order is written to the e-commerce database, it is also written to an outbox table in the same transaction; a separate publisher reads that table and pushes to the queue — closing the "written to DB but message never sent" gap. Idempotency: the ERP-side consumer treats the order number as a key; if the same message arrives twice it opens no new record and returns the existing result. With these two in place, retries become safe — and safe retries are the integration's insurance policy.

Stock: a delta stream paired with full reconciliation

Two mechanisms must run together for stock. The continuous line: movements in ERP published as deltas/events, with e-commerce updated within minutes. The safety line: at least one daily full reconciliation — comparing both systems' stock views, reporting and correcting the differences. The delta line inevitably drops events (network, ordering, restarts); without reconciliation those drops accumulate and turn into "but it showed in stock" returns. Threshold behavior must also be designed: pausing sales or switching to reservation on the last few units is cheaper than the cost of overselling.

Rhythm mismatch: ERP's window vs the site's 24/7

ERPs have maintenance windows, batch hours and capacity ceilings; e-commerce peaks during a midnight campaign. A middle layer (queue + buffer store) is the shock absorber: the site must not depend synchronously on the ERP; the order queue should accumulate while the ERP is closed and drain at a controlled rate when it opens. The same principle applies in reverse: giant batch updates from ERP are applied gradually (rate limits, chunked processing) so they do not choke the storefront.

Failure management: dead letters, alerts and replay

In integration, failure is an operating condition, not an exception. The minimum set: unprocessable messages land in a dead-letter queue (DLQ); DLQ size is wired to alerts; messages can be inspected with their payloads and safely replayed after a fix. Replay is risk-free when idempotency exists — and catastrophic when it does not; that is why pattern order matters. Correlation identifiers (order number, message id) must be logged end to end, so "where did this order get stuck?" is answerable in minutes.

Contracts and versioning: the integration's long life

Both sides are living systems; they add fields and change types. The integration contract (schema) must be explicitly versioned with a written backward-compatibility rule: adding fields is free, removing or retyping requires a new version. Schema validation must be mandatory on the consumer side; silently parsing wrong is more dangerous than loudly rejecting.

Business impact: integration is the infrastructure of your promise

The "in stock" badge, the delivery date, the order status notification — every promise made to the customer rests on this integration's correctness. Overselling produces returns and reputation cost; lost orders are direct revenue loss; manual fixes grow the operations team. Built on the right patterns, the integration yields measurable wins: reconciliation deltas approaching zero, an empty DLQ, and operational intervention becoming the exception — metrics for both the engineering and the management dashboard.

Frequently asked questions

Real-time or batch synchronization?

Decide per flow: orders and critical stock want near-real-time; prices and master data are healthier as planned batches. There is no single answer; the table is above.

What if the ERP's API is weak?

Strengthen the middle layer: even file/staging-table exchange becomes reliable with queues + idempotency + reconciliation. The patterns are transport-independent.

iPaaS product or custom build?

For a few standard flows, iPaaS buys speed; for complex business rules and high volume, a custom layer returns control. A mix is legitimate too: transport in iPaaS, business rules in your code.

How should sync latency show to the customer?

With honest design: "limited stock" on the last units, an explicit post-order "confirmed" step and status notifications manage latency before it becomes an experience problem.

Integration checklist

1. Freshness needs and patterns tabled per flow

2. Outbox + idempotent consumer on the order line

3. Delta stream + daily full reconciliation running for stock

4. Queue buffer absorbs ERP windows; rate limits defined

5. DLQ, alerting and safe replay in place

6. Correlation IDs logged end to end

7. Schema versioning and compatibility rules written

SSH Yazılım builds ERP–e-commerce integrations on proven patterns with measurable reliability. Let us harden your order and stock lines together.