eCommerce and ERP Integration

Of all the system pairs I have connected across twenty-two years of enterprise work, eCommerce and ERP is the one where a single stale number can cost real money in minutes. A shopper adds the last unit to their basket, the storefront still shows it in stock because nobody told it the warehouse shipped that unit an hour ago, and now you have an oversell, a refund and an unhappy customer. Behind the scenes, someone in operations is retyping web orders into the ERP, adjusting stock by hand, and pasting tracking numbers back into the store. Every one of those manual hops is a chance to introduce an error, and every error eventually reaches a customer. Connecting the two systems removes the human retyping and, done properly, gives sales, warehouse and finance a single shared version of the truth. This guide walks through how that connection actually works, and it sits alongside my enterprise system integrations hub, which anchors a wider cluster of system-pair integration guides.

The message up front: eCommerce and ERP integration is not primarily a technology problem. The REST calls and webhooks are easy. The hard part is agreeing which system owns the product catalogue, which owns the price, and how fast inventory has to travel so the store never sells what the warehouse cannot ship. Solve the data ownership and timing questions first, and the pipes almost build themselves.

1. What eCommerce and ERP each are, and why integrate them

An eCommerce platform is where the storefront lives. It manages the online catalogue, product pages, the shopping basket, checkout and the orders customers place. Its job is to sell: present products attractively, take payment, and capture the order. Shopify, Magento (Adobe Commerce), WooCommerce and BigCommerce are typical examples. The storefront is optimised for conversion and customer experience, not for accounting rigour or warehouse control.

An ERP, enterprise resource planning system, is where the back office lives. It runs inventory, warehousing, fulfilment, procurement and finance. Its job is to execute and account for the business: reserve stock, pick and ship the order, raise the invoice, post the ledger entry and reconcile the payment. SAP, Oracle, Microsoft Dynamics 365 Business Central and NetSuite are typical examples. The ERP is the system of record for stock and money, built for control and auditability rather than storefront agility.

Organisations integrate the two because an online sale is a single business event that starts in one system and finishes in the other. The order is captured in the storefront; the stock reservation, the shipment, the invoice and the payment reconciliation happen in the ERP. Without a link, that single event is split across two disconnected systems and stitched back together by hand. With a link, the web order flows into the ERP automatically as a sales order, the catalogue, price and available stock flow back so the store shows the truth, and shipment tracking flows to the customer without anyone retyping a thing. This pattern is common wherever an online channel feeds a real fulfilment and finance operation: retail, direct-to-consumer brands, wholesale and B2B trade, and distribution. If you want the underlying concepts before the specifics, my enterprise system integration explained primer covers the fundamentals that every pairing in this cluster relies on.

2. The business problems it solves

The case for integration is easiest to make by listing the specific, daily frustrations it removes. These are the symptoms I hear in almost every discovery session before an eCommerce and ERP project:

• Overselling. The storefront shows stock the warehouse no longer has because the two counts drift apart. The order is taken, the item cannot ship, and the business eats a refund and a reputation hit.
• Duplicate order entry. Web orders are read off the store and keyed into the ERP by hand. It is slow, it is demoralising, and it doubles the surface for typos on every single order.
• Stale catalogue and pricing. A price changes in the ERP but the store still shows the old one, or a discontinued product stays live online. Now two systems disagree and the customer sees the wrong version.
• Manual stock updates. Someone exports a stock report and re-uploads it to the store on a schedule, so availability online is always hours behind reality.
• Poor order visibility. The customer cannot see where their parcel is, and support cannot tell them, because tracking lives in the ERP and never reaches the store.
• Delayed reporting. Any report that spans web sales and fulfilled revenue has to be assembled by hand in a spreadsheet, so it is always stale by the time it is read.
• Human errors. Every manual re-key is a chance to transpose a quantity, pick the wrong SKU or attach the order to the wrong customer. Those errors surface as wrong shipments, wrong invoices and finance corrections.

Integration attacks all of these at once by making the data move automatically and by fixing where each field is authoritative. The retyping disappears, the overselling stops because inventory travels fast enough, and store, warehouse and finance look at the same numbers.

3. Integration architecture

At the architectural level, the storefront and the ERP almost never talk to each other directly. A direct point-to-point link is quick to demo and painful to live with, because every change on either side ripples straight into the other and there is nowhere to transform, validate or retry. The pattern that survives contact with production puts a middleware layer between the two systems. The eCommerce platform exposes or consumes events through a REST API and webhooks, the middleware receives them, transforms and validates the data, and then calls the ERP through its own API. The reverse path works the same way.

The building blocks worth naming:

• REST APIs are the default way both modern eCommerce platforms and ERPs expose their data. They are request-driven: the middleware asks for a record or posts a new one over HTTP, usually with JSON. Simple, well documented, and adequate for most of the traffic in this pairing.
• Webhooks flip the direction. Instead of the middleware polling the store every few minutes asking "any new orders?", the platform pushes an event the instant a customer checks out. Webhooks are what make an order reach the ERP in seconds rather than on the next poll.
• Middleware is the broker in the centre. It owns transformation (mapping storefront SKUs and fields to ERP item and field names), validation (rejecting bad data before it corrupts the ERP), routing, and the retry logic that keeps a temporary ERP outage from losing a web order. This is where an integration platform earns its licence fee.
• Message queues decouple the two systems in time. When the store fires an order event, the middleware drops it on a queue, and the ERP-side worker consumes it when it can. If the ERP is down for maintenance, the orders wait in the queue instead of being lost, and processing catches up when it comes back.
• Batch integration still has its place. Not everything needs to move the instant it changes. A scheduled job that syncs the full product catalogue and price list, or reconciles the customer master, is simpler and cheaper than streaming every change, and for slow-moving data it is the right tool.

4. Data flow: what moves in each direction

A clean integration is easiest to reason about when you split it by direction and are strict about which system is the source for each object. The two directions carry very different kinds of data.

eCommerce to ERP (the storefront feeding the back office):

• Orders placed online need to become sales orders in the ERP so they can be picked, packed and shipped.
• Customers who register or check out need to exist in the ERP so they can be invoiced and tracked.
• Payments captured at checkout, so finance can reconcile what was taken against what was billed.
• Returns and RMA raised by the customer, so the ERP can process the refund, restock and credit note.

ERP to eCommerce (the back office informing the storefront):

• Product catalogue so the store lists exactly the items the business actually sells, with correct descriptions and attributes.
• Pricing so the store charges the same authoritative prices the ERP will actually bill and account for.
• Promotions so discounts and campaign prices configured centrally show correctly at checkout.
• Inventory availability so the store never promises stock the warehouse cannot ship.
• Shipment tracking so the customer and support can see where the parcel is without opening the ERP.
• Invoice status so the order shows as billed and the customer's account stays accurate.

Notice the pattern. The storefront sends demand and money in; the ERP sends catalogue, price and fulfilment reality back. Keep that division clear and most of the design decisions make themselves.

5. Data objects exchanged

Putting the concrete objects side by side makes the contract between the two systems explicit. This is the table I sketch on a whiteboard in the first design workshop, because it forces both teams to agree on ownership before anyone writes code.

The left column is demand and money, born in the storefront. The right column is catalogue, price and inventory truth, born in the ERP. When both teams sign off on this table, arguments about "why did my field get overwritten" mostly disappear, because everyone knows which side owns which object.

6. Business process flow

The clearest way to see the integration in action is to follow one order along its whole life and mark which system owns each step. The order-to-cash journey crosses the eCommerce and ERP boundary exactly once, at the point where a web order becomes a real sales order for fulfilment.

The product sync, the customer order and the payment are the storefront's territory: they are about capturing the sale and are owned by the eCommerce platform. The moment the order is paid, it crosses the boundary and becomes a sales order in the ERP, which then owns the rest of the chain, fulfilment and shipping and the invoice. The single most important integration event in this whole pairing is that one crossing, paid web order to ERP sales order. Everything after it, the parcel shipped and the invoice raised, flows back to the store as status updates so the customer sees the full picture without anyone retyping it.

7. Real-time versus batch

Not every field needs to move the instant it changes, and treating everything as real time is a common way to make an integration expensive and fragile for no benefit. The discipline is to match the timing to how fast the data actually changes and how quickly a stale value would cause harm. In this pairing, inventory is the field that punishes lateness hardest, because a stale count is what causes an oversell.

A caution on inventory timing: the temptation is to leave stock on a nightly batch because "it worked before we scaled". It does not work once volume rises. During a sale or a marketing push, a warehouse count that is even fifteen minutes old will let the store sell units that are already gone, and every oversell is a refund plus a support ticket plus a dented reputation. Push inventory to near real time even when everything else can wait, because this is the one field where a stale value costs money the same day. Everything else, the catalogue and the promotions, can ride a schedule.

8. Integration technologies and when each fits

The tooling landscape for eCommerce and ERP integration is broad, and the right choice depends less on fashion than on what the two systems already speak and what your operations team can support. The options I reach for, and when:

• REST API. The default for anything modern. Both current eCommerce platforms and ERPs expose REST endpoints with JSON payloads. Use it for the bulk of your request-driven traffic: create a sales order, fetch a stock level, post a customer, update a price.
• Webhooks. The right choice when you need the store to push events the instant they happen, an order placed, a payment captured, a return requested, without the middleware polling. They are the backbone of instant order capture and they keep API call volumes sane.
• iPaaS connectors. Managed integration-platform-as-a-service tools ship pre-built connectors for the common storefronts and ERPs, so you configure a flow rather than code one. A strong fit when the systems are mainstream and you want less to build and operate yourself.
• OAuth 2.0. Not a transport but the authorisation standard you will almost certainly use to let the middleware call the store and ERP APIs securely, with scoped, revocable tokens rather than shared passwords.
• Message queues such as RabbitMQ. A pragmatic broker for reliable queuing between the middleware and each system, giving you decoupling and a retry buffer so an ERP outage never loses an order.
• Event streaming such as Kafka. An event backbone for high-volume, many-consumer scenarios. Overkill for a simple two-system link, but the right call when order and inventory events must fan out to a warehouse system, a marketplace and analytics at once, with a durable, replayable log.
• SFTP. Unglamorous and still everywhere. For nightly batch file exchange, a full catalogue or price-list extract dropped as a file and picked up by the other side, SFTP is simple, robust and universally supported.

My rule of thumb: REST plus webhooks plus OAuth 2.0 for the real-time path, a message queue such as RabbitMQ for reliability, and SFTP batch for the slow reference data. Reach for a full iPaaS when you would rather buy the plumbing than run it, and for Kafka only when the event-fan-out genuinely justifies it.

9. Security

An eCommerce and ERP link carries customer identities, addresses, order values and payment references. That makes it a sensitive pipe, and the security thinking has to be part of the design rather than bolted on afterwards. The essentials:

• Authentication. Every call between the middleware and either system proves who it is, using OAuth 2.0 tokens or service credentials, never a shared human login. Tokens are scoped and can be revoked without changing anyone's password.
• Authorisation. The integration account is granted the minimum it needs and nothing more. The store-side account can read orders and write nothing to the ledger; the ERP-side account can create sales orders and post stock but not delete customers. Least privilege contains the blast radius if a credential leaks.
• Encryption. Everything moves over TLS in transit, and sensitive fields, payment references and personal data especially, are protected at rest. Never let this traffic run over an unencrypted channel, even inside the corporate network. Card data should stay with the payment gateway, not flow through this pipe.
• Audit logs. Every message, its payload summary, its source, its outcome and its timestamp are logged. When finance asks why an order value differs between store and ERP, you need to answer from the log, not from a shrug.
• Error handling. Security includes failing safely. A rejected or malformed message must be quarantined, alerted and retried in a controlled way, never silently dropped and never allowed to write half an order. Good error handling is what stops a transient glitch from becoming a data-corruption incident.

10. Common challenges

The problems that actually derail eCommerce and ERP projects are boringly consistent, and knowing them in advance is most of the battle:

• Overselling. Inventory travels too slowly, the store sells stock the warehouse already shipped, and the business absorbs refunds and complaints. This is the single most common failure and it is a timing problem more than a code problem.
• SKU mapping. The store keys a product by its own SKU or handle; the ERP keys the same product by a different item code. Without a reliable cross-reference, orders attach to the wrong item and stock updates land nowhere.
• Price and promotion conflicts. A discount set in the store and a price set in the ERP disagree at checkout, so the customer is charged one figure and invoiced another. You need one authoritative source for price and a clear rule for where promotions are applied.
• Duplicate customers. A shopper checks out as a guest twice with slightly different details, or registers after ordering, and the integration cheerfully creates several ERP records for one person. Without matching and de-duplication rules, the link multiplies the mess.
• Returns and RMA complexity. A return has to reverse stock, refund payment and issue a credit note, all in step across two systems. Get the sequence wrong and you refund without restocking, or restock without refunding, and the numbers stop reconciling.

11. Best practices

The habits that separate an integration people trust from one they route around:

• Define the master system per object. Decide, field by field, which system is authoritative. Catalogue, price, promotions and inventory are owned by the ERP; the order and the customer's checkout details are captured by the store. Write it down, agree it, and enforce it in the mapping so nothing overwrites its own master.
• Prioritise inventory freshness. Make stock the field you treat most aggressively, near real time even when the rest is scheduled, because it is the one that causes overselling. A small buffer or safety-stock rule on the store side is cheap insurance during peaks.
• Build retries with backoff. The ERP will be down for maintenance and the network will blip. A failed order message should retry automatically on an increasing delay, not vanish. Idempotent operations, safe to repeat, make retries safe so an order never posts twice.
• Log and monitor everything. Every message in, out, transformed and rejected, with alerts on queue depth, error rate and processing lag before customers notice. An integration that only tells you it broke when a shopper complains is not monitored, it is being watched by the customer.
• Version your interfaces. Storefront APIs and ERP payload formats change. Version the contract so a change on one side does not silently break the other, and so you can migrate deliberately rather than in an emergency.

The practitioner's insight: the single decision that most determines whether an eCommerce and ERP integration succeeds is where inventory is authoritative and how fast it travels, decided before any code is written. Make the ERP the master of stock, push that number to the store in near real time, and overselling, the failure everyone fears, largely disappears. Get every team to agree ownership of catalogue, price and stock, and the transformation, conflict handling and de-duplication rules all follow naturally. This same principle anchors every guide in the enterprise integrations hub, because data ownership is the problem that recurs in every system pair.

12. KPIs: proving it works

An integration is an investment, and like any investment it should be measured, not taken on faith. The metrics I hold an eCommerce and ERP link accountable to:

• Order processing time. How long from a paid web order to a sales order ready to pick in the ERP. Before integration it was often hours of manual keying; after, it should be seconds to minutes.
• Oversell rate. The percentage of orders that cannot be fulfilled because stock ran out after the sale. This is the number that most directly reflects inventory freshness, and a healthy link keeps it near zero.
• Inventory accuracy. The gap between the stock the store shows and the stock the warehouse holds. The whole point of the link is one version of availability, so measure how close you are to it.
• Manual effort saved. The hours of order re-keying and stock uploading eliminated per week, measured concretely. This is the number that pays back the project and the one finance cares about most.
• Return on investment. Effort saved plus oversells avoided plus faster fulfilment, set against build and run cost. On eCommerce and ERP the return usually shows up quickly, because the manual work removed and the refunds avoided are both so visible.

13. Industry examples

The same architecture adapts to very different sectors, with the emphasis shifting to match what each business cares about most:

• Retail. High order volumes and frequent promotions make near-real-time inventory and reliable price sync essential, so the store never oversells and never charges the wrong figure during a campaign.
• Direct-to-consumer brands. A single Shopify or WooCommerce storefront feeds one ERP, where a lean team relies on the link to run fulfilment and finance without hiring people to retype orders as they scale.
• Wholesale and B2B trade. Customer-specific pricing and credit terms live in the ERP and must reach the store so each trade buyer sees their own agreed price, while orders flow back for account-based invoicing.
• Distribution. Multiple warehouses and large catalogues make SKU mapping and aggregated stock availability the make-or-break detail, so the store shows a single accurate figure across sites.
• Multi-channel sellers. One ERP behind a storefront plus marketplaces, where a shared inventory pool must be reflected everywhere at once so stock sold on one channel is not oversold on another.

These are the same forces that make the neighbouring pairings in this cluster worth reading if your estate is broader than just the storefront and the ledger: connecting the physical till with the ledger in my POS and ERP integration guide, and connecting the checkout money rail with the ledger in my payment gateway and ERP integration guide. The architecture rhymes; only the objects and the owning systems change.

14. References

This guide leans on a small set of widely adopted, vendor-neutral standards and patterns rather than any single product's documentation. For the interested reader, the concepts worth reading further on, by name, are:

• REST (Representational State Transfer), the architectural style behind the HTTP and JSON APIs that both modern eCommerce platforms and ERPs expose.
• Webhooks, the event-notification pattern that lets the storefront push orders and other changes to the ERP the instant they happen instead of being polled.
• OAuth 2.0, the authorisation framework for granting scoped, revocable access to those APIs without sharing passwords.

Each of these is a published, openly documented standard maintained by its respective standards body or community, and the current specifications are the authoritative source rather than any vendor's summary of them.

Final thoughts

Connecting eCommerce and ERP is one of the highest-return integrations most online businesses can do, precisely because the pain it removes is so visible. The retyping stops, the overselling stops, and store, warehouse and finance finally see the same product, the same stock and the same order. The benefits, less duplicate entry, fewer oversells, faster fulfilment and shared visibility, show up quickly and are easy to measure.

The challenges are just as predictable: overselling from stale inventory, SKU mapping across systems, price and promotion conflicts, duplicate customers and the sequencing of returns. None of them is really a technology problem, and all of them yield to the same discipline, decide the master system per object first and get inventory travelling fast enough, then build the pipes to respect it. Looking ahead, the direction of travel is clear: more event-driven, near-real-time flows over batch, more managed iPaaS platforms replacing hand-built middleware, and AI starting to help with the unglamorous work of matching SKUs and de-duplicating customers across systems. The plumbing keeps getting easier. The judgement about data ownership and inventory timing stays exactly as important as it has always been, and that is the part worth getting right.

Related reading: Enterprise system integrations hub, Enterprise system integration explained, POS and ERP integration, Payment gateway and ERP integration.