B2B Ecommerce Integration: Selling to Accounts, Not Shoppers

Almost everything behind the product image. Each account sees its own negotiated pricing rather than one public price. Payment is usually on account against a credit limit rather than by card. Products are bought in cartons, inners or other trade units rather than singles. Availability matters in terms of lead time rather than a simple in stock flag. Buyers reorder the same lines constantly, so speed of repeat ordering beats discovery. And your own sales representatives need to place orders on behalf of customers in the same system.

In the ERP, without exception. The ERP is where prices are negotiated, where contracts are recorded and where invoices are ultimately raised, so it has to be the source of truth. Copying the rules into the storefront creates two systems that will diverge, and the divergence is discovered by a customer being charged the wrong amount. The practical implementation is usually a scheduled push of each account’s price list for fast browsing plus a live check at checkout so the order itself is never priced from stale data.

Show what the customer can actually have, not what is physically on a shelf somewhere. That means subtracting stock already allocated to other orders, restricting to the warehouse that serves this customer, expressing the figure in the unit of measure they buy in, and adding a lead time for anything on an incoming purchase order. Many Australian wholesalers prefer bands such as available now, limited or made to order, both because exact quantities can be commercially sensitive and because a band cannot be wrong in the way a precise number can.

Usually yes. Older systems often lack a modern interface but offer a database view, a scheduled file export, or a middleware layer that can be wrapped so the portal has something to ask. The main consequence is on how live the data can be. If the ERP can only be queried on a schedule then pricing and stock on the site are as fresh as that schedule, and the design has to compensate, typically by confirming price and availability at checkout and being honest on screen about when figures were last updated.

In practice it tends to move their time rather than remove it. The portion of a rep’s week spent transcribing repeat orders is not where the commercial value sits, and customers who reorder online still need range advice, promotional planning and problem solving. The arrangements that work give reps the ability to order in the portal on a customer’s behalf, preserve their commission on portal orders from their accounts, and make the portal the tool they demonstrate on a visit. The arrangements that fail are the ones announced internally as a cost reduction.

By making it an explicit setting per customer rather than a global rule, because trade buyers genuinely disagree about it. Some want anything available despatched immediately and the remainder to follow, since their own customers are waiting. Others want the order held until it can ship complete, because their receiving process cannot absorb three deliveries against one order. The portal has to reflect whichever applies to that account, show the backordered lines clearly with an expected date, and update that date when the incoming purchase order moves.

For a wholesaler with documented pricing rules and a reasonably clean ERP, six to twelve weeks from scoping to a pilot group transacting is a realistic range. The build is rarely the constraint. The time goes into pinning down pricing precedence, agreeing what available should mean, and deciding credit behaviour at checkout, all of which involve people rather than software. Where pricing rules exist only as knowledge in a long serving rep’s head, expect the documentation stage alone to take several weeks and treat that as valuable work rather than delay.