Every manufacturer and FMCG brand we work with has an ERP. SAP, Oracle, Dynamics, sometimes something bespoke that was built 15 years ago and nobody fully understands any more. The ERP is the spine of the business. It manages inventory, processes orders, handles financials, and connects to the supply chain. It works.
It works for trade. It was built for trade. It processes bulk orders from dealers, distributors, and retailers. Minimum order quantities, pallet-level fulfilment, 30-day payment terms, account-based pricing. The entire logic of the system assumes that the customer is another business, not a consumer with a credit card buying a single unit.
When a business decides to sell ‘direct to consumer’, the ERP is rarely the first thing anyone thinks about. The conversation starts with the website, the brand, the marketing. By the time someone asks how the consumer order actually gets into the ERP, the platform has already been chosen, the agency has been briefed, and the launch date has been set. The integration becomes an afterthought. And that is where the trouble starts.
An ecommerce platform like Shopify, BigCommerce, or Adobe Commerce is designed to sell to consumers. It handles product display, basket management, payment processing, and order confirmation. It does its job well. The problem is that it speaks a different language to your ERP.
Your ERP expects orders in batches, with account numbers, purchase order references, and trade pricing. A consumer order arrives individually, with a card payment, a delivery address, and a retail price. The units of measure may be different. The product codes may not match. The stock levels in the ERP update on a batch cycle (every four hours, or overnight), while the ecommerce platform needs real-time availability to avoid selling something that is not in stock.
Bridging this gap is not a plug-in. It is not a standard API connection that an agency can configure in a sprint. It is a genuine technical and architectural challenge that requires understanding both systems intimately: what the ERP needs to receive, what the ecommerce platform needs to send, and how to handle the dozens of edge cases that sit between them.
The straightforward consumer order (one item, in stock, standard delivery) will probably work. It is the exceptions that expose the integration.
A consumer orders two items. One is in stock, one is on back-order. The ERP handles back-orders at trade level by holding the entire order until complete. The consumer expects the in-stock item to ship immediately and the other to follow. The integration needs to split the order, and the ERP may not support that natively.
A consumer returns an item. The ecommerce platform triggers a refund. But the ERP needs to receive the returned stock back into inventory, update the financials, and reconcile the payment. If the returns process was not designed into the integration from the start, this becomes a manual exercise: someone in finance matching refunds to returns on a spreadsheet.
The stock level in the ERP says 500 units. But 480 of those are allocated to a trade order shipping next week. The ecommerce platform does not know this, because the integration was built to sync total stock, not available stock. The site shows ‘in stock.’ The consumer orders. The warehouse cannot fulfil. The customer gets an apology email. The brand takes the reputational hit.
Every one of these scenarios is predictable. Every one of them can be designed for. But they are only designed for if someone asks the right questions before the integration is built, not after it breaks.
The typical solution to the ERP integration problem is middleware: a layer that sits between the ecommerce platform and the ERP, translating data between the two. In principle, this is sound. In practice, it introduces its own problems.
Off-the-shelf middleware connectors promise a quick integration. They handle the common scenarios well enough. But they rarely handle the specific logic of your ERP configuration, your product data structure, your inventory allocation rules, or your financial reconciliation requirements. The business ends up with a connector that works for 80% of orders and generates errors for the other 20%. That 20% becomes manual work: someone checking, correcting, and re-processing orders that fell between the systems.
Custom middleware is more robust but more expensive, and it requires someone who understands both the ERP and the ecommerce platform well enough to design the data architecture properly. That person is rarely the agency (who understand the platform but not the ERP) and rarely the ERP vendor’s team (who understand the ERP but not consumer ecommerce). It is a specific skill set that sits in the gap between the two.
The most important piece of advice I can give any business planning D2C is this: map the integration requirements before you select the ecommerce platform. Not after. Before.
Understand what your ERP can and cannot do with consumer orders. Understand where the data gaps are: product data, stock allocation, pricing, returns logic, financial reconciliation. Understand what the integration needs to handle on day one and what can wait. Then choose the platform and the integration approach based on what the operation actually requires, not what the agency is most comfortable building.
This is not glamorous work. It involves sitting with the IT team, the finance team, and the warehouse team and asking detailed questions about how the current systems handle specific scenarios. It involves mapping data flows and identifying where the logic breaks. It involves testing edge cases before they become customer complaints.
But it is the work that determines whether your D2C channel actually functions or becomes an expensive source of manual workarounds and operational frustration. The storefront is the visible part. The integration is the part that makes it work. And in most D2C projects, nobody gives it the attention it deserves until it is too late.
