Pricing is where route accounting implementations run over budget. Not because the software cannot do it, but because the business has never written down what it actually does, and discovers the true complexity halfway through configuration.
Start by documenting reality
Before you look at a product, extract every distinct pricing mechanism in current use. Interview sales, finance and two long-serving drivers separately — they will each describe different rules.
Typical inventory of mechanisms in a mid-sized distributor:
- National list price
- Channel price lists (convenience, wholesale, foodservice, forecourt)
- Customer group prices
- Customer-specific contract prices on named SKUs
- Volume breaks by line and by order
- Temporary price reductions with date ranges
- Multi-buy deals
- Free-goods deals
- Retrospective volume rebates
- Retailer-funded promotions with agreed cost splits
- Introductory and listing allowances
- Delivery charges, minimum order surcharges, fuel surcharges
- Container deposits and returns
Nearly every business finds at least two mechanisms that exist only in someone's head. Those are the ones that break configuration in month four.
"Why is this customer paying £8.40?" must be answerable in the system, showing which rule applied and which were superseded.
The resolution hierarchy
The software must decide which price wins, deterministically, every time. A workable hierarchy, most specific first:
- Customer + SKU contract price
- Customer + SKU promotional price
- Customer group + SKU price
- Channel price list
- National list price
Then apply, in order: volume breaks, deals, then order-level discounts and surcharges.
The key requirement is that the same input always yields the same output, and that a user can see why a given price was applied. A pricing engine without an explanation feature generates weekly disputes that consume more time than the configuration ever saved.
Deal types and how they behave
| Deal | Mechanic | Complication |
|---|---|---|
| Temporary price reduction | Lower price for a date range | Overlapping promotions, priority rules |
| Multi-buy (3 for 2) | Quantity-triggered discount | Partial quantities, mixed SKU baskets |
| Free goods | Extra units at no charge | Stock movement and tax treatment |
| Bundle | Fixed price for a mixed group | Reporting margin at line level |
| Retrospective rebate | Payment after volume achieved | Accrual, timing, dispute risk |
| Listing allowance | Fixed payment for shelf presence | Not a price at all, but often modelled as one |
Free goods deserve care: the units must move out of van stock, they usually have a tax treatment, and margin reporting must attribute the cost to the promotion rather than showing a random gross margin collapse on a normal line.
Promotional funding and accountability
In supplier-distributor relationships, promotions are frequently funded partly or fully by the brand owner. The system needs to track:
- Which promotions are funded, by whom, at what rate
- Claim generation against actual sales
- Evidence requirements — photos of displays, compliance checks
- Accruals for retrospective rebates
- Settlement of claims and disputes
Unclaimed promotional funding is a widespread, quiet margin loss in distribution. Businesses that automate claim generation from sales data routinely recover amounts that surprise their own finance teams.
Keeping the configuration maintainable
Pricing configurations rot. Common causes and controls:
Promotions with no end date. Require an end date on every promotion; run a monthly report on anything active for more than 90 days.
Customer-specific prices that outlive their reason. Attach an owner and a review date to every contract price. Review annually.
Overlapping rules with unclear priority. Keep the hierarchy shallow. Every additional layer multiplies interaction cases.
Undocumented exceptions. Require a reason field on any manual price rule, and report on rules with no documented justification.
No margin monitoring. Run a monthly report of lines sold below target margin, grouped by rule. This is how you find the promotion that never ended and the contract price set for a customer who has since tripled in size.
Testing pricing before go-live
Build a test pack from real invoices:
- 20 normal invoices across customer types
- 10 invoices with active promotions
- 5 with overlapping promotions
- 5 with volume breaks
- 5 with credits and returns
- 5 edge cases: minimum order, delivery surcharge, deposit, tax exemption, free goods
Run them through the new system and compare line by line with the historical invoice. Any discrepancy is either a configuration error or an undocumented rule you have just discovered — both are worth finding before go-live rather than in front of a customer.
Questions readers send us
How complex should our pricing be? Less complex than it currently is, almost certainly. Every mechanism carries configuration cost, dispute risk and margin opacity. A rationalisation exercise before implementation frequently pays for itself in reduced configuration effort alone.
Should drivers be able to apply discounts? Within a small, reason-coded, reported limit. Some flexibility prevents refused deliveries and lost sales; unlimited authority produces margin erosion that nobody notices until an annual review.
How do we handle price increases? With a scheduled effective date, advance customer notification, and a report of which customers are protected by contract prices that override the increase. That last report is the one most often forgotten, and it is the reason price increases frequently deliver less than forecast.
Can promotions be planned in the route accounting system? Some products include promotional planning; many expect promotions to be defined in the ERP or a trade promotion management system and imported. Decide where the master lives before configuring, and enforce it — dual maintenance of promotions is a reliable source of pricing errors.
What is the most common pricing configuration mistake? Overlapping promotions with no defined priority, producing a price that is technically correct according to the rules and completely unintended by the person who set them up. Priority rules should be explicit, documented and tested.
