How to manage multiple customer price lists without the wrong price reaching the invoice

A janitorial supply distributor sold to three kinds of accounts out of one counter: national chains on a negotiated contract rate, independent cleaning companies on a standard wholesale tier, and a handful of walk-in tradespeople who paid list price. Three tiers, one register, one sheet of paper taped under the counter glass listing which customer got which discount.

It worked, more or less, as long as the same two cashiers who'd memorized the accounts were the ones on shift.

The list under the glass doesn't scale

The distributor added a second location. Then a fourth tier — a seasonal promotional rate for a manufacturer's rebate program, active for some customers and not others, on some SKUs and not others. The sheet under the glass turned into three sheets, then a shared spreadsheet nobody updated consistently, because updating it meant someone remembering to tell every counter every time a customer's terms changed.

The register itself had no idea any of this existed. It had one price per item. Every discount was a manual override, typed in by whoever was working that register, based on whatever they remembered or whatever the customer told them their price was supposed to be.

That last part mattered more than it should have. A customer who knew they got 12% off canvassed a new hire on a slow Tuesday and got told they got 12% off — no system checked whether that was true.

Where it actually broke

It surfaced first as a small one: a national account's rebate window ended on a Friday, and Monday's invoices at both counters still carried the promotional rate, because nobody had pulled the sheet down. Three days of orders went out underpriced before the office caught it reconciling the manufacturer rebate claim against actual sales — the numbers didn't match, and the gap was the exact size of three days of full-price sales that had gone out discounted.

Going the other direction cost more. A long-standing wholesale account, negotiated down to a specific rate on a specific SKU three years earlier by an owner who'd since left, got rung up at list price by a cashier who'd never seen that account before and had no way to know the rate existed. The customer didn't argue at the register — they paid, called their rep afterward, and asked why the contract they'd had in place for three years apparently didn't apply anymore. The rep had to explain that it did, and it was the counter that was wrong.

Two errors, opposite directions, same root cause: the price a customer was entitled to lived in someone's memory or a spreadsheet, not in the system doing the selling. Every sale where the person at the register didn't happen to know the right number was a coin flip between undercharging a customer who wasn't supposed to get a break and overcharging one who was.

The turning point

The owner's first instinct was to write clearer rules and retrain the counter staff. That fixed the two accounts everyone was already talking about. It didn't fix the fact that the correct price for any given customer, on any given item, on any given day, was still information that lived outside the system making the sale — which meant the next new hire, the next promo window, the next negotiated rate change would produce the exact same kind of error, just for a different account.

The actual fix wasn't better memory. It was moving the price list itself into the same system that rang up the sale, so the register could answer "what does this customer pay for this item, right now" without anyone having to know.

What holds up in practice

Attach price tiers to the customer record, not to a cashier's memory. Every account gets an assigned price list or contract rate at setup — standard wholesale, negotiated, promotional, list — and that assignment travels with the customer, not with whoever happens to be working the counter that day.

Let time-boxed rates expire themselves. A promotional or rebate rate should have a start and end date built into the price list, so it stops applying the moment it's supposed to — not whenever someone remembers to take the sheet down.

Resolve conflicts with a fixed rule, not a guess. When a customer qualifies for more than one applicable price — a promo on top of a standing contract rate — the system needs a consistent rule for which one wins, applied the same way every time, not left to whichever cashier is faster at math.

Make an override visible, not silent. Some sales genuinely need a manual price change — a damaged item, a one-off accommodation. That's fine, but it should require a reason and leave a record, not look identical to a normal sale in the reporting.

Keep every channel reading the same list. A route rep quoting a customer and a counter cashier ringing them up should be pulling from the same price assignment, not two systems that can drift apart the moment one gets updated and the other doesn't.

Practical checklist

• Assign every customer a price list or contract rate in the system itself, not a note under the counter glass.
• Give promotional and rebate rates a hard end date so they stop applying automatically.
• Set one tie-breaking rule for overlapping prices, applied consistently across every sale.
• Require a reason code on any manual price override, and review those overrides regularly.
• Confirm counter, route and online sales all draw from the same price assignment per customer.

iotoms attaches a price list directly to each customer account and applies it automatically at every point of sale — counter, route or otherwise — so the rate a customer is entitled to is the rate that reaches the invoice, without a cashier having to remember it.