B2B Ecommerce Integration: Selling to Accounts, Not Shoppers
A wholesale ordering site is not a retail store with a login bolted on. Every account sees a different price, holds a different credit position, buys in different pack quantities and has a different idea of what counts as in stock. All of that already lives in your ERP, which is why a trade portal succeeds or fails on the integration rather than the design.
The failure pattern is consistent: the site launches, reps keep taking orders by email because the portal shows the wrong price or lets a customer order past their credit limit, and within a year the project is quietly described as a website that nobody uses. Below is what has to flow, in which direction, and what breaks when it does not.
Realistic ROI
Four Things That Decide Whether a Trade Portal Gets Used
Wholesale buyers abandon a portal for one reason: it told them something that turned out not to be true. These four decisions determine whether that happens.
Pricing has to come from the system that owns it
Wholesale pricing is layered: a list price, a customer group discount, a customer specific price on some lines, a contract price on others, a volume break, and a promotion that overrides part of it. That logic already exists in the ERP and it must not be reimplemented in the website, because two copies of pricing rules diverge within months. The site should ask for the price for this customer, this product, this quantity, today, and display whatever comes back.
Credit position belongs to finance, not the storefront
An account on hold, over its limit or outside terms should not be able to place an order that finance will have to reverse. The portal needs to know the current credit status at checkout, and it needs a defined behaviour for each case: block, allow with a warning, convert to a quote for approval, or require card payment instead. Deciding those behaviours is a finance conversation that should happen before the build, not a technical one.
Available means available to this customer
Trade buyers plan around lead times, not just current stock. Showing a raw on hand number is often worse than showing nothing, because it ignores allocated stock, goods already on a purchase order, minimum order quantities and pack rounding. What the buyer needs is a straight answer: how much can I have, and when. That is a calculation across several ERP fields rather than a single field lookup.
Reps and customers use the same system
The portal that succeeds is normally the one your sales team uses on a customer’s premises, ordering on that customer’s behalf, seeing the same prices and the same stock. It gives you one order path instead of two, it makes the data trustworthy because reps notice errors immediately, and it removes the political problem of a portal that reps see as competing with them for commission.
What Has to Flow Between the Portal and the ERP
Six flows carry almost all the value. The direction and the timing of each one matters as much as the fact that it exists.
Customer specific pricing
Either the full price list for each account is pushed to the store on a schedule, or the store asks the ERP for a live price at the moment of display. Pushed lists are faster to browse and go stale; live lookups are always correct and depend on the ERP being available. Most wholesalers end up with a hybrid: pushed lists for browsing and a live check at checkout so the order is never priced wrongly.
Credit and account status
Current balance, credit limit, overdue amount and any hold flag, checked at checkout rather than at login, because a buyer may spend an hour building a large order. The behaviour for each status is agreed in advance with finance and applied consistently, including the awkward middle case where an account is within limit today but this order would push it over.
Stock and lead times
Available to promise rather than raw on hand, taking account of allocations, incoming purchase orders and the warehouse the customer is actually served from. Where exact figures are commercially sensitive, banded indicators work well: available now, limited, or on a stated lead time. Buyers accept a band. They do not forgive a number that turns out to be wrong.
Orders and backorders
The order arrives in the ERP as a sales order with the right customer, price, delivery address and pack quantities, and the portal shows its real status thereafter. Backorder policy has to be explicit per customer: some accounts want partial despatch immediately, others want the order held complete. Getting this wrong generates more support calls than any other single rule.
Reordering and history
Wholesale buying is repetitive, so the fastest ordering experience is usually a previous order, a standing list or an uploaded spreadsheet of codes and quantities. That means the portal needs order history from the ERP including orders placed by phone, email or a rep, not just orders placed on the site. A history that shows only web orders makes the portal look empty to your best customers.
Invoices, statements and payments
Self service access to invoices, credit notes, statements and outstanding balances removes a large share of the calls your accounts team fields. Where you allow payment against invoices online, the receipt has to post back to the ledger and allocate correctly, otherwise you have created a reconciliation problem in exchange for a convenience.
Trade Ordering Before and After Integration
| Task | Traditional | Integrated Portal | Notes |
|---|---|---|---|
| Customer checks their price | Emails their rep and waits | Sees their contract price live | The single most requested capability in wholesale, and the one that decides whether the portal is trusted. |
| Order placed after hours | Sits in an inbox until morning | Lands in the ERP immediately | Trade customers frequently order outside business hours, often from a warehouse floor or a van. |
| Account over its credit limit | Discovered at invoicing | Handled at checkout by agreed rule | Blocking, warning or converting to a quote are all valid. Silently accepting is not. |
| Ordering below the pack quantity | Corrected by hand later | Rounded to the pack at entry | Pack size, inner quantity and unit of measure must come from the ERP, per product. |
| Rep ordering for a customer | Written down and keyed in later | Placed in the portal as that account | One order path for everyone is what makes the data reliable and the reps supportive. |
| Chasing an invoice copy | A call to accounts | Downloaded from the portal | Reduces routine calls noticeably, and the effect compounds at end of month. |
| Repeat order of a standing list | Rebuilt line by line each time | Reordered from history in a minute | History must include phone and rep orders or the feature looks broken to large accounts. |
| A line the customer cannot buy | Ordered anyway, cancelled later | Hidden or blocked by catalogue rules | Territory restrictions, brand exclusivity and account specific ranges are common in Australian distribution. |
Where Wholesale Portals Quietly Fail
Pricing rules rebuilt inside the website
The moment discount logic is written a second time in the storefront, it starts drifting from the ERP. A change to a customer group in the ERP does not reach the site, a promotion expires in one place and not the other, and the first person to notice is a customer being overcharged. Keep pricing in the system that owns it and have the site ask. If the ERP cannot answer fast enough, cache the answer with a short expiry rather than reimplementing the rules.
Stock shown as a raw on hand number
On hand includes stock already allocated to other orders, stock in a warehouse this customer is not served from, and stock in a unit of measure the buyer does not think in. Publishing it directly guarantees that some customers will be told they can have something they cannot. Calculate an available to promise figure per warehouse, or publish bands rather than numbers, and always let the checkout do a final confirmation.
GST displayed the way a retail store displays it
Trade buyers work in GST exclusive terms and expect prices, minimum order values and freight thresholds to be quoted that way, with tax shown as a separate line and the tax invoice compliant when it is issued. A portal that quietly displays GST inclusive pricing to account customers creates disputes over every order value threshold, and a tax invoice that omits the required details creates a problem at BAS time for your customer rather than for you.
No decision about who can see what
Wholesale accounts often have several users with different rights: a buyer who can order, a warehouse contact who can only receipt, an owner who can see pricing and statements. Without a permissions model agreed up front, either everybody sees the account’s full financial position or the portal is too restrictive to be useful. Design it early, because retrofitting permissions across an already published catalogue is painful.
The rep channel is treated as the competition
A portal presented internally as a way to reduce reliance on sales staff will be quietly undermined by the people best placed to undermine it. The arrangements that work give reps the portal as a tool, keep their commission on portal orders from their accounts, and use the time freed from order taking for range and margin conversations. This is a commercial decision, not a technical one, and it decides adoption more than any feature.
Nothing watching the order flow
A trade portal that silently stops posting orders to the ERP looks completely healthy from the outside. Customers place orders, receive confirmations and wait. You need alerting on any order that has not reached the ERP within a few minutes, a visible queue of failures, and the ability to replay them once the cause is fixed. Without it the first indication is an angry call about an order placed four days ago.
How Yes AI Approaches a B2B Commerce Integration
Pricing logic documented before build
We work through every layer of your pricing with the people who actually maintain it, write down the order of precedence, and test it against real accounts and real historical orders. In a surprising number of wholesalers this document does not exist yet, and producing it is valuable regardless of the portal.
Credit rules agreed with finance
What happens at the limit, on hold, overdue, and on the order that would tip an account over. Agreed in writing with your finance team, applied consistently at checkout, and logged so exceptions can be reviewed rather than argued about.
Built, hosted and monitored by us
The integration runs on a managed cloud automation layer we operate, with alerting on failed orders and record level logging of pricing lookups so a disputed price can be traced back to what the ERP actually returned that day.
Straight advice on platform choice
Several mainstream ecommerce platforms now handle wholesale respectably, and if one of them plus a standard connector covers your rules we will tell you and build only the gap. Custom work is warranted when your pricing or availability logic genuinely exceeds what the platform can express.
From Email Orders to a Portal Reps Trust
Five steps. First accounts are usually transacting between weeks six and ten.
Map how orders arrive today
Email, phone, rep, spreadsheet and fax, with volumes against each. We look at where re keying happens, where pricing errors originate, and which accounts generate the most administrative work.
Document pricing and availability rules
Every pricing layer and its precedence, pack quantities and units of measure, warehouse allocation per customer, backorder policy per account, and what available should mean on screen.
Agree credit and permission behaviour
Checkout behaviour for each credit status, which user roles exist on an account, what each role may see, and how a blocked order becomes a quote rather than a dead end.
Build, test with real accounts, pilot
Built against official interfaces and tested using a copy of real customer data including your most complicated accounts, then piloted with a handful of friendly customers and your own reps before any wider announcement.
Roll out by segment and tune
Accounts onboarded in waves rather than all at once, monitoring on order posting from day one, and pricing and availability rules tuned against real behaviour rather than assumptions.
Related Reading
SaaS Integration Explained
The six integration patterns and how to choose between them.
EDI Integration
When your trading partners are the major chains instead.
ERP to Ecommerce Integration
Connecting the back office to the online store.
Shopify ERP Integration
Orders, stock, trade pricing and GST between Shopify and the ERP.
Multichannel Inventory Sync
One stock pool across trade, retail and marketplaces.
Custom API Integration
When the connector you need does not exist yet.
FAQ
Build a Trade Portal Your Reps Will Demonstrate
Book a call. We map your pricing layers, your credit rules and your availability logic, and give you a priced plan. The pricing documentation is yours either way.
All discussions held in confidence. Australian-based consultants.