How do you report on invoice exceptions in Acumatica?

Executive Summary

Acumatica reports invoice exceptions through two native paths: the AP Bills and Adjustments screen with its match status field, and the Approval Map history that logs why a bill was held or rejected. Both are built against structured data already inside Acumatica: the purchase order, the receipt, and the bill line. When those three disagree, an exception fires.

The mechanism that causes drift to survive this reporting is simple. Contract terms like rate card tiers, minimum volume commitments, and surcharge expiration dates usually live in a PDF outside Acumatica, not as a rule the matching engine checks. An invoice that matches its PO perfectly can still be wrong against the contract, and Acumatica's exception report has no field for that comparison.

What changes it is treating Acumatica's exception report as the first filter, not the whole audit. It clears the invoices with no contract question at all, then a separate review against the actual contract terms picks up what's left.

1. What counts as an invoice exception in Acumatica?

An invoice exception in Acumatica is a bill that fails a structured check against data already in the system: a quantity or price variance against the linked purchase order, a missing or short receipt, a duplicate reference number, or a hold triggered by the approval map. Each of these is visible on the AP Bills and Adjustments screen through the match status and approval status fields, and each can be filtered into a report without custom development.

Acumatica evaluates a bill against the PO it references and the receipt tied to that PO. If the invoiced quantity exceeds the received quantity, or the unit price differs from the PO line by more than the configured tolerance, the system marks the bill as unmatched and routes it for review rather than posting it straight through.

Duplicate detection works off vendor reference number and amount. If a second bill arrives with the same vendor invoice number, Acumatica flags it before it reaches approval.

Approval map holds are a separate category. A bill can match its PO perfectly and still sit in exception status because it exceeds an approver's authorized amount or triggers a condition built into the workflow, like a new vendor or a missing tax ID.

2. Where do you find exception reports in Acumatica?

Exception visibility in Acumatica comes from three places: the AP Bills and Adjustments list filtered by match or approval status, the Approvals screen showing pending and rejected items with reasons, and the generic inquiry screen if a controller builds a custom view joining bill, PO, and receipt tables. None of these require a third-party add-on for the matching Acumatica already performs.

The bill list is the fastest starting point. Sorting by match status separates fully matched bills from those flagged for quantity, price, or receipt variance, and an AP lead can work that queue in order of dollar exposure.

The Approvals screen tells a different story: not what failed matching, but what a human decided to hold or reject, and why, since Acumatica logs the approver's comment against the bill.

For a recurring report, a generic inquiry built once against the AP Bill, PO, and PO Receipt tables gives a standing view that refreshes automatically, which is usually more durable than exporting the bill list by hand each month.

3. What exceptions does Acumatica's matching miss?

Three-way matching checks the invoice against the purchase order and the receipt; it does not test whether the unit price on the PO still reflects the current contract rate, whether a volume tier discount applied correctly, or whether a fuel surcharge should have expired months ago. Those checks require a rate card and contract terms as the reference point, and Acumatica has no field that stores a rebate clause or a surcharge trigger condition.

A PO can be created with a stale unit price and the invoice will match it exactly. Acumatica has no exception for that because nothing in the system contradicts the PO line. The match passes and the overcharge is never on any exception list.

The same is true for volume commitments. If a contract discounts pricing once a quarterly spend threshold is crossed, Acumatica does not track the running total against that clause, so the invoice that should have received the lower rate posts at the higher one with no flag.

Rebate clauses and surcharge expirations sit entirely outside Acumatica's data model. They live in the contract document, and a document is not a table the matching engine can query.

4. How do rate card and surcharge exceptions differ from a matching exception?

A matching exception is a disagreement between two records already in Acumatica: bill versus PO versus receipt. A contract compliance exception is a disagreement between the invoice and a document Acumatica never ingests: the vendor contract itself. The first is solved by tightening tolerances and approval rules inside the ERP.

The second requires reading the contract and building a rule the ERP was never asked to check.

This distinction matters because it changes who fixes it. A matching exception gets resolved by AP: chase the receipt, correct the PO, override the tolerance.

A contract compliance exception gets resolved by comparing the invoice line to the actual rate schedule, volume tier, or surcharge clause in the signed agreement, which usually means someone opening the contract PDF and doing the comparison by hand or building a rule engine that ingests those terms separately from Acumatica.

A. Matching exception

Bill disagrees with PO or receipt already in Acumatica. Fixed inside AP: correct the PO, chase the receipt, or override with authorization.

B. Contract compliance exception

Bill agrees with the PO but the PO itself no longer reflects the contract: a stale rate, an uncredited rebate, a surcharge past its expiration condition. Fixed by comparing the invoice to the contract document directly.

5. Can you build contract compliance checks inside Acumatica?

Acumatica's generic inquiry and business rule tools can encode a fixed rate or a fixed tolerance once someone enters it manually, so a single rate card can be built into a validation rule. What it cannot do natively is read a contract PDF, track a rolling volume commitment against a trailing period, or catch a surcharge that should have expired on a date nobody entered as a system field.

For a small number of high-value vendor contracts, a controller can manually enter the current contracted rate as a reference value and build a business rule that flags any bill priced above it. This works, but it only stays accurate if someone updates that reference value every time the contract is renegotiated.

Volume tiers are harder. They require summing invoice amounts for a vendor over a rolling period and comparing that running total against a threshold that changes the rate going forward, which Acumatica's native rule engine is not built to compute continuously.

Surcharge expiration is the hardest case. A fuel surcharge tied to a diesel price index or a temporary accessorial fee has a condition for when it should stop, and unless someone builds a scheduled check against that specific condition, the surcharge keeps appearing on invoices indefinitely with no exception raised.

6. Should you build custom matching in Acumatica or run a separate audit?

Building custom contract logic inside Acumatica makes sense for a handful of high-volume vendors where the terms are stable and worth encoding once. It makes less sense for the full population of service vendor contracts, most of which change terms often enough that a rule built today is wrong by the next renewal. A periodic audit against the actual contract file catches what a static rule would have missed by then.

The trade-off is maintenance versus coverage. A custom business rule inside Acumatica covers exactly the contracts someone took the time to encode, and stays accurate only as long as someone updates it.

A periodic review of invoices against the underlying contract documents covers whatever vendors are in scope for that review, regardless of whether anyone built a rule for them, and it catches drift that accumulated since the last check rather than only going forward.

Most manufacturers end up doing both: native matching handles the volume, high-dollar and slow-moving structured exceptions, and a separate audit picks up the rate card, volume tier, and surcharge questions matching was never built to answer.

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 Acumatica flag a vendor invoice that is priced above the contract rate?

Only if the purchase order itself was created at the correct contract rate. Acumatica compares the invoice to the PO, not to the contract document, so an invoice matching a stale or incorrect PO price passes with no exception raised.

Can Acumatica track volume-based rebate clauses automatically?

Not natively. Acumatica has no built-in field for a rolling volume threshold tied to a rebate or discount tier. Tracking that requires either a custom report summing vendor spend over the contract period or a review conducted outside the ERP.

What is the difference between a three-way match exception and a contract compliance exception?

A three-way match exception compares the bill, purchase order, and receipt, all records inside Acumatica. A contract compliance exception compares the bill to the vendor contract itself, a document Acumatica does not ingest or reference in its matching logic.

Where does Acumatica log why an invoice was held for approval?

On the Approvals screen, which records the approver's action and any comment against the specific bill. This shows workflow-driven holds, such as exceeding an authorization limit, separately from matching-driven exceptions like a quantity variance.

Can a generic inquiry in Acumatica replace a contract compliance review?

A generic inquiry can surface structured exceptions already present in the bill, PO, and receipt tables. It cannot read a contract PDF or evaluate a rebate clause, so it narrows the population needing manual review rather than replacing that review.

Should every vendor invoice get checked against its contract manually?

That depends on vendor volume and contract complexity. High-spend service vendors with rate cards, tiers, or surcharge clauses are the ones where a manual or periodic contract comparison catches drift that native matching structurally cannot see.

Does upgrading to a newer Acumatica version add contract-level matching?

Acumatica's matching has stayed focused on PO, receipt, and bill reconciliation across versions. Contract terms living outside the ERP, in a separate document, are not something a version upgrade changes; that gap is closed by process or by a separate review, not by the platform.

What data does a contract compliance review need that Acumatica does not store?

It needs the actual rate card, volume tier schedule, rebate clause language, and surcharge trigger conditions from the signed contract, plus the invoice history to compare against them. Acumatica stores the invoice and PO but not the contract terms themselves.