Counter and will-call sales look like the easy part of distribution. Somebody walks in, takes product, pays or charges it to an account, and leaves. No routing, no delivery window, no proof of delivery. In practice it is the transaction most likely to leave the rest of the system slightly wrong, precisely because it is fast and because it bypasses the workflow everything else runs through.
Inventory that is already gone
A delivered order reserves stock, gets picked, and ships. Each step is a checkpoint. A counter sale compresses all of that into one moment, often after the material has physically left. If the counter is transacting against a different view of inventory than the warehouse — a separate point-of-sale, a spreadsheet, or a paper ticket entered later — then the available-to-promise number is wrong for as long as it takes somebody to key it in.
That window is where the classic failure lives: an order is promised against stock that walked out the front door an hour ago. Nobody did anything wrong. The system simply had two doors and only counted one of them.
Pricing that does not match the contract
Contractor pricing is rarely a single discount. It is tiers, customer-specific price books, quantity breaks, and sometimes job-specific pricing negotiated for one project. All of that is understood by the order desk and encoded in the order entry system.
At the counter, under time pressure, it is often understood by a person. The result is not usually a large error — it is a small one, repeated. Margin erodes a point at a time, and because the transactions are small and numerous, it does not show up as an incident. It shows up as a quarter that came in under plan for no obvious reason.
The unit-of-measure trap
Industrial and building products carry conversions that are not clean: each, box, pallet, linear foot, hundredweight. A counter sale of three hundred feet of something stocked in twenty-foot lengths and priced per hundred feet involves two conversions, and doing them mentally is how a system ends up with fractional pieces it cannot reconcile.
This compounds with fabrication. If the counter sells from the same stock the saw is consuming, and both are converting between units independently, the physical count and the system count diverge in a way that a cycle count corrects but never explains.
What handling it properly means
The requirements are unglamorous and mostly amount to the counter not being a special case.
It should draw on the same inventory as delivered orders, so a sale is reflected everywhere the instant it happens. It should apply the same pricing engine, so contractor tiers and customer price books are enforced rather than remembered. It should handle unit conversion natively, so nobody is doing arithmetic at a keyboard while a customer waits. It should post to the same ledger, so counter margin is visible next to delivered margin rather than in a separate report. And when a line cannot be filled from stock, converting it to a drop-ship or special order should not mean starting the transaction again.
None of that is a counter feature exactly. It is what happens when the counter is a way of fulfilling an order rather than a parallel system that sells things. More on how that fits with fabrication and delivery on the industrial distribution page, and on the warehouse side in warehouse management.