Exception reporting for Business Central invoices

Executive Summary

Business Central's three-way match and its standard variance reports test whether an invoice agrees with its own purchase order and receipt. That is a narrow definition of "correct." It says nothing about whether the PO price itself still reflects the vendor contract, whether a volume rebate tier was applied, or whether a surcharge that was supposed to expire is still on the invoice. An invoice can pass every check BC runs and still be wrong against the contract.

The mechanism causing this is structural, not a configuration gap you can fix inside BC. Contract terms such as rate cards, rebate clauses and NTE caps live in PDFs and side letters outside the ERP. BC has no table for them, so it cannot test an invoice against a term it never ingested. Its exception reports can only compare documents that already exist inside the system.

What changes this is treating BC's variance report as one input, not the full check. A separate contract reference, even a maintained spreadsheet of current rates and thresholds, gives you something to report the invoice against beyond the PO. Margin Drift Diagnostic builds that reference and the matching logic for you; short of that, this page shows what to set up inside BC first and where it will still need a second data source.

1. What does Business Central check when it matches an invoice?

Business Central's three-way match compares the vendor invoice against its purchase order and its posted receipt: quantity, unit cost and line total. If those three documents agree within the tolerance you configured, the invoice posts without a hold. The check confirms internal consistency between three documents BC already has.

It does not test any of them against what the vendor contract actually specifies, because the contract is not a document BC stores.

Three-way matching runs at the purchase line level. BC checks that the quantity invoiced does not exceed quantity received, and that unit cost on the invoice matches the unit cost on the purchase order within a set tolerance percentage or amount. A mismatch creates a warning or blocks posting, depending on your setup under Purchases & Payables Setup.

This catches a narrow, real class of error: a vendor invoicing for quantity never received, or a cost that drifted from the PO line at the point of invoicing. It is a genuinely useful control.

It does not test whether the PO price itself is correct. If a rate card change was never updated in the BC vendor price list, every invoice at the old rate matches its PO cleanly and posts without incident. The match is checking the invoice against BC's own records, not against the contract those records are supposed to reflect.

2. Which invoice exceptions can BC's standard reports actually surface?

BC's built-in tools for this are the Purchase Invoice/Order variance views, the Vendor Ledger Entries with applied vs. original amount, and posted purchase invoice statistics showing discrepancy between expected and invoiced cost. These surface documented mismatches: a received quantity that differs from invoiced quantity, or a posted cost that differs from the PO cost. They report differences between BC records, not differences between an invoice and a contract term BC was never given.

The Order Statistics FactBox on a purchase order shows invoiced versus received amounts side by side, useful for spotting a partial invoice or an over-bill against the PO. Vendor Ledger Entries can be filtered by amount and applied date to find unapplied credit memos, one genuine recovery source BC does track well because credit memos are documents it holds.

Where this stops: surcharge schedules, minimum volume commitments and rebate tiers are contract terms, not PO fields. A freight invoice can carry a fuel surcharge percentage that expired on the carrier's own tariff six months ago. BC has no field holding that expiration date, so no report inside BC will ever flag that line, no matter how the report is filtered or which fields it pulls.

3. How do you build a rate card outside BC to close the gap?

Close the gap by keeping a maintained reference, a spreadsheet or dedicated table, of the terms your contracts actually specify: current rate by SKU or lane, rebate tier thresholds, surcharge conditions and NTE caps by vendor. Export posted purchase invoice lines from BC on a schedule and join them against that reference outside the system. The join is where the real exception report lives, not inside any BC screen.

Structure the reference table by vendor and effective date, since rates change and an invoice has to be checked against the rate in force on its own invoice date, not today's rate. Include the source document, the specific contract clause or amendment, so a flagged line can be traced back to something a vendor can be shown.

Export posted purchase invoice lines using BC's standard data export or the OData API, matched on vendor number and item or G/L account. Bring both sets into a spreadsheet or a BI tool and calculate the delta between invoiced rate and contracted rate per line.

This is exactly the matching logic a fixed-scope engagement builds once against your full vendor contract file, rather than assembled and re-verified by hand every reporting cycle.

4. What belongs in an invoice exception report once you have a rate reference?

A useful exception report carries the invoice number, vendor, line amount, the contracted rate or term it should have matched, the delta in dollars, and the drift type: rate variance, expired surcharge, missed rebate, or NTE overrun. Sorting by dollar delta rather than by vendor or date puts the invoices worth investigating at the top, instead of burying them in a chronological list a controller has to read line by line.

Group by drift type rather than by vendor first. A rate variance and an NTE overrun require different follow-up: one is a pricing correction with the vendor, the other is a scope conversation about whether the work should have happened at all.

• Invoice and PO reference: The document numbers needed to pull the original invoice image and PO for verification before contacting the vendor.
• Contracted term matched: The specific rate card line, rebate tier or surcharge clause the invoice was checked against, with its source document.
• Dollar delta: Invoiced amount minus contracted amount, signed, so the report can be sorted by size of impact.
• Drift type: Rate variance, expired surcharge, missed rebate, duplicate payment or NTE overrun, so follow-up routes to the right owner.

5. Can Power BI or Jet Reports do this matching automatically?

Power BI and Jet Reports both connect cleanly to BC data and can automate the export half of this work, refreshing posted invoice lines on a schedule instead of a manual pull. Neither tool holds contract terms on its own. The rate card, rebate tier and surcharge reference still has to be built and kept current as a separate dataset that the report joins against, whichever visualization tool sits on top of it.

Power BI's native BC connector pulls purchase invoice lines, vendor ledger entries and PO data directly, refreshed on whatever cadence your Power BI license allows. Jet Reports works inside Excel against the same BC tables, which is useful if your AP team already lives in spreadsheets.

Both are reporting layers. The exception logic, what counts as a variance and against what reference, still has to be defined and maintained by someone. A dashboard that refreshes automatically against a contract reference nobody has updated in eight months will confidently report zero exceptions on invoices that are wrong.

6. Is this worth building in-house or should you get a one-time diagnostic first?

Building the rate reference and export logic in-house makes sense once you know which contracts and vendors are worth the ongoing maintenance. Before that is clear, a fixed-scope diagnostic against your existing BC data and contract file establishes which vendors and categories carry material drift, so the reporting structure you build afterward is built around real findings rather than a guess at where to start.

The in-house route costs staff time to build and, more significantly, staff time to maintain as contracts renew and rates change. That is a real ongoing cost, not a one-time build.

A diagnostic works from your posted BC invoice history and your actual vendor contracts, matched line by line, and hands back a prioritized list of where drift showed up and what it was worth. That list is what should determine whether a category gets a permanent reporting structure or gets checked periodically instead. Building the report before you know which vendors matter risks maintaining infrastructure around categories with nothing in them, and missing the one that does.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and what is margin erosion? causes and prevention for manufacturers.

7. Frequently Asked Questions (People Also Ask)

Does Business Central have a built-in field for contract rate cards?

No. Business Central stores vendor prices on purchase lines and item vendor catalogs, but it has no structure for a full rate card with volume tiers, effective dates and surcharge conditions. That reference has to be maintained separately and joined against BC data for reporting.

What is the difference between a BC posting variance and margin drift?

A posting variance is a mismatch between two BC documents, typically PO cost against invoiced cost. Margin drift is a mismatch between the invoice and what the vendor contract specifies, which BC cannot detect on its own because it never holds the contract term.

Can I set BC's three-way match tolerance to catch contract violations?

No. Tolerance settings control how much variance between PO and invoice cost is allowed before a hold triggers. Tightening tolerance catches more PO-to-invoice mismatches, but it still checks the invoice against the PO, not against the contract the PO was supposed to reflect.

Which BC report shows unapplied credit memos?

Vendor Ledger Entries, filtered to credit memo document type with a remaining amount greater than zero, shows credits issued but not yet applied against an invoice. This is one of the few exception types BC tracks natively and completely, since credit memos are documents it holds.

How often should the rate card reference be updated?

Update it whenever a contract renews, a rate amendment is signed, or a rebate tier threshold changes. A reference checked against stale rates will either flag invoices that are actually correct or, worse, clear invoices that are not, depending on which direction the rate moved.

Can Power BI connect directly to BC purchase invoice data?

Yes, Business Central has a native Power BI connector that exposes purchase invoice lines, vendor ledger entries and PO data for reporting. It automates the export step but does not supply the contract reference the exception logic needs.

What counts as an NTE overrun in a BC exception report?

An NTE, or not-to-exceed, overrun is an invoice line billed above a contractual cap agreed for that scope of work. BC has no field for the cap itself, so this requires the same external contract reference used for rate card and rebate checks.

Is this general information or legal advice about contract terms?

This is general information about reporting mechanics, not legal advice. Any dispute over contract interpretation, rebate entitlement or surcharge validity with a vendor should go through your legal or contracts function.

Should exception reporting replace the three-way match in BC?

No. The three-way match still catches quantity and cost mismatches between documents BC holds, which is worth keeping regardless. Contract-level exception reporting is an addition on top of it, not a replacement for it.