A distribution company came to us convinced they had a sales problem. Revenue was growing, order volume was up, and yet margin kept slipping quarter over quarter. Nobody could point to a single cause. This pricing automation case study is about what we found when we stopped looking at the top line and started looking at individual invoices instead.
The answer wasn't a bad deal, a rogue salesperson, or a pricing strategy mistake. It was smaller and more boring than that. Every order was priced manually against a spreadsheet, and that spreadsheet was wrong in tiny, inconsistent ways, all day, every day.
That is the uncomfortable truth about margin leaks. They rarely look dramatic. They look like nothing at all, until you add up twelve months of nothing.
The leak nobody could see
The company sold building materials to a network of retail and project buyers, roughly 400 SKUs, with price tiers by customer type and volume discounts layered on top. Sales staff quoted from a master price list in a shared spreadsheet, updated by finance whenever costs or promotions changed.
Three things were happening at once:
- Sales reps sometimes worked from a cached copy of the price list that was a version or two behind.
- Discount rules were applied by memory ("this customer always gets 8%") rather than by lookup, and memory drifted.
- Promotional prices that should have expired kept getting honored weeks after the promotion ended, because nobody removed them from the quoting habit.
None of these errors was large. A wrong price here was 1-2% off. A stale discount there was a few percentage points. Individually, sales staff would have defended every one of these as a reasonable judgment call. Collectively, across roughly 3,000 orders a month, it added up to margin erosion in the tens of millions of rupiah, month after month, invisible in any single transaction and invisible in the monthly P&L review too, because it was baked into "cost of goods" assumptions nobody re-checked.
We found it the unglamorous way: by pulling a sample of 200 recent orders and manually recalculating what each should have cost against the current authorized price list. Two in five orders had a pricing discrepancy. That ratio, applied across full volume, matched the margin decline almost exactly.
Why manual pricing always drifts
This is not a story about careless staff. It is a structural problem that shows up in almost every distribution or B2B sales business once the SKU count and customer tier count both grow past what one person can hold in their head.
A price list is a snapshot. The moment it's exported to a spreadsheet, printed, or memorized, it starts decaying. Costs change, promotions expire, exceptions get approved for one customer and then get applied to others by accident. There is no natural moment where an outdated price gets flagged, because the person quoting the price has no way to know it's outdated. They're not negligent, they simply don't have the right information at the point they need it.
This is the same failure mode we describe in Build vs Buy Software: A Decision Framework for Owners: the cost of a process gap doesn't show up as a line item, it shows up as a slow, distributed tax on everything the process touches.
The fix: one validation rule, not a new system
The instinct in situations like this is to propose a full pricing engine, a new ERP module, or a dedicated pricing team. All three were on the table in the first meeting. All three were overkill.
What actually fixed it was a single validation layer inserted at the point of order entry:
- A single source of truth for price and discount rules, stored in a database table instead of a spreadsheet, with every change timestamped and attributed.
- A hard validation check at order confirmation: any quoted price that deviates from the authorized price and approved discount tier gets blocked, with the deviation and reason surfaced to a supervisor before the order can proceed.
- Automatic expiry on promotional pricing, so a promo price cannot be applied past its end date without an explicit override, which is itself logged.
- A weekly exception report, so finance could see, at a glance, every order that needed an override and why, instead of discovering the pattern six months later.
None of this required machine learning, a new frontend, or months of build time. It required treating pricing as data with rules, not as a spreadsheet with tribal knowledge attached to it. This is squarely in the territory covered in Subscription Creep: The Silent Leak in Your Tech Budget, where the recurring theme is the same: the leaks that hurt most are the ones nobody is deliberately causing.
What changed in the numbers
Within the first full month after the validation layer went live, override requests ran at about 15% of orders, mostly legitimate one-off negotiated deals that now had a paper trail instead of a memory. Within three months, that number dropped closer to 5%, as sales staff adjusted their habits knowing the system would catch drift.
Margin on the affected SKU categories recovered to within a point of the target the finance team had modeled a year earlier and had quietly stopped expecting to hit. No pricing strategy changed. No customer was renegotiated. The only thing that changed was that the price actually charged matched the price that was supposed to be charged.
The takeaway for any business running on spreadsheets
If your business quotes prices from a spreadsheet, a printed list, or "what we usually charge this customer," you almost certainly have a version of this leak, and it is worth a half day of manual sampling to find out how big it is before assuming it's not.
You do not need a full system overhaul to fix it. You need one validation point where price meets order, and a rule that anything outside the authorized range gets flagged before it ships, not discovered after. If you want a second pair of eyes on where your own pricing or order process might be leaking margin quietly, that's a conversation worth having at /partner.