How to Prevent Contract Leakage on Supplier Invoices

Your ERP can pay an invoice that breaks your contract without raising a single flag. This guide shows how to separate real overcharges from false alarms and fix the causes before they repeat.

Contract leakage is negotiated value lost when purchases or payments do not follow the governing agreement, including off-contract buying and overpayments. On supplier invoices, this guide calls above-contract pricing invoice price leakage: a line billed above the agreed price after applying amendments and normalizing units, currency, and included charges. It becomes a financial loss only if paid. SAP's invoice price variance and Dynamics 365's two-way matching compare invoices with purchase orders. A contract leakage review compares each invoice line with the contract itself, catching orders raised above contract even when the invoice matches the PO. Prevention means checking unpaid invoices, assigning each flag a disposition, and fixing recurring causes.

Four supplier invoice lines were flagged in the same week, and a quick comparison put the overcharge at $16,870. But only $1,000 of it was real.

This gap between the alarm and the truth is the challenge in finding invoice price leakage. Most of the work is telling a real overcharge from a data problem that only looks like one.

The quieter problem runs the other way, because some real overcharges never raise a flag at all.

• SAP measures price variance against the purchase order rather than the contract.
• Microsoft Dynamics 365's two-way matching compares the same two prices.

So an order raised above the contract price produces an invoice that matches it perfectly. The variance reads zero, and nobody looks twice. Unlike invoice price variance, this review compares each invoice line with the governing contract itself, on the same unit and currency basis.

Getting this wrong costs money in both directions, because leakage that nobody finds is paid for good, while leakage claimed on weak evidence comes back as supplier disputes and savings figures that finance has to walk back. This is why the method below keeps three stages apart:

• a detected discrepancy, where the numbers disagree
• an approved claim, which the contract owner and procurement agree the terms support
• a documented financial outcome, such as a credit, a refund, or a payment that was stopped.

The method in brief:

1. Start with unpaid invoices in one category, so a real overcharge can still be corrected before the cash leaves.
2. Compare each line with the governing contract and its amendments, not with the purchase order.
3. Put both prices on the same unit, currency, and charges before comparing them.
4. Sort every flag into one of four outcomes, which this guide calls the four-disposition review: reconciled, record correction, commercial review, or unresolved.
5. Fix each recurring cause at its source, and count every stage of recovered value only once.

Here are the four lines. They are synthetic, built to show the mechanics, and each one returns in every section below.

Read naively, that is $16,870 of apparent overcharges, but worked properly it is one $1,000 finding for commercial review, one wrong internal record, one false alarm, and one line nobody can judge yet. By the end of this guide you will know which line is which and why, and you will have a review template to run the same check on your own invoices.

Where should a contract compliance review of supplier invoices start?

• Start with one category, a defined set of suppliers, one review period, and begin with unpaid invoices wherever you can. A paid overcharge can only be recovered, while an unpaid one can still be corrected before the cash leaves.
• Write down the scope first, including any deliberate exclusions and any documents known to be missing.
• Give every invoice line a stable identifier, because joins between invoice, purchase order, and receipt tables multiply rows easily, and one line counted three times triples the apparent exposure.
• Then choose the baseline, since each one answers a different question. The purchase order shows whether the supplier billed what was ordered, the price master shows whether the invoice matches what the system believes, and standard cost shows whether the price matches the budget.
• Only the governing agreement shows whether the price matches what was negotiated, which is the question this review asks. Where no agreement can be found for a line, record a coverage gap rather than falling back to the purchase order.

The four lines in this guide follow exactly that scope: one direct-materials category, one week, all unpaid.

Which contract terms govern each invoice line?

The governing terms are the agreement plus every amendment, schedule, and approved change that applies to that supplier, legal entity, and material or site, on the date the agreement says governs pricing, which usually means reading well past the original contract.

• Match on the supplier and legal entity, the material, the covered site or scope, and each price's effective dates.
• Then check which date the agreement uses, because some agreements price on the order date and others on shipment or delivery.
• An invoice that straddles a price change can be right under one reading and wrong under another, so the agreement decides rather than the ERP default.
• Watch in particular for provisional prices billed at an interim rate pending a final one, and for expired price conditions that stay in use because nothing replaced them.

Agreements change often enough that a price master loaded once will drift. A 2020 amendment to the agreement between DecisionPoint Systems and Kaiser, filed with the SEC requires quarterly updates to the price exhibit as needed. It also requires tariff-driven price increases to be approved and documented through a contract amendment before taking effect, and another amendment within 45 days if the tariff is later removed or decreased. Each change is a moment when the price master either gets updated or falls behind.

This is Line B's story (from the table above), and it is the first surprise in the case. An approved amendment moved the price to $10.40 and Line B follows it, but the stored price never caught up. The invoice is right and the record is wrong, so the fix belongs to master data, not to the supplier.

How do you compare invoice and contract prices on the same basis?

Convert both prices to the same unit, price unit, currency, and included charges before comparing them, using a documented conversion factor for that material, and keep the original values visible for the reviewer.

Units cause many false alarms, because a line can be invoiced in cases while the contract prices it per each. Prices can also be quoted per 100 or per 1,000 units. SAP's order price quantity check compares the ratio of quantities in price units and order units with the goods receipt or purchase order. Currency needs the rate the agreement specifies, and freight or surcharges need the same treatment on both sides.

Worked through, Line A is $50.00 per CASE against a contract of $5.00 per EACH, with master data documenting 10 EACH per CASE, so the contract price per CASE is $5.00 × 10 = $50.00. That is an exact match, and the $9,000 was never there.

Line D cannot be finished yet, because the invoice is $22.00 per BAG against $1.10 per KG and no bag weight is documented. At 20 kilograms a bag the price is exactly on contract, and at 18 kilograms it is over, so until the factor exists the line stays unresolved rather than being forced to a number.

This comparison is also the step the invoice price variance in your ERP skips, because SAP defines that variance as the invoice price differing from the purchase order price and does not consider the contract. Procurement suites can manage contract compliance for invoices directly, but only where the contract is loaded as a structured record that reflects the latest amendment.

When does a price discrepancy indicate supplier overbilling?

A discrepancy points to invoice price leakage when the invoiced price, on a comparable basis, exceeds the price the governing terms establish. It becomes a financial loss only if the difference is paid. This is the four-disposition review: every flag ends in exactly one of four places, and only one of them is a supported overcharge.

Applied to the four lines,

• Line A closes as reconciled
• Line B routes the price master for correction
• Line C goes to commercial review as a $1,000 overcharge on comparable terms, with no offsetting credit found.
• Line D stays open, with a request out for the bag weight and its amount excluded from validated totals.

Two distinctions keep this honest: a supported discrepancy is not yet an approved claim, and an approved claim is not yet money collected, so Line C remains a $1,000 finding until procurement and the supplier have worked through it.

A tolerance is also not a contract, because it only decides whether an invoice is held or passed, as when a 5 percent tolerance accepts a price of 1.05 but holds 1.10. A price that sits comfortably inside tolerance can still be above contract. The Tellius guide to spend intelligence versus process mining explores that gap in depth.

What goes in a review packet, and who owns each step?

A review packet is everything a second person needs to reach the same disposition without redoing the work. Here is Line C, completed using the template.

The packet is the same whether a person or an AI worker assembles it, because the evidence standard does not change with who does the work.

Each step needs its own owner: accounts payable confirms whether the line is paid, held, credited, or rebilled, and the contract or category owner confirms which terms govern. Procurement manages the conversation with the supplier, and finance decides how any outcome is recognized. Keep that separation whatever your roles are called, because whoever finds a discrepancy should not be the only person who decides it is real.

How do you prevent recurring contract leakage on supplier invoices?

Most prevention comes from fixing a small set of recurring causes at their source rather than recovering money afterward, and each of the four lines points to one of them.

Treat these as patterns to check rather than a ranking, because no reliable industry figure exists for how the causes split.

Mapped to the table,

• Line A's documented conversion factor should be marked as validated
• Line B's amendment should update the price master with its effective date
• Line C points to the supplier's billing setup, so hold unpaid lines at $10.00 and raise the difference at the next supplier review
• Line D needs its bag weight added to master data before any future line in that unit can be compared.

Check before payment as well. Run the same checks on unpaid invoices at each payment run, so a real discrepancy is held and corrected before the cash leaves. Doing that by hand every week is rarely realistic, which makes it a natural job for an AI worker on a scheduled Mission that hands people only the lines needing a decision.

Then measure recurrence. After a cause is fixed, track whether it stops producing exceptions. Once the price master reflects Line B's amendment, the next invoice at $10.40 should pass without a flag, and if it does not, the fix has not taken hold. A falling recurrence count for each fixed cause is the evidence that prevention is working, and it is a more honest measure of progress than the size of any recovered total.

How do you track prevented and recovered value without double-counting?

Keep each stage of a finding as its own figure, and never add successive stages of the same finding together. The six stages are:

• detected exposure,
• validated findings,
• approved or submitted claims,
• accepted claims,
• credits applied or cash received, and
• incorrect payments prevented.

Line C's $1,000 appears as detected, validated, submitted, accepted, and finally credited, which is one $1,000 passing through five stages, not $5,000. The error is easy to make because each stage tends to live in a different system, and each owner reports their own stage accurately.

If another 3,000 units of the same material are still unpaid and are then paid at $10.00 instead of $10.50, that is $1,500 of incorrect payment prevented. Count it separately, and only after those lines have actually been paid at the corrected price.

Before totaling, check for credits and rebills already issued and for duplicate findings on the same line, and make each status rest on its own record, from the review packet to the posted credit. Report corrected records and repeat exceptions beside the money, since they show whether next quarter will look different.

How Tellius can support invoice price reviews before payment

Tellius is an AI analytics platform for configured invoice-to-contract reviews, using scheduled Kaiya Missions to return cited findings for human review. A Kaiya App gives the team a place to review the results. Your team sets the source mappings, comparison rules, and approval path for its category.

A Mission can run on a schedule around payment cycles. With invoice lines, purchase orders, receipts, and governing contract terms connected, it can apply your team's approved rules for units, currencies, and dates, then assemble a cited review brief. Each figure should trace back to its invoice line and contract clause.

A configured App can give accounts payable, procurement, category owners, and finance one place to review the findings, see the calculations, keep open questions out of validated totals, and assign recurring causes. The team can build the App by describing it to Kaiya in plain English.

With those sources and rules in place, Kaiya can answer questions such as which suppliers keep landing in commercial review or how much validated overcharge sits in unpaid invoices this month, with the supporting evidence attached.

The Mission assembles the evidence. Procurement and finance decide whether to hold a payment or raise a claim. Start with a read-only replay of one category and one recent quarter of invoice history, then decide whether to add a payment-run control.

The review template

The CSV holds all 28 fields, with the four example lines filled in. In short, it records six things for each invoice line:

Terms used in this guide

‍

‍

‍

‍