# What invoice controls is Business Central missing?

> Dynamics 365 Business Central matches invoices to POs and receipts. See which contract-level checks it does not run, and what closes the gap.

Source: https://valuexpa.com/insights/what-invoice-controls-does-dynamics-365-business-central-not
Publisher: ValueXPA (https://valuexpa.com)
Updated: 2026-10-22

---

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Dynamics 365 Business Central is built to move an invoice through approval, not to read the contract behind it.

That distinction matters for any manufacturer running service vendor spend, freight, contract labor, maintenance, IT services, through BC. The system enforces what it can see on a purchase order. It has no field for a rebate tier, a surcharge cap, or a rate card expiration date.

## Executive Summary

Business Central's native invoice controls stop at three-way matching: the invoice line, the purchase order line, and the receipt. That check confirms quantity and unit price agree with what was ordered and received. It says nothing about whether the unit price itself is still the one the contract allows, whether a volume tier should have triggered a lower rate, or whether a surcharge that was valid in January is still valid in September.

The mechanism is simple. Contract terms, rate cards, rebate clauses, not-to-exceed caps, live in PDFs, side letters, and vendor portals outside the ERP. BC has no object model for them. It cannot flag an invoice as wrong against a document it never ingested. That leaves every invoice that passes the three-way match still exposed to drift the match was never designed to catch.

What changes this is not a BC configuration change. It is a separate check run against the contract itself, either periodically as a diagnostic or continuously as a forward control, because the gap is structural to what the ERP was built to do.

## 1. What does Business Central actually check on an incoming invoice?

**Business Central runs three-way matching: it compares the invoice line against the purchase order line and the goods or service receipt. It confirms the vendor billed the quantity ordered, at the unit price recorded on the PO, for an item or service that was actually received. That is a quantity and price-agreement check against BC's own transaction history. It does not compare the price to anything outside the ERP, so a unit price that was wrong when the PO was.**

The PO is the reference point for the whole check. If the purchase order carries a stale rate, an expired discount, or a surcharge that should have rolled off, BC matches the invoice to that PO cleanly and approves it.

Approval workflows in BC route invoices by dollar threshold or by department, not by contract clause. A large invoice and a small one go through the same price-agreement logic; only the approver list changes based on amount.

For a distributor or manufacturer running freight, contract labor, or maintenance spend through BC, this means the control surface is exactly as good as the PO data entered months or years earlier, and no better.

## 2. Why doesn't three-way matching catch a rate card violation?

**Three-way matching tests internal consistency: does the invoice agree with the PO and the receipt. A rate card violation is external inconsistency: does the PO's own price agree with the contract. Those are different questions, and BC only asks the first one. A rate card defines tiered pricing, minimum volume commitments, and surcharge conditions in a document the ERP never reads, so a PO built against an outdated tier passes every match BC runs while still billing the wrong rate.**

Rate schedule violations are a recurring, easy-to-miss source of drift because the invoice looks ordinary against the wrong reference table. Nothing in the transaction itself looks anomalous. The quantity is right, the receipt is right, the unit price matches the PO line exactly.

Catching this requires comparing the PO price, not the invoice, against the contract's current rate schedule. That comparison sits entirely outside BC's data model, which has no field for 'contract rate as of this date' separate from 'PO price as entered.'

## 3. Can Business Central detect a surcharge that should have expired?

**No. A fuel surcharge, an emergency staffing premium, or a temporary rush fee carries an end condition written into the contract: a date, a volume threshold, or an index level. Business Central has no mechanism to track that condition or to flag an invoice line once it is met. The surcharge keeps posting at whatever rate was last entered until someone manually removes it from the vendor's billing setup or the PO. Nothing in the matching logic checks the condition.**

This is a persistence problem, not a matching problem. The surcharge was legitimate when it started. The invoice control never asked whether the condition that justified it still holds, because that condition lives in the contract text, not in a BC field.

A surcharge with a defined end date or trigger needs a check that runs against the contract's expiration logic on every invoice cycle, not once at PO setup. BC's price agreement check has nothing to compare that logic to.

## 4. Does Business Central track NTE caps and rebate clauses?

**Business Central has no native construct for a not-to-exceed cap or an earned rebate clause. An NTE cap limits total billing on a project or service line regardless of hours or units logged; BC will post every invoice line up to and past that cap unless someone manually tracks cumulative spend outside the system. A rebate clause promises money back once a volume threshold is crossed; BC does not calculate the threshold or generate the claim on its own.**

Both failures share a root cause: BC's invoice controls operate line by line, against a single PO, not cumulatively against a contract's full term.

### A. NTE overruns

A staffing or IT services contract with a not-to-exceed cap needs running-total tracking across every invoice in the engagement. BC approves each invoice individually against its own PO line. Nothing sums the project to date against the cap and blocks the line that crosses it.

### B. Unclaimed rebates

A rebate tied to annual volume requires tracking cumulative purchase quantity against a threshold defined in the contract, then generating a credit memo or claim when it's crossed. BC has no field for the threshold and no trigger to act on it, so the rebate goes unclaimed unless someone checks the contract manually.

## 5. What does this gap cost on freight and contract labor invoices specifically?

**Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, across ValueXPA diagnostics. That figure describes the whole engagement, not any single category, so it should not be read as a freight number or a labor number on its own. What can be said about freight and contract labor specifically is qualitative: both categories carry surcharge and rate structures that change on a schedule BC's PO-based matching does not track.**

Freight contracts commonly bundle base rate, fuel surcharge, and accessorial charges into a single carrier invoice, each with its own trigger condition. Contract labor invoices commonly bundle a base bill rate with overtime multipliers and NTE caps on a per-engagement basis.

In both cases, BC's three-way match confirms the invoice matches the PO. It does not confirm the PO still reflects the contract. Quantifying the gap for a specific set of invoices means comparing them against the underlying contract documents directly, which is arithmetic a reader can run against their own freight or labor spend rather than a number the diagnostic dataset breaks out by category.

## 6. Is a BC customization or add-on the fix, or is this a different kind of check?

**A BC customization can extend the PO or invoice screen with new fields, but it still requires someone to enter the contract's rate tiers, surcharge conditions, and NTE caps by hand and keep them current. That is the same work a manual audit does, moved into the ERP's UI. It does not solve the underlying problem: the contract terms have to be interpreted from PDFs and side letters before any field, custom or native, can hold them.**

The real choice is not between BC-native and BC-customized. It is between reviewing invoices against contracts retrospectively, on a fixed schedule, or building a forward control that checks every invoice against current contract terms as it arrives.

A periodic audit tests history: it takes the last 12 to 18 months of invoices and reconciles each one against the contract that governed it, across ValueXPA diagnostics, surfacing what already leaked. A forward control tests the next invoice, checking it against the current rate schedule before payment.

Both need the same underlying work first: turning unstructured contract terms into a rule set BC was never built to hold. See diagnostic or software: what to buy first for how to sequence that decision.

## 7. Should a $50M+ manufacturer build this check in Excel instead?

**Excel can hold a rate card and a lookup formula, and for a single vendor with a stable contract that may be enough. The difficulty scales with the number of vendors, contract renewal dates, and surcharge conditions tracked at once, since each one needs its own update discipline outside BC. For a manufacturer above $50M in revenue running dozens of service vendor contracts through Business Central, that tracking burden is the actual constraint, not the formula itself.**

The question is not whether a spreadsheet can express a rate rule. It clearly can. The question is who updates it every time a contract renews, a rate tier changes, or a surcharge condition rolls off, and whether that update happens before the next invoice cycle or after.

A worked example, using the 1% to 3% band: take your annual service vendor spend routed through BC, multiply by the share under contracts with tiered rates or surcharge clauses, and that is the base exposed to the kind of drift BC's matching does not test. The size of that base is what determines whether a spreadsheet keeps pace or falls behind. See build vs. buy: can you do contract-to-invoice matching in Excel? for the mechanics of where that tracking breaks down.

For the wider pattern this sits inside, start with the margin drift guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and what is margin erosion? causes and prevention for manufacturers.

For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for) and [margin drift vs. legitimate price increases: how to tell them apart](/insights/margin-drift-vs-legitimate-price-increases-how-to-tell-them).

## 8. Frequently Asked Questions (People Also Ask)

### Does Business Central support three-way matching out of the box?

Yes. Business Central natively matches the invoice line, purchase order line, and receipt to confirm quantity and unit price agree with what was ordered and received. It does not compare that price against a contract's rate card, rebate clause, or surcharge terms, which live outside the ERP entirely.

### Can I add custom fields in Business Central to track contract terms?

Yes, BC supports custom fields and extensions. But someone still has to read the contract, extract the rate tiers, surcharge conditions, or NTE caps, and enter them manually. The customization holds data; it doesn't interpret the PDF or side letter the terms come from.

### Will BC flag an invoice if the vendor overbills against the contract?

Only if the overbilling also breaks the PO match, such as billing a different quantity or unit price than the PO states. If the PO itself carries a stale or incorrect rate, BC approves the invoice cleanly because it matches what BC expects.

### How do I know if my BC-managed vendor spend has this exposure?

Any service vendor contract with tiered pricing, a surcharge with an expiration condition, a not-to-exceed cap, or an earned rebate creates exposure, because none of those terms have a home in BC's data model. Reviewing a sample of contracts against their matching POs shows whether current rates are still in effect.

### Is this a Business Central limitation or true of other ERPs too?

It's structural to how ERPs handle purchasing generally. Three-way matching checks internal consistency between the invoice, PO, and receipt. Reading and enforcing contract terms outside that transaction chain is a different function that most ERPs, not just BC, don't build in natively.

### Does upgrading to a newer BC version add contract-level checks?

No. Version upgrades improve BC's core purchasing and finance functions but don't add a contract interpretation layer. The gap between PO-based matching and contract enforcement persists across BC versions because it's a design boundary, not a missing feature awaiting a patch.

### What's the fastest way to find out how exposed we are?

Pull a sample of service vendor contracts, freight, labor, maintenance, and compare their current terms against the PO prices and surcharge lines currently running through BC. A fixed-scope diagnostic does this systematically and returns a prioritized roadmap in 2 to 4 weeks, across ValueXPA diagnostics.

### Can BC's approval workflow substitute for a contract compliance check?

No. Approval workflows route invoices by dollar amount or department, deciding who signs off. They don't test whether the underlying price, surcharge, or rebate terms match the contract. An invoice can clear every approval step while still billing against a stale rate.

### Do we need software or a one-time audit to close this gap?

It depends on whether you can already name which contracts are leaking. A periodic diagnostic tests 12 to 18 months of history; a continuous control tests each new invoice. Both require the same first step: turning contract terms into a rule set BC doesn't natively hold.

### Is contract complexity quietly draining your operating margin?

A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit.

**[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)**

## Executive Summary

Business Central's native invoice controls stop at three-way matching: the invoice line, the purchase order line, and the receipt. That check confirms quantity and unit price agree with what was ordered and received. It says nothing about whether the unit price itself is still the one the contract allows, whether a volume tier should have triggered a lower rate, or whether a surcharge that was valid in January is still valid in September. The mechanism is simple. Contract terms, rate cards, rebate clauses, not-to-exceed caps, live in PDFs, side letters, and vendor portals outside the ERP. BC has no object model for them. It cannot flag an invoice as wrong against a document it never ingested. That leaves every invoice that passes the three-way match still exposed to drift the match was never designed to catch. What changes this is not a BC configuration change. It is a separate check run against the contract itself, either periodically as a diagnostic or continuously as a forward control, because the gap is structural to what the ERP was built to do.

## 1. What does Business Central actually check on an incoming invoice?

Business Central runs three-way matching: it compares the invoice line against the purchase order line and the goods or service receipt. It confirms the vendor billed the quantity ordered, at the unit price recorded on the PO, for an item or service that was actually received. That is a quantity and price-agreement check against BC's own transaction history. It does not compare the price to anything outside the ERP, so a unit price that was wrong when the PO was. The PO is the reference point for the whole check. If the purchase order carries a stale rate, an expired discount, or a surcharge that should have rolled off, BC matches the invoice to that PO cleanly and approves it. Approval workflows in BC route invoices by dollar threshold or by department, not by contract clause. A large invoice and a small one go through the same price-agreement logic; only the approver list changes based on amount. For a distributor or manufacturer running freight, contract labor, or maintenance spend through BC, this means the control surface is exactly as good as the PO data entered months or years earlier, and no better.

## 2. Why doesn't three-way matching catch a rate card violation?

Three-way matching tests internal consistency: does the invoice agree with the PO and the receipt. A rate card violation is external inconsistency: does the PO's own price agree with the contract. Those are different questions, and BC only asks the first one. A rate card defines tiered pricing, minimum volume commitments, and surcharge conditions in a document the ERP never reads, so a PO built against an outdated tier passes every match BC runs while still billing the wrong rate. Rate schedule violations are a recurring, easy-to-miss source of drift because the invoice looks ordinary against the wrong reference table. Nothing in the transaction itself looks anomalous. The quantity is right, the receipt is right, the unit price matches the PO line exactly. Catching this requires comparing the PO price, not the invoice, against the contract's current rate schedule. That comparison sits entirely outside BC's data model, which has no field for 'contract rate as of this date' separate from 'PO price as entered.'

## 3. Can Business Central detect a surcharge that should have expired?

No. A fuel surcharge, an emergency staffing premium, or a temporary rush fee carries an end condition written into the contract: a date, a volume threshold, or an index level. Business Central has no mechanism to track that condition or to flag an invoice line once it is met. The surcharge keeps posting at whatever rate was last entered until someone manually removes it from the vendor's billing setup or the PO. Nothing in the matching logic checks the condition. This is a persistence problem, not a matching problem. The surcharge was legitimate when it started. The invoice control never asked whether the condition that justified it still holds, because that condition lives in the contract text, not in a BC field. A surcharge with a defined end date or trigger needs a check that runs against the contract's expiration logic on every invoice cycle, not once at PO setup. BC's price agreement check has nothing to compare that logic to.

## 4. Does Business Central track NTE caps and rebate clauses?

Business Central has no native construct for a not-to-exceed cap or an earned rebate clause. An NTE cap limits total billing on a project or service line regardless of hours or units logged; BC will post every invoice line up to and past that cap unless someone manually tracks cumulative spend outside the system. A rebate clause promises money back once a volume threshold is crossed; BC does not calculate the threshold or generate the claim on its own. Both failures share a root cause: BC's invoice controls operate line by line, against a single PO, not cumulatively against a contract's full term. ### A. NTE overruns A staffing or IT services contract with a not-to-exceed cap needs running-total tracking across every invoice in the engagement. BC approves each invoice individually against its own PO line. Nothing sums the project to date against the cap and blocks the line that crosses it. ### B. Unclaimed rebates A rebate tied to annual volume requires tracking cumulative purchase quantity against a threshold defined in the contract, then generating a credit memo or claim when it's crossed. BC has no field for the threshold and no trigger to act on it, so the rebate goes unclaimed unless someone checks the contract manually.

## 5. What does this gap cost on freight and contract labor invoices specifically?

Margin drift across a full diagnostic typically runs 1% to 3% of service vendor spend, across ValueXPA diagnostics. That figure describes the whole engagement, not any single category, so it should not be read as a freight number or a labor number on its own. What can be said about freight and contract labor specifically is qualitative: both categories carry surcharge and rate structures that change on a schedule BC's PO-based matching does not track. Freight contracts commonly bundle base rate, fuel surcharge, and accessorial charges into a single carrier invoice, each with its own trigger condition. Contract labor invoices commonly bundle a base bill rate with overtime multipliers and NTE caps on a per-engagement basis. In both cases, BC's three-way match confirms the invoice matches the PO. It does not confirm the PO still reflects the contract. Quantifying the gap for a specific set of invoices means comparing them against the underlying contract documents directly, which is arithmetic a reader can run against their own freight or labor spend rather than a number the diagnostic dataset breaks out by category.

## 6. Is a BC customization or add-on the fix, or is this a different kind of check?

A BC customization can extend the PO or invoice screen with new fields, but it still requires someone to enter the contract's rate tiers, surcharge conditions, and NTE caps by hand and keep them current. That is the same work a manual audit does, moved into the ERP's UI. It does not solve the underlying problem: the contract terms have to be interpreted from PDFs and side letters before any field, custom or native, can hold them. The real choice is not between BC-native and BC-customized. It is between reviewing invoices against contracts retrospectively, on a fixed schedule, or building a forward control that checks every invoice against current contract terms as it arrives. A periodic audit tests history: it takes the last 12 to 18 months of invoices and reconciles each one against the contract that governed it, across ValueXPA diagnostics, surfacing what already leaked. A forward control tests the next invoice, checking it against the current rate schedule before payment. Both need the same underlying work first: turning unstructured contract terms into a rule set BC was never built to hold. See diagnostic or software: what to buy first for how to sequence that decision.

## 7. Should a $50M+ manufacturer build this check in Excel instead?

Excel can hold a rate card and a lookup formula, and for a single vendor with a stable contract that may be enough. The difficulty scales with the number of vendors, contract renewal dates, and surcharge conditions tracked at once, since each one needs its own update discipline outside BC. For a manufacturer above $50M in revenue running dozens of service vendor contracts through Business Central, that tracking burden is the actual constraint, not the formula itself. The question is not whether a spreadsheet can express a rate rule. It clearly can. The question is who updates it every time a contract renews, a rate tier changes, or a surcharge condition rolls off, and whether that update happens before the next invoice cycle or after. A worked example, using the 1% to 3% band: take your annual service vendor spend routed through BC, multiply by the share under contracts with tiered rates or surcharge clauses, and that is the base exposed to the kind of drift BC's matching does not test. The size of that base is what determines whether a spreadsheet keeps pace or falls behind. See build vs. buy: can you do contract-to-invoice matching in Excel? for the mechanics of where that tracking breaks down. For the wider pattern this sits inside, start with the margin drift guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and what is margin erosion? causes and prevention for manufacturers. For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for) and [margin drift vs. legitimate price increases: how to tell them apart](/insights/margin-drift-vs-legitimate-price-increases-how-to-tell-them).

## Common questions

### Does Business Central support three-way matching out of the box?

Yes. Business Central natively matches the invoice line, purchase order line, and receipt to confirm quantity and unit price agree with what was ordered and received. It does not compare that price against a contract's rate card, rebate clause, or surcharge terms, which live outside the ERP entirely.

### Can I add custom fields in Business Central to track contract terms?

Yes, BC supports custom fields and extensions. But someone still has to read the contract, extract the rate tiers, surcharge conditions, or NTE caps, and enter them manually. The customization holds data; it doesn't interpret the PDF or side letter the terms come from.

### Will BC flag an invoice if the vendor overbills against the contract?

Only if the overbilling also breaks the PO match, such as billing a different quantity or unit price than the PO states. If the PO itself carries a stale or incorrect rate, BC approves the invoice cleanly because it matches what BC expects.

### How do I know if my BC-managed vendor spend has this exposure?

Any service vendor contract with tiered pricing, a surcharge with an expiration condition, a not-to-exceed cap, or an earned rebate creates exposure, because none of those terms have a home in BC's data model. Reviewing a sample of contracts against their matching POs shows whether current rates are still in effect.

### Is this a Business Central limitation or true of other ERPs too?

It's structural to how ERPs handle purchasing generally. Three-way matching checks internal consistency between the invoice, PO, and receipt. Reading and enforcing contract terms outside that transaction chain is a different function that most ERPs, not just BC, don't build in natively.

---

ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us