The cart total and the invoice have to be the same number
The most damaging bug in trade ordering is not a crash. It is a cart that quietly disagrees with the invoice, and it has one common cause.
Ask a distributor what went wrong with their last ordering system and you will rarely hear about downtime. You will hear about the week the portal quoted one price and the invoice charged another, and about the customer who noticed first.
Where the second number comes from
A trade cart has to feel fast, so the obvious approach is to work the price out in the browser: send down the price list, apply the rules in JavaScript, update the total on the spot.
That works until pricing has more than one layer, which in distribution it always does: a base list, the account's price book, a negotiated line, a quantity break, a promotion running this week. Now the logic exists twice, once in the browser and once where the invoice is produced, and the two copies must agree forever.
They will not. Someone fixes a rounding rule in one and not the other. A promotion expires at a different moment in each. A break applies per line in one and per order in the other. Each is a small bug that produces a wrong invoice.
The fix is boring
Price the cart on the server, in the same code that prices the invoice. The browser asks what the cart costs and displays the answer. One implementation, nothing to disagree with. The cost is a network round trip when a quantity changes, which is imperceptible and a very cheap price for never having the screenshot conversation.
Ask a vendor: when I change a quantity, is the new total calculated in my browser or asked for from your server? If it is the browser, ask how the two implementations are kept in step.
It protects your rates too
Anything the browser computes, a customer can read. If price book eligibility lives in JavaScript, it is visible to anyone who opens developer tools, and your account-by-account discount structure is on display. Resolving server-side means the browser only ever learns what that account pays for what that account can see.
How to check it in a demo
- Add a line with a quantity break and step the quantity through the break point. Watch whether the price changes instantly or after a beat.
- Ask to see the same order as a cart and as an invoice, side by side, on an account with a negotiated rate.
- Ask what happens if a price changes between a buyer filling their cart and submitting it.