In B2B commerce, it is no longer price alone that decides, but whether the buyer knows at any time where their order stands. Around 80 percent (Gartner) of buying interactions between suppliers and buyers now run through digital channels, and 44 percent (Forrester) of B2B buyers have already switched supplier because the digital experience fell short. Anyone who still hands out order status only by phone or email loses time and trust at exactly this point. This article shows how picking, partial delivery and invoice status become visible live from the ERP in the B2B account, instead of ending up in the customer service queue. New for 2026 is the wave of self-service customer portals with which manufacturers and wholesalers give their customers real-time access to material and order status (Perzeptron/Limtronik). The key is to build this status return channel without creating a new, competing data silo.
Key takeaways
- Around 80 percent (Gartner) of B2B buying interactions run through digital channels, and 44 percent (Forrester) of buyers have already switched supplier because of a weak digital experience. Order status is a particularly sensitive point within it.
- 61 percent (Bitkom) of companies cannot fully exploit their data potential because information sits in unconnected systems: the current state lives in the ERP, the customer account does not know it, so the customer calls and the sales desk looks it up.
- Order progress is derived from concrete ERP events and mapped onto understandable stages: accepted, in picking, packed and ready to ship, shipped, delivered and invoiced, each stage carrying a timestamp.
- Partial deliveries belong in the account line by line, with shipped, open and backordered quantities kept apart instead of merged into one order total. Together with the invoice status from the finance module, the account answers the most common query by itself.
- The ERP stays the single governing source and the customer account only reads. Middleware and a lean status API instead of a full export prevent a second data silo; time-critical changes are pushed as events, less critical ones follow on a short cycle.
Why Order Status Becomes a Service Lever
B2B buying has shifted fundamentally in just a few years. Decision-makers now move across an average of ten different channels (McKinsey) before placing an order, and more than two-thirds (McKinsey) of them prefer digital self-service or remote contact over the classic field-sales visit. At the same time, 73 percent (Forrester) of younger decision-makers from the Millennial and Gen Z generations are involved in B2B purchases, and 33 percent (Gartner) want a largely seller-free buying experience. Order status is a particularly sensitive point in this journey: once the order is placed, the customer wants to know whether the goods are being picked, when they will ship and how the invoice stands. If this information is handed out only by phone, friction arises exactly where the buying decision has already been made.
The bottleneck rarely lies in the willingness to inform, but in the data behind it. According to Bitkom, 61 percent (Bitkom) of companies cannot fully exploit their data potential because information sits in unconnected systems. This hits order status directly: the current state lives in the ERP, but the customer account in the shop does not know it. So the customer calls, the sales desk looks it up in the ERP and passes the state on verbally. This detour costs time on both sides and is error-prone. A live account reverses the flow: the status moves automatically from the ERP into the account, and the inquiry disappears.
Order Progress
From order confirmation through picking to shipping: every step visible with a timestamp and a status the customer understands.
Partial and Combined Deliveries
Which line item has shipped, which follows: partial deliveries and backorders kept clearly apart instead of in one order total.
Invoice and Payment Status
Invoiced, open or paid: the document status comes straight from accounting into the same account.
Shipment Tracking
Tracking number and delivery status from the carrier, without a second portal login and without an inquiry.
Reorder from History
View earlier orders and trigger them again in a few clicks, including the most recently valid terms.
Proactive Notification
Status changes trigger automatic emails or portal notices before the customer even has to ask.
Making Picking and Order Progress Visible
The most important building block of a live account is order progress. It translates the internal processing steps from the inventory system into a status display the customer understands. What matters is less the technical detail than clear, reliable stages. Every stage arises from a concrete event in the ERP: the release for picking, the completion of the pick list, the handover to shipping. These events are mapped to clear status values and given a timestamp, so the customer can read the progress without interpretation.
- Order accepted: The order is created in the ERP, checked and released for picking; the customer sees the receipt with a timestamp.
- Being picked: The warehouse gathers the line items; the progress can be broken down to the number of items already picked.
- Packed and ready to ship: The goods are picked and wait for handover to the carrier.
- Shipped: The handover creates the tracking number, which appears in the account together with the shipping and logistics status.
- Delivered and invoiced: After delivery the order is marked as completed and extended by the invoice status.
Representing Partial Deliveries Correctly
In B2B, partial delivery is the rule rather than the exception. An order of twelve line items is rarely shipped complete in one go; part is in stock, another is backordered or drop-shipped directly from the supplier. A status display that only knows the order as a whole becomes useless here, because it lists an order as open even though its largest part has long reached the customer. The live account must therefore break the status down to the individual line item: which quantity has shipped, which follows and which is on backorder. Only this granularity makes the display reliable and answers the question about the remaining balance on its own.
Keep Backorders Separate
Invoice Status and Payments in the Account
After shipping, the buyer's interest does not end, because now the commercial side follows: is the invoice issued, is it open, is it paid. Since around 80 percent (Gartner) of B2B buying interactions now run digitally, customers expect the document status in the same account rather than in a separate email. The invoice status comes from accounting or the finance module of the ERP and is mirrored into the account just like the delivery status. Clean matching of incoming payments matters so that an already settled document does not keep showing as open; how this reconciliation works is described in detail in the article on payment reconciliation with the ERP.
Bringing the Status Into the Shop Without a New Silo
The biggest concern of many retailers is that a customer portal becomes yet another system that holds its own data and drifts apart from the ERP. That is exactly what must be avoided. The status return channel is therefore built so that the ERP remains the single leading source and the account only reads. The customer account stores no order state of its own, but queries it on demand or receives it by event. This creates no second data set that would have to be maintained and reconciled.
This applies especially when the status comes from a grown or older ERP. The return channel should be designed to survive a later system replacement, such as the end of maintenance for older SAP systems. A cleanly encapsulated interface can be repointed to a new backend without having to rebuild the customer account.
- ERP stays leading: Order, delivery and document data are created in the ERP; the customer account reads them instead of storing a second truth.
- Middleware as the return channel: A middleware collects status changes from the ERP and makes them available to the shop over a clearly defined interface.
- Status API instead of full export: The shop queries the status per order over a lean API rather than mirroring entire data sets.
- Events instead of constant polling: Status changes are preferably reported by event; when webhooks pay off over polling is shown in the article on webhooks and polling.
- Permissions and visibility: Every customer sees only their own orders; the assignment follows the customer data synchronization.
Phone Inquiry Versus Self-Service
The benefit becomes visible in a direct comparison. As long as the status is handed out only on request, it is tied to business hours and to the availability of the sales desk. Self-service in the account decouples the answer from this and makes it available around the clock, at the timeliness of the ERP. Since more than two-thirds (McKinsey) of buyers expect digital self-service, this is not a comfort extra but an expectation of the provider.
| Criterion | Phone and email inquiry | Live status in the account |
|---|---|---|
| Availability | Only during business hours | Around the clock in the account |
| Timeliness | Manually researched interim state | Straight from the ERP, in real time or short cadence |
| Effort | Ties up the sales desk per request | Self-service without extra staff |
| Partial deliveries | Hard to follow on the phone | Visible line item by line item |
| Invoice status | Requires a query to accounting | Document status directly in the account |
| Error rate | Transcription errors and misunderstandings | One source, no manual transfer |
Real Time or Cadence: Updating the Status
Not every status value needs the same cadence. A change from shipped to delivered is time-critical because the customer checks at that very moment; the transition from open to paid may follow at a short interval. In practice a staggered strategy works well: time-critical events are reported immediately by event, less critical ones reconciled at short intervals. Since 44 percent (Forrester) of B2B buyers have already switched supplier over a weak digital experience, the effort for a timely, reliable update pays off.
The cadence is always a compromise between timeliness and system load. Polling every status value by the second burdens the ERP and interface unnecessarily; too loose a cadence lets the display age and provokes exactly the inquiry it is meant to avoid. An event-driven link resolves this conflict because it sends only on actual changes and keeps the rest in a calm reconciliation.
One Source, Many Channels
Implementation Step by Step
- Define the status model: Decide which order states (accepted, being picked, shipped, invoiced) the customer should see and how they are derived from the ERP fields.
- Clarify data sources: Check which systems hold order, delivery and document; for separate systems, a look at bidirectional synchronization helps.
- Build the return channel: Set up middleware and a status API and define whether status changes are transferred by event or at short intervals.
- Test visibility and permissions: Make sure every customer sees only their own orders, and check partial deliveries and backorders against real cases.
- Monitor and extend: Watch the return channel with interface monitoring and add further status details after launch.
An order is only well looked after when the customer can see its state themselves, without calling. Mirror the status from the ERP into the account and you turn transparency into service.