B2B customer portal: what should it read from and send to your ERP?

What does a B2B customer portal need from the ERP?

A B2B customer portal is a signed-in website where a business customer’s buyers see their own prices, place and repeat orders, track deliveries, and download or pay invoices. Almost everything the buyer looks at is already a record in the seller’s ERP: the customer account, the negotiated price, the credit position, the order, the shipment and the invoice. The portal is a window onto those records, plus a way to send requests back.

That is why a portal project is mostly an integration project. The screens can be configured in weeks. The work that decides whether buyers trust the portal is mapping each record, agreeing which system may change it, and handling the answers the ERP gives. This guide is for distributors, wholesalers and manufacturers that sell to trade accounts and already run an ERP. If you are still choosing the portal itself, the B2B buyer workflow test and the B2B ecommerce platform comparison come first.

Which system should own each portal record?

Each record needs one owner: the system where it is created and corrected. Other systems may display it or ask for a change, but they do not change it themselves. In most trade businesses the ERP owns the commercial and financial records, and the portal owns who can log in and what each person may do.

Two rows cause most of the trouble. The first is the split between a person and a company. A buyer’s email address is a portal user, not a new customer. If self-registration creates an ERP customer for every sign-up, finance ends up with three accounts for one business and three separate credit limits. Link each user to an existing ERP customer and contact, and keep new sign-ups pending until sales or finance approves them.

The second is the order. While the buyer is building a cart, the portal owns it. Once it is submitted, the ERP decides whether it becomes a sales order, and the portal must show that decision rather than its own. A portal that shows “confirmed” because it sent a message has made a promise the ERP has not.

Should prices and stock sync on a schedule or be checked live?

A portal can get ERP data in two ways. It can receive a published copy (the ERP sends price lists or stock levels when they change, or on a timer) or it can ask the ERP live, at the moment a buyer opens a page or the cart. Published data is fast and keeps working if the ERP is slow or down, but it can be out of date. Live checks are current, but every page view becomes an ERP request, and the portal stalls when the ERP does.

Whichever route you choose, agree the price rule before launch: if the price changes between the cart and the ERP’s acceptance, which price stands? A workable rule is that the portal sends the price it showed, the ERP reprices on acceptance, and any difference comes back as “accepted with changes” for the buyer to see. A silent change becomes a dispute when the invoice arrives.

How does a portal order become an accepted ERP order?

The illustrative order below comes from a contractor account, customer C-2041, with three branches. A buyer at the Eastside branch orders three lines under the company’s purchase order 7781. One line is above the buyer’s spending limit, and the account is close to its credit limit.

The answer back to the portal matters as much as the order going in. Agree a short list of states, what the buyer sees for each, and who acts next:

Should the portal show phone, email and EDI orders, invoices and payments?

Yes. A buyer does not care how an order reached you. If the portal shows only orders placed in the portal, buyers still phone to ask about the rest, and much of the reason to build it disappears. Read order history from the ERP, where every channel ends up, and show each order with the buyer’s PO number, because that is the number the buyer searches for. Reorder from history should copy the ERP lines and then reprice them, not reuse last year’s price.

Invoices and payments need the same care. Show open invoices, credit notes and the balance from the ERP’s receivables records. When a buyer pays in the portal, the payment must reach the ERP, be applied to the right invoices and update the available credit. If the payment provider confirms the payment but the ERP never applies it, the next reminder letter goes to a customer who has already paid. The payment reconciliation guide shows how to trace each card payment through the provider’s payout to the bank.

For distributors whose portal is one of several order routes alongside sales reps, email and EDI, the wholesale order management guide shows how all of those routes land in the same ERP order process. Sales reps need the same history in their CRM; the CRM and ERP integration guide covers that side.

How do you test a B2B portal and ERP integration before launch?

Run these tests with real customer accounts, price lists and stock copied into a test environment, not with demonstration data. Write the expected result for each one before it runs. Most of them are failures on purpose, because the normal order is the one most likely to work already.

Test 2 is a security test, not an integration detail. The 2025 edition of the OWASP Top 10 ranks broken access control first among web application risks. In a portal it means one customer seeing another’s contract prices. Check it on every page that takes an order, invoice or account ID.

How do you roll out a B2B customer portal without disrupting orders?

Budget for the work that continues after launch: someone to approve new users and addresses, keep price lists current, and clear the failed-message queue every day. A portal with nobody watching its exceptions slowly sends buyers back to the phone. The e-commerce and B2B service describes how Harmatiq plans and connects buyer portals, and the ecommerce ERP integration guide covers the message design, retries and reconciliation behind every handoff above.