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. For a manufacturer, it may also own bills of materials and work orders, which our manufacturing ERP comparison covers. 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.

For orders placed through an AI buying service, the agentic commerce integration guide explains who can approve the purchase, which checks happen before the order becomes final and what to do when checkout cannot confirm the result.

If you are replacing accounting plus operational spreadsheets rather than connecting an established ERP, the QuickBooks to ERPNext migration guide explains how to scope configuration, retain useful systems and reconcile balances before switching.

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. If the B2B storefront is still being chosen, the B2B ecommerce platform comparison shows how the main candidates model company accounts and price lists. For a signed-in trade portal, the B2B customer portal and ERP integration guide covers buyer users, contract prices, credit and order states in detail.

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. The same stable order ID lets marketing match reported purchases to real orders; the server-side tracking guide shows how.

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, a decision about what happens to the goods and a 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; the ecommerce payment reconciliation guide works through one payout line by line. 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 application programming interface (API) call makes the customer experience depend on the speed and uptime of the ERP. Use it when the business value justifies that dependency. Queues and copied data reduce that dependence, but the copy can become old. 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 unchangeable copy of the addresses, prices and tax. It creates an order-submitted message with a duplicate-protection key, such as the sales channel plus commerce order ID. The integration checks 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 resend that line or approved operation. The same duplicate-protection 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?

Keep the original IDs from both systems and store how they correspond. Add a duplicate-protection key to every create operation. Keep the source version, event time and processing time. Order matters when updates can arrive late. A newer update must not be overwritten by an older retry. Use a queue when the receiving system can be unavailable or slow.

Separate technical failure from business rejection. A timeout, expired token or unavailable service can retry automatically, waiting longer after each failure. 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 work list 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 resend it and how that action is recorded. Mask sensitive customer and payment data in logs. Give credentials only the permissions they need, 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.

For physical stock, compare item, location, unit, state and cutoff before approving any correction. The inventory reconciliation worked ledger and CSV template shows how a late dispatch can leave availability correct while on-hand is 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, integration platform or custom integration?

Put the connector through a difficult order before launch

Take a ten-unit order. Ship four units now and six later. Then resend the first shipment after a timeout. Does ERPNext keep one sales order, record the two shipments correctly and avoid deducting the first four units twice? A connector demo should answer questions like that with records. A green sync successful message is not enough.

The Shopify–ERPNext integration acceptance test pack gives your team three working files: an execution checklist and sign-off record, a 20-case test sheet, and a who-owns-what matrix. The cases cover wrong warehouse mappings, duplicate and out-of-order messages, partial shipments, refunds, physical returns, missing events, credential changes and upgrades.

• Agree ownership first. Decide which system is allowed to change each fact, such as stock, price, shipment or refund.
• Run the awkward cases. Use a test shop and ERPNext site. Record the Shopify and ERPNext IDs, quantities, values and timestamps you actually observe.
• Do not grade your own assumptions. Every row starts as NOT RUN. Mark PASS only when the expected records exist; mark FAIL when they do not; use NOT IN SCOPE only with a named approver and reason.

The pack is based mainly on version 1.20.3 of Frappe’s ecommerce_integrations app, reviewed on 24 October 2026. We reviewed a newer development version separately because it uses a different Shopify authentication method. Neither review proves that the connector will work with your installed ERPNext version or Shopify shop. Confirm both in your test environment. The checklist contains the exact code references, while the ERPNext service scope explains what an implementation needs from the client and from Harmatiq.

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 system connections. A two-way customer flow with duplicate protection 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 named country rules or modules 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. Resending a failed message is safe. Finance can match sales to cash. That result comes from clear data rules 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.