← All articles
Pricing Systems

One Record, Not Five Systems

The first job on the list in the last piece was to keep one record of every commercial term. Its sample line was a simple test: when a price changes at 9 a.m., everyone who creates a quote, sends an invoice, or pays a rebate against it would see the same number by 9:05, without anyone forwarding a file.

Very few mid-sized manufacturers or distributors pass that test today, and most of them know it. Ask a plain question like “what does this customer pay for this product?” and the answer depends on who you ask. Sales checks the price file. Customer service checks the ERP. Finance checks the report, which includes the rebate allocations, and whoever negotiated the last agreement goes looking in their inbox. Each answer comes back with what they believe the answer is, but the answers often don’t match.

This piece is about why that happens and what it takes to fix it.

Where the record lives today

At most of the companies we work with, commercial terms are spread across roughly five places.

  1. The ERP (often considered the system of record for price) holds the price that gets invoiced, along with whatever discount structure someone managed to configure when the system went in.
  2. A shared folder holds the price files: list prices, customer price sheets, and the “master” workbook that contains the price setting logic.
  3. Contracts and special pricing agreements sit as PDFs, sometimes in a CRM or contract tool, often in a folder named after the customer.
  4. Rebate and incentive terms live in a finance or accounting spreadsheet, because that’s where the accruals get calculated.
  5. The exceptions (one-off approvals, the “match the competitor on this job” email, the freight waived for a good customer) live in inboxes and chat threads.

Each of these was set up by a different team for a different purpose, and each does its own job reasonably well. The trouble is that none of them is required to agree with the others, and nothing checks whether they do. Five different perspectives on price, that usually don’t agree or tell the same story.

One question, five places

“What does this customer pay for this product?”

Today

  • ERP
  • ≠
  • Price file
  • ≠
  • Contract
  • ≠
  • Rebate sheet
  • ≠
  • Inbox

Five answers.

One record

Every term, defined onceeffective-dated · owned · traceable
  • ERP
  • Price file
  • Contract
  • Rebate sheet
  • Inbox

One answer.

How five records drift apart

The drift is rarely dramatic. It builds up through ordinary gaps that nobody owns.

Timing is the most common. A list price update takes effect on the first of the month in the price file and on the fifth in the ERP, once someone gets around to loading it. The contract that promised to hold pricing through year-end may never hear about it at all. For a few weeks, or indefinitely, the company has more than one valid price for the same item.

Identifiers come next. The ERP knows the customer by a bill-to account number, the contract names the parent company, and the rebate workbook groups customers by buying group. A supplier’s special pricing agreement lists the supplier’s part number, which has to be mapped to your own SKU before anything can be matched.

Units of measure add another layer. A contract priced per case and an invoice billed per each look like a 90% discount until somebody notices, and plenty of reports are built before anybody does.

Then there are terms that exist in only one place. Supplier-funded special pricing is a good example in distribution. The invoice shows a sale at or below cost, and the support that makes the line profitable arrives later as a claim against the supplier, recorded somewhere else. In a recent engagement, ERP invoice lines sold under supplier agreements showed a negative gross margin in the invoice data. Once the supplier support (SPA rebates) was matched back to each customer and SKU, the same lines carried a pocket margin above 11%. Nobody had made a mistake; the pricing wasn’t “wrong”. The two halves of each deal were recorded in different systems, and nothing joined them.

That example is worth a second look, because the cost of drift runs in both directions. Disconnected records hide leakage, which most people expect. They can also make healthy business look unprofitable, and that leads to the wrong conversation with the wrong customer. Both are bad.

What one record actually requires

“One record” can sound like a call to replace the ERP, and that worry is one reason many companies never start. Don’t worry, your CIO can relax; replacing the ERP isn’t required. The ERP still invoices, and contracts still get signed in whatever tool legal or Sales Ops prefers. The change is that every commercial term is defined once, in one governed place, with an effective date and someone accountable for it. Every other system either reads from that record or gets reconciled against it.

In practice that comes down to a few unglamorous pieces of work.

Customers, products and suppliers get mapped once, including bill-to to parent, buying group membership, supplier part number to your SKU, and unit of measure conversions. Every downstream join then uses the same keys instead of each analyst rebuilding them.

Every term carries a start date and an end date, so “what was this customer’s price on March 3?” has exactly one answer, and an agreement that was supposed to expire actually does.

Each kind of term has a named owner who is allowed to change it, and every change leaves a trail of who made it, when and why.

Transactions link back to the terms that priced them, so an invoice line can tell you which price and which agreement or rebate program applied to it.

This is the part of a pricing project that takes the longest and gets the least time in a demo, which is why it so often gets underscoped. It’s also the part that decides whether everything built on top of it can be trusted.

Why it has to come first

Every other job from the last piece reads from this record. Margin leakage analysis needs the invoice line joined to the rebate and the agreement behind it, or the pocket margin is simply wrong. Sizing a cost change means knowing which customers have price protection and until when. A recommendation is only as good as the terms it was built on, and an audit trail can only trace back to a record that exists.

Companies that skip this step and go straight to analytics tend to rebuild the join by hand every time a new question comes up. That’s the spreadsheet problem again, with a nicer front end.

Where to start tomorrow

You can measure how far apart your records are in an afternoon. Pull ten invoice lines from last month, from different customers, and include at least a couple sold under (or with) a special agreement or a rebate program. For each line, write down the price according to the ERP, the current price file, the contract or agreement, and the rebate terms that should apply. Then note where they disagree and which source turned out to be right.

It’s common to find a few lines where the sources disagree and nobody can say with certainty which one is correct. That short list is a strong way to open the conversation with finance and IT about where the record should live and who should own each part of it. It also gives you a baseline to measure against once the work starts.

Next in the series: finding the margin leak before quarter-end finds it for you.

At Revomo, this record lives in the Data & Context Studio, which is part of every subscription. If you run the ten-line test and would like help reading the results, we’d be glad to compare notes. The first look is on us.

Read next

Next in the series

Finding the Leak Before Quarter-End Finds It for You

7 min read ·
More on Pricing Systems

The Six Things a Real Pricing System Has to Do

7 min read ·
More on Pricing Systems

Admitting the Spreadsheet Is Broken Is the Easy Part

8 min read ·
Plate B2 · Series 2026