A price increase means a week of spreadsheets
Ingredient costs have gone up and you have agreed a price increase. Now it has to go out. The foodservice distributor wants their template with their own product codes and case prices. The cash and carry wants a different template, with retail price suggestions. A regional wholesaler wants a PDF. Each has a notice period, and each wants a different effective date.
Someone builds each file by hand from the master spreadsheet, checks it, sends it, and then keeps an eye on the first invoices to make sure the new prices actually went through.
Why every price change is a project
Your prices are yours, but the files belong to each customer, and each one's format, codes and rules are slightly different. None of that is held anywhere except in the files sent last time.
- Customer templates change without notice.
- Each customer uses its own product codes and case descriptions.
- Notice periods differ by customer and are written in trading terms.
- Price lists in accounts and in customer files drift apart.
- Invoice prices are not checked against the agreed effective date.
What it costs
Days of commercial time for each price change. Price increases that start later than they could because the file was late and the notice period restarted. Invoices raised at the old price, or the new one too early, leading to credits and awkward calls. And old price files in circulation with customers because nobody knows which version they hold.
One price list, every format
- A master price list holds each product's price for each customer, with effective dates and history.
- Each customer's product codes, case descriptions and template are recorded once, from the last file they accepted.
- When a price change is approved, the tool generates each customer's file in their own format, in Excel, CSV or PDF, ready for a person to check and send.
- Notice periods from each customer's trading terms are applied, so the tool proposes the earliest effective date for each one.
- The approved prices are pushed to your accounts or ERP with their effective dates, so invoices change on the right day.
- The first invoices after each change are checked against the new prices, and mismatches are listed.
| Customer type | Typical file | Handled by |
|---|---|---|
| Foodservice distributor | Their template, their codes | Generated from master list |
| Cash and carry | Template with RRP column | Generated from master list |
| Regional wholesaler | PDF price list | Generated from master list |
| Your accounts system | Price records with dates | Pushed through API or import |
A price change, done once
Commercial approves a price change once, and the files follow. Notice periods are tracked for you. Invoices change on the right day, and the check afterwards catches any that did not. When a customer asks which prices they were sent, the history answers it.
Sales and credit control also stop working from different lists. The price a customer was told, the price in the accounts system and the price on the invoice all come from the same record, so the monthly round of price queries shrinks to the genuine ones.
New customers get the same treatment from the start. Their template and codes are recorded when they open an account, so the next price change includes them without anyone having to remember they exist.
Does this sound like your price changes?
- Each customer's price file is rebuilt by hand.
- Notice periods are worked out from trading terms each time.
- Invoices have gone out at the wrong price after a change.
- The accounts price list and customer files disagree.
- Nobody is sure which price file a customer last received.