How should ecommerce ERP integration actually work?

What is ecommerce ERP integration?

Ecommerce ERP integration connects the online sales channel to the system that runs core operations and finance. ERP means enterprise resource planning. It often owns approved products, purchasing, inventory, sales orders, invoices and accounting. Commerce owns the buying session, cart, checkout and customer-facing experience. The integration keeps the two systems consistent without pretending that both own the same fact.

The design needs more than an order export. Products, prices, customers, stock, orders, payments, fulfilments, cancellations, returns, refunds, invoices, credits and settlements all have a lifecycle. Each flow needs a source, destination, key, trigger, response, retry rule and reconciliation rule.

Which system should own each ecommerce and ERP record?

A system of record is the accepted owner of a fact. Other systems can copy the fact for speed or presentation. They do not silently replace it. The owner depends on the business. A PIM can own product content. An ERP can own item status and cost. Commerce can own navigation and promotions. A WMS can own warehouse execution. Write the decision down field by field when a record has mixed ownership.

What data needs to move between ecommerce and ERP?

Products, categories and content

Map item IDs, SKUs, variants, units, tax classes, weights, dimensions, barcodes, status and sellable dates. Keep rich content separate from operational fields when a PIM or commerce team owns it. Define what happens when an item is disabled in ERP while it remains indexed or sits in a cart. Deleting it from commerce can break order history and search links. Hiding it from new purchase is often safer.

Prices, discounts and tax

Map currency, price list, customer or company, unit, quantity break, tax inclusion and validity dates. Preserve both list price and actual selling price when finance needs to explain a discount. Decide how promotions map to ERP. A cart-level discount can be distributed across lines, sent as a separate adjustment or recalculated. Each option affects tax, returns and revenue reports.

Customers and B2B companies

Separate a person from a legal customer account and delivery location. Map company ID, contact ID, billing account, ship-to account, tax number, currency, price group, terms and credit state. A self-registered buyer can remain pending until sales or finance approves the account. Do not let a new email address create a duplicate ERP customer every time.

Inventory and available-to-promise

On-hand stock is not the same as sellable stock. A simple available quantity can be on hand minus allocated, blocked and safety stock. Available-to-promise can also include dated purchase or production supply. Define whether commerce shows a number, a status or a promised date. Include location priority, backorder rules, bundles and reservations. A scheduled stock snapshot can be enough for a low-volume catalogue. Fast-selling or scarce goods often need events, reservation or a live check near checkout.

Orders and changes

Send a stable commerce order ID and line ID, customer references, addresses, SKU, unit, quantity, price, discounts, tax, shipping, currency, payment state and requested delivery data. The ERP response needs more than “success.” Return the ERP order ID, accepted line quantities, holds, changed dates, rejected codes and warnings. Define who can change an order after acceptance and how the other system learns about it.

Fulfilment, returns and refunds

A shipment can contain part of one order and one order line can ship more than once. Use fulfilment and package IDs, quantities, carrier, service, tracking and event time. Returns need a reason, disposition and link to the original line. A return authorisation, warehouse receipt, credit note and payment refund are different events. Do not collapse them into one “returned” flag.

Invoices, payments and settlements

Card authorisation, capture, gateway fee, refund, chargeback, payout and ERP receipt are separate records. Keep gateway transaction IDs through the whole chain. Reconcile gross sales, tax, shipping, discounts, refunds, fees and net cash. For B2B terms, map invoice due date, outstanding amount, credit note and payment allocation so the account view agrees with finance.

Which ecommerce ERP data should sync in real time?

A live API call couples the customer experience to the speed and uptime of the ERP. Use it when the business value justifies that dependency. Queues and published data reduce coupling. They also create a freshness question. State the maximum acceptable age for every copied fact.

What does a reliable order integration look like?

A customer submits order WEB-10482. Commerce stores the final cart, payment reference and an immutable snapshot of addresses, prices and tax. It creates an order-submitted event with an idempotency key such as the channel plus commerce order ID. The integration validates required mappings before calling the ERP.

The ERP accepts seven lines and places one line on hold because the item is inactive. It creates sales order SO-89311. A useful response includes both IDs, each line result and the hold reason. Commerce shows “received, action needed” rather than “confirmed.” A customer-service task points to the failed line. Staff correct the item mapping and replay that line or the governed operation. The idempotency key prevents a second sales order.

Later, the warehouse ships five lines in two parcels. The integration sends shipment IDs, line quantities and tracking. One line remains open. The ERP invoices the shipped quantity. The customer returns one unit. The warehouse receipt does not itself prove that finance issued a credit or the gateway sent a refund. Each event remains linked to the original order and line.

How do you prevent duplicates, lost messages and silent errors?

Use stable IDs from both systems and store the mapping. Add an idempotency key to every create operation. Keep the source version, event time and processing time. Order matters when updates can arrive late. A newer event must not be overwritten by an older retry. Use a queue when the destination can be unavailable or slow.

Separate technical failure from business rejection. A timeout, expired token or unavailable endpoint can retry automatically with backoff. An unknown SKU, closed accounting period or invalid tax code needs business action. Repeating the same invalid request every minute creates noise and load. Put it in an exception queue with the record, reason, age, value and owner.

A dead-letter queue stores messages that automatic processing could not complete. It is not a graveyard. Define who reviews it, how a record is corrected, who can replay it and how the replay is audited. Mask sensitive customer and payment data in logs. Use least-privilege credentials, rotate secrets and keep production access separate from development.

How do ecommerce, ERP and finance prove they agree?

Operational monitoring asks whether jobs ran. Reconciliation asks whether the business result is complete and equal. Count orders by day and channel. Compare gross value, discounts, tax, shipping and accepted line quantities. Compare open fulfilment quantity. Compare invoiced and credited value. For payments, bridge gateway activity to ERP receipts and bank settlement.

Suppose commerce records a sale of 120, including 20 tax. The gateway captures 120, takes a fee of 3 and pays 117. Later it refunds 24, including 4 tax. The integration must keep the sale, tax liability, fee, cash, refund and tax reversal distinct. A comparison of only order total to bank cash will always appear wrong.

Give every mismatch an amount, age, cause and owner. A missing £10 order from five minutes ago is different from a £50,000 settlement mismatch from last week. Set service levels around business risk. Keep reconciliation independent enough to catch a failure in the primary event path.

Should you use a connector, iPaaS or custom integration?

Ask a connector vendor to show the exact objects, fields, directions, triggers, retry rules, limits and supported versions. Ask where transformations live and how custom fields survive upgrades. Ask how it handles partial success. A logo-to-logo claim is not an integration specification.

How do you implement ecommerce ERP integration safely?

Cost grows with the number of records, rules, systems and exceptions, not only the number of endpoints. A two-way customer flow with deduplication can be harder than a one-way catalogue feed. A real-time price call can be harder than a nightly product file. Estimate each flow through build, test, monitor, support and change.

For a regional rollout, test currency precision, tax and invoice fields, e-invoicing where required, address formats, time zones, language, privacy, data retention and the identifiers used by local carriers, banks and payment services. Keep those differences in explicit country configurations or adapters rather than scattering them through the core order flow.

A strong ecommerce ERP integration is deliberately boring in production. Staff know which system owns each fact. Orders do not duplicate. Failures are visible. Replays are safe. Finance can reconcile sales to cash. That result comes from explicit contracts and operational design, not from connecting two logos. Use the wholesale order management guide and fulfilment workflow guide to test the surrounding process. If the operational system is still undecided, use the distribution ERP software guide to build and test the shortlist.