Contract compliance: a Controller guide

Executive Summary

A Controller signs off on numbers that assume every vendor invoice matches its contract. That assumption is usually untested. Contract compliance is the discipline of proving invoice terms match contract terms, line by line, before the invoice posts or during the audit that follows close. Without it, gross margin absorbs errors that have nothing to do with operations.

The mechanism is simple: contracts carry rate cards, volume tiers, rebate clauses, surcharge schedules and not-to-exceed caps, most of them in PDFs outside the ERP. AP systems match invoices to purchase orders and receipts, not to those clauses. A surcharge that should have expired, a tier that should have dropped a rate, a rebate that should have been claimed: none of these trip a three-way match.

They post clean and sit in cost of goods until someone reconciles the contract itself.

What changes it is a control that tests the invoice against the contract clause, not just the PO, on a cycle the Controller owns: at close for material vendors, periodically for the rest, and always before a contract renews.

1. What does contract compliance mean for a Controller specifically?

For a Controller, contract compliance means every posted vendor invoice reflects the rate, tier, rebate and cap terms in the signed contract, not just the purchase order and receipt. It is distinct from AP accuracy: an invoice can match its PO exactly and still violate the contract underneath it. Compliance is a reconciliation between two documents that live in different systems, and the Controller is the person accountable for both being true at once.

Three-way matching answers one question: does the invoice match what was ordered and received? It never opens the contract PDF. A vendor can raise the correct quantity at the wrong rate and pass every AP control in place today.

Contract compliance closes that gap by testing the invoice against the clause that governs it: the rate card, the volume tier threshold, the rebate trigger, the surcharge expiration date, the not-to-exceed cap. Each of those lives in a document AP was never built to read.

For a Controller, the practical distinction matters at sign-off. Approving an invoice batch confirms coding and authorization. It does not confirm the vendor charged what the contract allows. Those are two separate assertions, and only one of them is currently tested by most AP workflows.

2. Where does drift actually enter the books during close?

Drift enters at the point an invoice is coded to an expense account without being checked against its governing contract clause. This happens most often with recurring vendors on freight, contract labor, MRO and maintenance, where the invoice format looks identical month to month even after a rate, tier or surcharge condition has changed. The invoice looks routine.

The close process has no step that would catch the difference, so it posts and repeats.

A recurring vendor invoice is the easiest one to approve and the easiest one to miss. It arrives in the same format every cycle, coded to the same account, often approved by the same person under time pressure at month end.

That familiarity is exactly what makes it a risk. A surcharge that was contractually temporary can keep appearing on the invoice after its expiration date, unnoticed because the line item itself never changes shape, only its justification does.

A volume tier is similar. The contract may specify that crossing an annual volume threshold drops the unit rate. Nothing in the AP workflow tracks cumulative volume against that threshold, so the lower rate never gets applied unless someone reconciles it separately from the invoice queue.

The result is that drift does not enter through unusual transactions. It enters through the ordinary ones, because those are the ones nobody re-examines against the contract once the vendor relationship is established.

3. How should a Controller build a compliance check into the close cycle?

Build the check as a scheduled reconciliation, separate from invoice approval, that samples material vendor contracts against posted invoices on a fixed cadence. It does not need to touch every invoice every month. It needs to guarantee that every contract with a rate card, tier or rebate clause gets tested at least once before its renewal date, and that high-dollar recurring vendors get tested every close.

The check works in three layers, and each answers a different question.

A. Layer 1: recurring vendor sampling

Pull the top vendors by annual spend in freight, contract labor, MRO and maintenance, and test a sample of their invoices from the current close period against the current contract terms. This layer runs every month and catches drift while it is still small.

B. Layer 2: clause-triggered review

Track dates that matter contractually: surcharge expirations, tier thresholds, rebate claim windows, NTE cap resets. When one of those dates falls inside the close period, pull every invoice affected by it, not a sample. This layer catches the drift that Layer 1's sampling would miss by chance.

C. Layer 3: pre-renewal audit

Before any contract renews, reconcile the full period of invoices against its terms once. This is the backstop: whatever Layers 1 and 2 missed across the contract's life, this catches before the same terms get signed again unchanged.

4. Can existing AP or ERP controls catch this without new work?

Existing AP and ERP controls test what they were built to test: quantity, price against a stored unit cost, and authorization. They do not read a contract's rebate clause or surcharge expiration condition, because those terms usually live outside the ERP in a PDF the system was never configured to parse. Extending three-way matching to catch this requires someone to first translate the contract clause into a rule the system can check, which is separate work from running the match.

A three-way match compares the invoice to the purchase order and the goods receipt. That comparison confirms the vendor billed for what was ordered and delivered. It says nothing about whether the price itself is still the contractually correct one.

Some ERPs store a unit cost against a vendor or item, and can flag a variance from that stored figure. That catches a rate change the moment it happens, but only if someone updated the stored cost to reflect the contract in the first place. A stale stored rate produces a clean match against a wrong number.

Rebate clauses and volume tiers are harder still, because they are conditional on cumulative activity the ERP may not track in the form the contract specifies. The gap is not a missing feature so much as a missing translation step: nobody has turned the contract language into a rule the system enforces. That translation is the actual work of a contract compliance program, whether it is done manually by the Controller's team or through a dedicated audit.

5. What should a Controller ask for from a contract compliance audit?

Ask for three deliverables: a finding list mapped to specific invoices and contract clauses, a corrected coding recommendation for anything already posted incorrectly, and a forward rule that prevents the same drift from recurring. A finding without a forward rule just gets rediscovered next year. The audit should also state which vendors and categories it covered and which it did not, so the Controller knows the actual scope of assurance being given.

A finding that says "this invoice was overbilled" is useful for one period. A finding that says "this surcharge clause has no expiration check in AP, and here are the other vendors with the same clause type" is useful indefinitely.

The Controller's interest is different from the CFO's here. The CFO wants the recovery number. The Controller wants the list of accounts and vendors that need a standing control, because that list is what changes the close checklist going forward.

Ask explicitly what the audit did not cover. A scoped engagement that reviewed the top vendors by spend leaves the rest of the vendor file untested, and that boundary needs to be stated, not discovered later when a smaller vendor turns out to carry the same clause.

6. How does this fit with a Controller's other priorities like close speed and audit readiness?

Contract compliance testing does not need to sit inside the close timeline to protect it. Layer 1 and Layer 2 checks run on their own schedule and feed corrections into the following period rather than delaying the current close. The payoff for audit readiness is direct: a documented, dated reconciliation between invoices and contract terms is exactly the evidence an external auditor asks for when testing cost of goods sold for accuracy.

A Controller who adds a new step to the close checklist itself, one that requires reading contract PDFs during a five-day close, will correctly resist it. That is not where this work belongs.

The sampling and clause-triggered layers run asynchronously, on their own calendar, independent of the close deadline. When they surface an error, it gets corrected in the next period through a normal adjusting entry, coded and documented like any other correction.

External auditors testing cost of goods sold for accuracy will ask how the company knows vendor billing matches contract terms. A dated log of clause-based reconciliations answers that question directly. Without it, the honest answer is that nobody has checked, which is a harder conversation during fieldwork than a scheduled program with documented findings.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

Is contract compliance the same thing as an AP audit?

No. An AP recovery audit looks backward for duplicate payments, missed credits and overbilling already posted. Contract compliance specifically tests whether invoice terms match the underlying contract clause, which an AP audit may not check if the invoice otherwise looks clean against the PO.

Which vendor categories should a Controller prioritize first?

Start with recurring, high-dollar categories where contract terms carry conditional clauses: freight and 3PL surcharges, contract labor rate escalations, and maintenance agreements with not-to-exceed caps. These carry clause types that AP systems are not built to test, regardless of vendor size.

Does this require new software before a Controller can start?

No. The first layer is a sampling exercise against existing contracts and invoices, which can run with spreadsheets and the AP ledger already in place. Software or an outside audit becomes useful once the vendor file is large enough that manual sampling cannot cover it on a reasonable cycle.

How does a Controller know if a finding is material enough to restate anything?

Materiality depends on the dollar amount relative to the account and period in question, which is a judgment the Controller makes with the same threshold used for any other correcting entry. A contract compliance finding is not automatically a restatement; most corrections post as a normal adjustment in the period discovered.

Who should own the contract library that this checking depends on?

Whoever owns vendor relationships, typically procurement or the category owner, should maintain the current signed contract as the source of truth, with finance holding a copy for reconciliation. Without a maintained, current library, the Controller's team ends up testing against an outdated version of the contract.

What is a not-to-exceed cap and why does it matter to close?

A not-to-exceed cap is a contractual ceiling on what a vendor may bill for a given scope of work, common in professional services and maintenance agreements. If invoices are coded and paid without checking cumulative billing against the cap, the overrun sits in cost of goods until someone reconciles the full period against the contract.

Can this work be done as part of month-end close instead of separately?

It can, but a full clause-by-clause reconciliation inside a five-day close timeline usually is not realistic. Running it on a separate, ongoing schedule and feeding corrections into the next period as normal adjusting entries keeps the close timeline intact while still closing the gap.

What should the Controller do with findings after an audit is complete?

Convert each finding into a forward rule, not just a one-time correction: a dated check on the relevant clause type, added to the recurring sampling schedule described above. A finding that is corrected once but not converted into a standing check tends to recur at the next contract renewal.

Does contract compliance apply to multi-entity organizations differently?

The mechanism is the same, but the reconciliation has to account for contracts negotiated at the parent level and applied across multiple entities, each of which may code and receive invoices differently. A multi-entity Controller needs the sampling layer to span entities, not just vendors, to catch a compliant entity masking a non-compliant one.