Does Business Central check invoices against contracts?

Executive Summary

Business Central's controls stop at the documents it was configured to compare: the purchase order, the receipt and the invoice. A vendor can raise a rate, apply an expired surcharge, or skip an earned rebate and still pass every check Business Central runs, because none of those checks touch the contract itself.

The mechanism is structural, not a bug. Contract terms like volume tiers, rebate triggers and NTE caps live in unstructured PDFs that never enter the ERP as data. Business Central was built to enforce the purchasing workflow, not to parse a contract clause and turn it into a rule.

Closing the gap means either building the contract logic manually, which most AP teams do not have time to maintain line by line, or running a separate check that starts from the contract instead of the PO. The rest of this page describes what Business Central actually verifies, where the blind spot sits, and how a manufacturer above $100M in revenue typically finds out how much it is costing them.

1. Does Business Central check invoices against contract terms?

No, not directly. Business Central's native matching compares an invoice to the purchase order and the goods receipt tied to it. It confirms the invoice charges the price on the PO and the quantity that was received.

It does not open the underlying vendor contract, so a rate card change, a rebate clause, a volume tier or an NTE cap can sit unread even while every invoice clears the system's own checks without a flag.

The confusion is understandable. Three-way matching feels like a contract check because it catches the most obvious form of overbilling: an invoice that does not match what was ordered or received. That is a real control, and it works.

But a PO price is only correct if someone entered the right price on the PO in the first place, and kept it current every time the contract changed. Business Central verifies internal consistency between its own documents. It has no mechanism for reading a signed agreement and comparing that document to what showed up on an invoice six months later.

This is true of Business Central specifically and of ERP purchasing modules generally. The control was built for the purchasing workflow, not for contract enforcement, and the two are not the same job even though they touch the same invoice.

2. What does three-way matching in Business Central actually verify?

Three-way matching in Business Central checks that the invoice quantity matches what was received, and that the invoice price matches the price stored on the purchase order line. Both checks are internal to Business Central's own records. Neither one asks whether the PO price is still the contract price, whether a volume tier should have triggered a lower rate, or whether a surcharge on the invoice has a valid basis in the vendor agreement.

A purchase order in Business Central carries a unit price, usually copied in from a vendor catalog record or entered manually by a buyer. Once that price is on the PO, matching logic treats it as correct.

That is where the exposure starts. If a vendor's contract lowered a rate under a volume tier and nobody updated the PO template, matching will pass an invoice at the old, higher rate every time. The system did its job. The job it did was not the one the reader needed.

The same is true for accessorial and surcharge lines that arrive as separate charges. If they were never on the PO to begin with, matching has nothing to compare them against, so they clear by default rather than by verification.

3. Where do contract terms live outside Business Central?

Contract terms that drive pricing accuracy, rate cards, rebate clauses, NTE caps, surcharge expiration dates and minimum volume commitments, typically exist as unstructured PDFs, signed exhibits, or email confirmations, never as structured fields inside Business Central. Turning them into an enforceable rule requires a person to read the clause, extract the trigger condition, and apply it manually, since the purchasing module has no field designed to hold or test that condition.

None of these live in Business Central as data the system can check against an invoice line. They live in the contract file itself, in whatever format the vendor sent it: a signed PDF, a rate exhibit, an email thread confirming a change.

That gap is not a configuration oversight to be fixed with a setting. It is the difference between a system built to run a purchasing workflow and a document written in prose by two legal teams.

• Rate cards and tier schedules: Negotiated unit rates by volume band, usually issued as a PDF attachment or an email exhibit, not entered as structured pricing data.
• Rebate and credit clauses: Conditions under which a vendor owes money back, triggered by spend thresholds the AP team has to track manually.
• Not-to-exceed caps: A ceiling on a specific charge type, stated in contract language rather than as a system-enforced limit on the invoice line.
• Surcharge expiration terms: A fuel or accessorial surcharge tied to an index or a date range, with no field in Business Central that expires it automatically.
• Minimum volume commitments: A floor the buyer agreed to purchase against, which affects whether a given invoice is even priced correctly under the contract.

4. Can Business Central catch a rate schedule violation on its own?

Only if the correct rate is already sitting on the purchase order before the invoice arrives. Business Central compares the invoice to the PO, so if the PO price is stale, wrong, or was never updated to reflect a contract change, the invoice will match it perfectly and still overcharge against the actual agreement. The system's accuracy depends entirely on the accuracy of the PO it was given.

This is the core mechanical point. A rate schedule violation is a mismatch between the invoice and the contract, not between the invoice and the PO. Business Central checks the second relationship, not the first.

A buyer who keeps every PO price current against every contract change, across every vendor and every tier, closes this gap manually. That is a real amount of ongoing work, done invoice by invoice and vendor by vendor, and it depends on someone maintaining that discipline indefinitely.

When a PO price drifts out of date, the invoice that matches it will look completely clean in Business Central. Nothing in the standard workflow surfaces the disagreement, because nothing in the workflow compares against the contract itself.

5. What happens when a surcharge or NTE cap is buried in a PDF contract?

The surcharge or cap goes unchecked, not because a control failed, but because no control was ever pointed at it. Business Central compares documents it holds: invoice to PO to receipt. A surcharge expiration date, an NTE ceiling, or a rebate threshold sits in the contract file, outside all three documents, so the invoice can be internally consistent with the PO and still be wrong against what the vendor actually agreed to charge.

Each row in that table is the same shape of problem. Business Central runs a document-to-document comparison. The contract term requires a condition test against a value that lives outside any of the documents Business Central compares.

An invoice with a surcharge that expired two months ago will match its PO exactly, because the PO never carried an expiration date to check against. The charge is wrong under the contract and correct under Business Central's own logic at the same time. That is not a contradiction. It is two different questions being asked, and only one of them being answered.

What Business Central's native matching checks, against what a contract term like a surcharge cap or NTE limit actually requires.

6. How should a Business Central user close this gap?

Start by identifying which vendor categories carry contract terms Business Central cannot see: rate cards, NTE caps, rebate clauses and surcharge schedules. Those are the invoices worth checking against the underlying contract directly, not just against the PO. A fixed-scope diagnostic reviews historical invoices against contract terms and returns a prioritized list of where the PO price and the contract price have separated.

The practical starting point is not a system change. It is a review of what has already been billed, checked against the contracts Business Central never reads, across the categories most likely to carry rate cards, tiers and caps: freight, contract labor, maintenance, and professional services.

That review produces two things: a list of specific invoices where the contract and the PO price disagree, and a list of which PO templates need correcting so the same drift does not recur. The first is a recovery question. The second is a prevention question, and Business Central can enforce the second once the correct rate is actually on the PO.

A margin drift diagnostic does this work against 12 to 18 months of historical spend and returns a prioritized recovery and prevention roadmap in 2 to 4 weeks, across ValueXPA diagnostics.

For the wider pattern this sits inside, start with the margin drift guide. See also the Margin Drift Diagnostic and our insights.

7. Frequently Asked Questions (People Also Ask)

Does Business Central do three-way matching?

Yes. Business Central compares the invoice to the purchase order and the goods receipt, checking that the quantity received and the price on the PO match what the vendor billed. This is a standard, well-built control for purchasing accuracy. It does not extend to checking the PO price against the underlying vendor contract.

Can Business Central read a PDF contract automatically?

No. Business Central has no native capability to parse a vendor contract document and extract rate terms, rebate triggers or NTE caps into enforceable rules. Contract terms have to be manually translated into PO prices, tier configurations or workflow steps by someone on the AP or procurement team.

Why would an invoice pass Business Central's checks and still be wrong?

Because Business Central checks the invoice against the PO and receipt, not against the contract. If the PO carries a stale or incorrect price, an invoice that matches the PO will clear every native check while still overcharging against what the vendor actually agreed to.

What kind of overcharges does Business Central typically miss?

Rate schedule violations where the PO was never updated, surcharges that should have expired, not-to-exceed overruns on labor or service lines, and rebates that were earned under a volume tier but never credited. Each depends on a contract condition outside the PO and receipt.

Does upgrading to a newer ERP version fix this?

No. The gap is structural to how purchasing modules work, not a version limitation. Any ERP that matches invoices to purchase orders and receipts, rather than to the contract document itself, has the same blind spot regardless of version or vendor.

Is this something an AP automation add-on solves?

AP automation tools speed up and digitize the same matching Business Central already does: invoice to PO to receipt. They prevent forward-looking errors at the point of receipt but still cannot interpret unstructured contract terms living in a PDF outside the ERP.

How do I find out how much this is costing us right now?

A review of historical invoices against the actual contract terms, not just the PO, will surface where the two have separated. That review covers 12 to 18 months of spend and identifies both what to recover and which PO templates to correct going forward.

Which vendor categories are worth checking first?

Categories where rate cards, volume tiers, NTE caps or surcharge schedules are common contract features: freight and 3PL, contract labor and staffing, maintenance and repair, and IT or professional services. Each carries terms that live outside the PO by default.

Do I need to replace Business Central to close this gap?

No. Business Central continues to run purchasing and matching. Closing the gap means adding a contract-level check, either maintained manually against rate cards and caps, or run as a separate review, so the PO price it enforces is the correct one to begin with.