The B2B order is not a B2C order
The fundamental error in many B2B projects is architecting the system around a B2C concept of an 'order'. In retail, an order is a simple, linear event: a single user pays with a card for items from a single catalogue to be shipped to a single address. The entire process is over in minutes. For a trade buyer, this model is a fiction. Their 'order' is a complex, long-running commercial agreement that might begin as a quote request, involve multiple authorisers, draw on customer-specific pricing, be paid for on a trade-account with a defined credit limit, and require split shipments from multiple depots or suppliers over a period of weeks. Trying to force this reality into a standard B2C checkout flow is a recipe for operational failure.
Consider the workflow of a buyer for a national housebuilder placing an order with a builders merchant. They need to see contract pricing, not the list price. The order may need approval from a site manager. It might be a call-off from a pre-agreed bulk purchase. Part of the order needs to be delivered to Site A on Monday, and another part to Site B on Wednesday. Some items are on backorder. This entire process is the 'order'. A platform's ability to model these states and actors is a far more important selection criterion than its front-end features. As we found when developing the B2B commerce platform for the Donaldson Group, mapping these real-world trade purchasing behaviours is the foundation of a successful system.
Your ERP is not an order management system
The default architecture for many B2B businesses is to treat the Enterprise Resource Planning (ERP) system, whether it's SAP, Microsoft Dynamics, or NetSuite, as the master for all commerce logic. It holds the customer data, the inventory, and the complex pricing rules. The logic is simple: since the ERP is the ultimate source of truth, the website should just ask it for everything in real time. This approach is almost always a mistake. ERPs were built for financial reporting and supply chain planning, not for serving sub-second API requests from a public-facing website. Every call for a price, a stock level, or a credit check adds latency that destroys the user experience.
Relying on direct, real-time ERP lookups creates a brittle and slow platform. According to our own internal benchmarks from multiple ERP integration projects, a single 'available-to-promise' inventory check against a major ERP can take over 500 milliseconds. On a product listing page with 20 items, that is ten seconds of loading time, which is commercially unviable. Furthermore, customising an ERP to expose new logic via an API is often fantastically expensive and slow, requiring specialist consultants and risking the stability of a business-critical system. The ERP should be the system of record, but it cannot be the system of engagement. Its data must be synchronised to a more appropriate, faster layer.
"Treating your ERP as a real-time order engine is the most common and costly mistake in B2B commerce architecture. It's a strategy that guarantees a slow site and a failed project."
Orchestration: The role of a dedicated OMS
The solution is to decouple the commerce front-end from the ERP back-end with a dedicated Order Management System (OMS). This can be a standalone product or a well-architected set of services built as part of the commerce platform. The OMS acts as an orchestration layer, handling the fast-moving data and complex logic that a modern B2B site needs. It can ingest inventory feeds from multiple warehouses, ERPs, and even third-party suppliers, aggregating them to present a single, accurate stock position to the customer. It manages the lifecycle of the order, handing off to the ERP only at key financial checkpoints, like raising an invoice or confirming shipment.
This architecture allows each system to do what it does best. The commerce platform, such as Adobe Commerce, handles the catalogue, merchandising, and customer-facing interactions. The OMS handles the complex, multi-stage order logic. The ERP handles finance, procurement, and master data management. For example, a customer's credit limit might be mastered in the ERP, but the OMS can cache and manage the real-time balance for web sessions, preventing the site from having to make a slow ERP call on every 'add to basket' action. This separation of concerns is the hallmark of a scalable and resilient B2B architecture, reducing dependency on a single monolithic system.
The questions that determine platform choice
Before you can choose a platform, you must have answers to a specific set of questions about your order management requirements. Your choice of Adobe Commerce, Salesforce Commerce Cloud, or another system will be dictated by how easily they can meet these needs, either natively or through extension. First, how will you handle customer-specific pricing? Can the platform evaluate complex rules in real-time without degrading performance? Second, how will you present inventory from multiple locations, and how will you manage orders with split shipments and staged delivery dates? This was a central challenge in our work with the builders merchant Bradfords.
Third, what does your complete 'order-to-cash' process look like for a trade-account customer? This includes not only credit limits but also purchase order processing, invoice payments, and returns. Fourth, do your largest customers require procurement system integration via punchout? This is a non-negotiable feature for many large enterprise buyers. Finally, how extensible is the platform's order model? If you need to add custom statuses to track a complex manufacturing or returns process, can this be done without fighting the core architecture? Your prospective implementation partner should have definitive answers to these questions, with examples. If their answers are vague, they do not have the requisite B2B experience.
