A Contract Price Book That Stops Leakage Every rate tied to its contract.

A contract price book is a single, searchable record of what you agreed to pay for each item, from each supplier, for each period. It sits between your contracts and your purchase orders, so any price can be checked in seconds.

Most operations already have the information. It's spread across signed contracts, rate schedules in spreadsheets, catalogue uploads in the ERP, and email threads where a rate was varied. Nobody can check a PO against all of that by hand, so mostly nobody does.

A useful price book holds, for every line:

• The agreed rate, with the contract or schedule it came from and its start and end dates.
• The unit of measure the rate applies to (each, box of 10, metre, kilogram).
• The last price actually paid, with the PO it came from.
• The range paid over the last 12 months, so outliers stand out.
• Escalation rules, where a contract allows for annual rises.

Every number links back to the line it came from. If a buyer questions a rate, they click through to the contract schedule or PO line, not to a black box.

Contract leakage is money paid above what was agreed. The contract says one price, the invoice says another, and the gap gets paid because nobody compared them.

It rarely comes from one big mistake. It comes from small gaps that repeat:

• Rates not loaded. A new contract is signed but the ERP still holds the old catalogue price.
• Expired contracts. A contract ends and orders keep flowing at whatever the supplier now charges.
• Unit of measure mismatches. The contract rate is per each, the PO is per box, and the comparison breaks.
• Off contract buying. An urgent order goes to a different supplier, or to the same supplier under a different part description.
• Extras. Freight, surcharges and minimum order fees the contract never allowed for.

Each one is small on a single line. Across thousands of lines a year it becomes a real number. That's why it needs checking by a system, line by line, not sampling at audit time.

For each PO or invoice line, leakage is the price paid minus the contract rate, times the quantity, counted only where the price paid is higher. Then add the lines up.

Leakage per line = (price paid − contract rate) x quantity

Example with made-up figures:

Four lines, $2,906.00 paid above the agreed rate. Nobody can check every line like this by hand on a busy site. A system can check every line, every day.

Two rules keep the number honest. Only count a line where a valid contract rate existed on the order date. And convert units of measure before comparing, or a box of 10 billed against a per each rate will look like a 900% overcharge.

It's built from data you already have. No supplier portal, and no new process for buyers.

1. Collect. Contracts and rate schedules, the item master, and at least 12 months of PO and invoice lines, through read-only access or exports.
2. Match. Link each contract rate to the item and supplier it covers, including where the description differs between the contract and the ERP.
3. Normalise. Convert units of measure, apply escalation clauses, and set the valid dates for each rate.
4. Add history. Attach the last price paid and the 12 month range for every item.
5. Flag gaps. List items bought often with no contract rate at all. These are usually the best place to negotiate next.
6. Review. A buyer checks any match the system wasn't sure about before it's used for flags.

The maths is plain, deterministic code. The AI helps read contract documents and explain results, but it never sets a rate. The contract price book case study shows how this was done for an international tier 1 mining operator, judging quotes against what was agreed and what was last paid.

Every quote line is compared against two things: what was agreed and what was last paid. That turns "does this look right?" into a clear answer with a reason.

The buyer sees the flag, the reason and the source lines. They decide. The same checks run on every PO before it's paid, covered on the PO vs contract rate checking page.

Spend analysis is only as good as what gets counted as spend. Without clear rules, the totals argue with each other and nobody trusts them.

Working with an international tier 1 mining operator, we caught a whole class of wrong spend numbers: quotes and unapproved orders were being counted as spend. One rule fixed it. That kind of problem sits under a lot of spend reports, and you only find it by auditing the data first. The AI data audit case study shows how.

With a price book in place, spend analysis can answer the questions that matter:

• Which suppliers are billing above contract, and on which items?
• Which contracts are expiring with heavy spend still running through them?
• Which high volume items have no contract rate at all?
• How much was paid above agreed rates last month, and which lines can be raised with the supplier for a credit?

For the wider picture on off contract buying, read the guide to maverick spend and three way matching.

Start with a free 15 minute call with Tristan, or send a quick enquiry. Work is charged at a consulting day rate. The price depends on your sites, systems and data, so we talk first, then Tristan sets out what he'd build, how many days it takes and what it costs. An engagement runs like this:

1. 15 minute call. Free, no obligation, no pitch. Tristan asks what you run and what is costing you, and tells you straight whether there is something worth fixing and roughly what it would cost.
2. A look at a sample export. Only if it's useful, and read-only.
3. A clear scope and price. What gets built, how many days it needs and what it costs, in writing, before any work starts.
4. Build inside your systems. In your own Azure, Databricks or Snowflake, with read-only access to source data.
5. Run, check and support. Monthly re-runs, new sites and fixes. A person approves every change.

The price book is usually built alongside stock levels and PO checking, because they share the same data. See the full AI for mining supply chain offer.