The order confirmation email said the item would ship in two days. The warehouse had none, because the stock figure the storefront was working from had been exported from the ERP overnight and the last three units had been sold to a trade customer at nine that morning. By the time anyone noticed, forty-two customers had bought a product that did not exist. This is the failure mode that made e-commerce and ERP integration a board-level concern around 2013. Online sales had crossed the threshold from marketing experiment to material revenue channel, and the batch integration that was adequate when the web store shipped twelve orders a week became the single most visible source of customer complaints when it shipped twelve hundred.
The Architecture That Broke
Most e-commerce platforms of that era were implemented by marketing or a digital agency, not by IT, and they were connected to the back office the way any two systems get connected when nobody owns the boundary: with a nightly file. The pattern was nearly universal. Overnight, the ERP exported a product and stock file. The storefront imported it. Through the day, the storefront collected orders. Overnight, it exported them. The ERP imported them the following morning. Everything worked, in the sense that data eventually arrived where it needed to be. The problems were all in the gap. Stock was wrong all day, by design. The storefront was showing a figure that was accurate at 2am. Every sale through any other channel — trade, retail, telephone, branch — made it less accurate. Overselling was not a bug in the integration; it was the expected behaviour of the architecture. Order status was unanswerable. A customer who called at eleven in the morning about an order placed at ten was asking about an order the ERP had never heard of. The service agent could see it in the storefront admin but not in the system that actually fulfilled anything. Pricing diverged. A price change made in the ERP reached the website the next morning. Promotions set up in the storefront were invisible to the ERP, which meant invoices sometimes disagreed with what the customer had been charged, and margin reporting was wrong in ways that took a month-end to surface. Failures were silent. A malformed record would cause the import to reject a batch, and because nobody was monitoring a nightly job that had run fine for two years, the discovery mechanism was a customer complaint or a gap in the sales ledger. And returns were nobody's process. The storefront could accept a return request. The ERP handled credit notes, stock receipt and refunds. Between the two sat an entirely manual reconciliation that scaled linearly with volume and was the first thing to break under load.
Why It Was Harder Than It Looked
The instinct was to replace the nightly file with real-time API calls and declare the problem solved. Organizations that tried this discovered several genuine difficulties. Real-time stock is a business question, not a technical one. Exposing the ERP's on-hand quantity live to a public website means every page view hits the transaction system, and it means a single physical unit can be committed to two customers in the same second. The real answer is an available-to-promise calculation with reserved quantities and channel-level buffers — which requires deciding, commercially, how much stock each channel is allowed to see and who loses when there is contention. That decision usually had no owner. The ERP was not built for this transaction profile. Systems designed around a few thousand order lines a day from internal users behaved badly when asked to accept continuous small transactions from an external system, particularly during a promotion. Integrating tightly often surfaced performance limits that had never been tested. Product data lived in the wrong place. The ERP held the SKU, cost and stock. The storefront held the description, images, category, specifications and SEO metadata. Neither was a complete product record, and every attempt to designate one as master ran into the fact that each held attributes the other could not represent. Customer identity forked immediately. Web customers registered with an email address. ERP customers existed as accounts with credit terms and a customer number. The same business buying through both channels became two customers, which broke credit control, pricing and any attempt at a single view of the relationship. And tax, in a multi-jurisdiction business, is not a lookup. Sales tax, VAT, place-of-supply rules and B2B versus B2C treatment differ by destination and customer type. Reimplementing that logic in the storefront guaranteed divergence from the ERP; calling the ERP for every basket introduced a dependency on the slowest part of the stack at the most sensitive moment in the transaction.
What Good Integration Looked Like
The organizations that solved this, then and now, converged on a small number of principles. Designate a system of record per data domain, explicitly. Stock, price and customer credit from the ERP. Content, merchandising and browsing behaviour from the commerce platform. Order as a shared object with a defined handover point. Written down, agreed by the business, and enforced in the integration. Push events rather than polling files. Stock movements, price changes and order placements are events. Publishing them as they happen removes the window in which the two systems disagree. Where real-time was genuinely impossible, frequent incremental syncs with change detection were an acceptable intermediate step; nightly full-file replacement was not. Put a middleware layer between the two. Direct point-to-point integration between a commerce platform and an ERP couples two systems with completely different release cadences. An integration layer that owns mapping, transformation, retry and error handling is the difference between a platform upgrade being a weekend and being a quarter. Design for failure explicitly. Queue orders that cannot be posted rather than losing them. Retry with backoff. Alert a human when the queue grows. Reconcile counts daily between systems. The question is not whether the integration will fail but whether anyone will find out before a customer does. Use available-to-promise, not on-hand. Physical stock minus allocated minus a channel buffer, recalculated on movement. This is the single change that eliminates most overselling. Reconcile daily and automatically. Orders in the storefront versus orders in the ERP. Stock in each. Revenue in each. A daily automated comparison catches the silent failures that would otherwise surface at month-end.
Agree authority
Name the system of record for each domain and the order handover point.
Reserve by channel
Agree allocations and buffers rather than publishing raw on-hand stock.
Handle failure
Queue failed postings, retry safely and alert an owner.
Reconcile the lifecycle
Compare orders and balances and own returns end to end.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Commerce and ERP Integration
- Decide the system of record per data domain before writing any code. Most integration failures are governance failures wearing a technical costume.
- Move from on-hand quantity to available-to-promise with channel buffers. This requires a commercial decision about who gets the last unit, and someone has to make it.
- Treat stock, price and order as events, not as nightly files. Every hour of staleness is an hour in which the storefront is lying to customers.
- Insert an integration layer rather than coupling the platforms directly. It will save you on the first upgrade of either system.
- Build monitoring and alerting into the integration on day one. A silent nightly job that has worked for two years is a pending incident.
- Solve customer identity deliberately. Web registrations and ERP account numbers must resolve to one customer, or credit control and pricing will not work.
- Own the returns process end to end. Returns are where manual workarounds accumulate fastest and where they are least visible.
- Load test at promotional volume, not average volume. The integration will fail on your biggest sales day or not at all.
The Regional Dimension
In the Gulf, e-commerce integration carries requirements that generic implementations tend to miss, and the gaps are expensive. Cash on delivery changes the order lifecycle. Where a meaningful share of orders is paid on delivery, the payment event happens days after the order and outside the payment gateway entirely. Integration designed around card authorisation at checkout does not handle this. Cash reconciliation from courier remittances back to individual orders in the ERP is a real and frequently manual process, and failed-delivery rates on COD orders mean stock must be returned to inventory correctly or the picture drifts within weeks. E-invoicing is now part of the order flow. Under ZATCA requirements in Saudi Arabia, an invoice generated by an online sale needs to be produced in the required structured format with cryptographic stamping and, for the relevant category, cleared before it reaches the buyer. That makes invoice generation a synchronous, regulated step rather than a downstream batch job. Organizations that implemented commerce integration before this obligation existed have generally had to rework the invoicing path rather than extend it. Bilingual product data doubles the master data problem. Product names, descriptions and specifications in Arabic and English must both exist, both stay current, and both map to a single SKU. Where the ERP holds only the English description and the storefront holds both, the ERP is not the product master in any meaningful sense — and the mismatch surfaces on invoices, delivery notes and customer communications. Multi-entity groups face a routing decision. A group selling into the UAE, Saudi Arabia and Qatar through one storefront must route each order to the correct legal entity for invoicing, VAT treatment and revenue recognition. That logic belongs in the integration layer with explicit rules, not in a storefront configuration that nobody in finance can read.
The Same Problem, New Channels
The architecture question has not changed; the number of endpoints has. Marketplaces, social commerce, mobile applications, in-store systems and B2B portals are all now order sources, and each one reintroduces the 2013 problem if it is connected point to point. An organization with six sales channels and no integration layer has fifteen potential pairwise integrations and no consistent stock position anywhere. The newer pressure is on data quality rather than plumbing. AI-driven merchandising, demand forecasting and customer service all consume this integrated data, and they fail in a more expensive way than a nightly file did. A model recommending a product that is out of stock, an automated agent confidently quoting a delivery date from a stale availability figure, or a forecast trained on order data that excludes a channel — these are the same synchronisation failures, surfacing with more confidence and at greater scale. Which brings the lesson back to where it started. The integration between commerce and the system of record is not plumbing that IT can quietly own. It encodes commercial decisions about stock allocation, pricing authority, customer identity and who absorbs the loss when two channels want the same unit. Getting the technology right is the easier half.
Common Questions
Why did nightly batch integration stop working for e-commerce?
Because the storefront was displaying stock and price data that was accurate only at the moment of export. As online volume grew and other channels sold the same inventory through the day, overselling, incorrect pricing and unanswerable order-status queries became routine rather than exceptional.
What is available-to-promise and why does it matter here?
It is physical stock minus allocated quantity minus a channel-level buffer, recalculated as movements occur, rather than raw on-hand quantity. Publishing available-to-promise to the storefront is the single most effective change for eliminating overselling, but it requires a commercial decision about how much stock each channel may see.
Should e-commerce and ERP be integrated directly?
Rarely. Direct point-to-point integration couples two systems with very different release cycles and multiplies as channels are added. An integration layer that owns mapping, transformation, retry and error handling keeps platform upgrades from becoming integration projects.
What does cash on delivery change about the integration?
It separates the payment event from the order event by days and moves it outside the payment gateway. The integration has to handle courier remittance reconciliation back to individual orders, and it has to return stock to inventory correctly when a COD delivery fails — otherwise the stock position degrades within weeks.
Commerce Integration Review — Outpace assesses where your channels and your system of record disagree, and designs the integration that stops it costing you orders.