Your Portal Says 40 In Stock. Twelve Of Them Cannot Ship This Week.
ERP and Operational Systems Consultant
Your customer portal shows one number next to each product. Forty in stock.
Your ERP does not hold that number. It holds several numbers, one per warehouse, and something in between added them up before the portal drew the screen.
That addition is where the promise breaks.
The total is an accounting answer
A single on-hand figure is correct. It is also answering a question nobody in a sales conversation is asking.
"How many do we own" is a question for your balance sheet. "How many can I put on a truck to this customer this week" is a question for your rep. They are different questions and they have different answers, and most B2B portals are quietly returning the first one to people who needed the second.
Nothing is broken in the ERP. SAP Business One knows exactly where every unit sits. The loss happens at the join, when an integration asks for on-hand quantity and gets a sum back without the dimension that made it useful.
What the sum hides
Four things, and each one has bitten somebody.
Location. Twelve of those forty are at a site that does not serve this customer's region. Shipping them means an inter-warehouse transfer first, which adds days nobody mentioned on the call.
Commitment. Some of that stock is already allocated to open sales orders. It is physically present and it is spoken for. A total that counts committed stock as available is not describing inventory, it is describing furniture.
In transit. Goods on a purchase order arriving Thursday may or may not be in the number, depending on how the integration was written. Both choices are defensible. Only one of them is true on your screen, and most teams do not know which one they picked.
Minimum levels. Plenty of distributors hold a floor at each site that they will not sell below. That floor is real policy and it is almost never reflected in a customer-facing number.
What it costs when a rep promises from it
Follow the chain, because the expensive part is at the end and it is not the one people expect.
The rep sees forty and commits to a date. Fulfilment discovers twelve are in the wrong building or already allocated. Now somebody pays: an expedited transfer, a split shipment, a partial delivery, or a credit note.
That is the visible cost, and it is the small one.
Here is the real one. The rep stops trusting the portal. Once a screen has burned someone in front of a customer, they stop reading it. They go back to phoning the warehouse to check before they promise anything, because a phone call has never made them look stupid.
You now have a portal that cost real money and an ordering process that runs on phone calls anyway. The system did not fail loudly. It failed by losing the confidence of the only people who were supposed to use it.
That failure never shows up in a report. Nobody files a ticket saying "I do not believe the inventory screen." They just stop looking at it.
What to show instead
Not the total. The total can stay, lower down, for whoever wants it.
Stock per warehouse, named. The rep sees where the units actually are. That one change turns a promise into an informed promise.
Available, not on hand. On hand minus committed minus whatever floor that site holds. This is the number that answers the question the rep was actually asking.
Lead time when the stock is elsewhere. If serving this order means a transfer, say so, with the days attached. A rep who can say "twenty eight ship Thursday, the rest follow Tuesday" has more credibility than one who says forty and delivers twenty eight.
A refresh interval you have decided on deliberately. SAP Business One does not announce changes. It emits no webhooks, so something has to go and ask on a schedule, and that schedule is a business decision about how stale a number may be before somebody quotes from it. Most teams have never made that decision explicitly. It got set by whoever wrote the integration and never revisited.
The objection, which is a fair one
"We do not want customers seeing our warehouse network."
Reasonable. Per-site stock across your whole footprint tells a competitor how you are structured and tells a customer which site to pressure.
You do not have to expose the map. Expose availability at the site that serves this account, plus a lead time for anything sourced from elsewhere. The customer gets a truthful, actionable number. Your network stays private. Internal roles, reps and procurement and warehouse staff, can see the full picture, because they need it and they already work there.
This is a permissions question, not a reason to keep showing one misleading total to everybody.
The test
Open your portal. Pick a product. Write down the number.
Then open your ERP and ask three questions about that same product. Where is it. How much of it is already committed. What is the lead time from the sites that are not local to this customer.
If the four answers do not reconcile, your reps have already noticed. They just have not told you, because they worked around it months ago.
I map how an order actually moves through your systems, find where the manual steps and the misleading numbers are costing you, and hand you a ranked 90-day roadmap with the business impact against each item. Fixed fee, fixed timeline, read-only, and the roadmap is yours whether you build it with me or with your own team.