AP exception handling: a Controller guide

Executive Summary

An AP exception is any invoice that does not clear match automatically: a price variance, a missing receipt, a duplicate-looking invoice number, a surcharge with no corresponding contract line. The mechanism that causes exceptions to pile up is not volume. It is the absence of a rule that says who decides, on what evidence, within what time.

Without that rule, exceptions get resolved by whoever is closest to the deadline, using judgment instead of the contract. That is how a stale rate card survives multiple renewal cycles: nobody with the authority to reject the invoice ever saw the current rate card at the moment the invoice was open.

What changes it is treating the exception queue as a control, not a backlog. That means a written escalation path, a required reference document for every override, and an aging report a Controller reviews on its own, separate from the general AP aging report used for cash management.

1. What counts as an AP exception?

An AP exception is any invoice that fails automated three-way matching: a price that does not equal the purchase order, a quantity that does not equal the receipt, a duplicate invoice number, or a charge line with no PO reference at all. It also includes invoices that pass three-way matching but do not match the underlying vendor contract, such as a surcharge or rate that the PO carried forward without checking against the current agreement.

Three-way matching checks the invoice against the purchase order and the receipt. It confirms the quantity and a price field agree with what was ordered and received. It does not test whether the PO itself still reflects the current contract.

That second category is the one that survives longest, because the system reports no exception. The invoice matches its PO. The PO was built from a rate card that expired a renewal cycle ago. Nothing in the match logic looks at the contract document itself.

A Controller's exception definition should include both categories explicitly, in the AP procedure document, not just in the ERP's match tolerance settings. If the written definition only covers match failures, the second category never gets counted, staffed, or reported, and it accumulates silently until a margin gap shows up in gross margin analysis with no line-item explanation.

2. Who should have authority to resolve an exception?

Authority should scale with what the exception is testing, not with invoice dollar value alone. A quantity variance against a receipt is an operations question and belongs with the receiving team. A price variance against a rate card or a surcharge with no contract basis is a contract question and belongs with whoever owns that vendor relationship, with the Controller's office holding override authority above a stated threshold.

A common failure is routing every exception to whichever AP clerk has queue access, regardless of what the exception is actually testing. A clerk resolving a price variance against a contract they have never read will approve the invoice as billed, because nothing in their role gives them the standing to reject it.

The fix is a routing table, not a policy statement: which exception type goes to which role, and what document that role must reference before approving. Receiving discrepancies go to operations, referencing the receipt. Rate and surcharge discrepancies go to the vendor owner or Controller's office, referencing the current contract, not the PO.

A. Escalation thresholds

Set a dollar threshold above which no single approver can clear an exception without a second reviewer. This is a standard segregation-of-duties control, and it catches the exceptions large enough to matter for close, not the routine quantity roundings that clear on their own.

B. Reference document requirement

Require the approver to name the document they checked: PO, receipt, or contract clause. An approval with no referenced document is the exception a later audit cannot explain, because nobody recorded what was actually verified at the time.

3. How does an unresolved exception affect the close?

An unresolved exception at month-end forces a choice between accruing an estimate or holding the close open, and neither is free. An estimate that turns out wrong restates a prior period. A held close delays every downstream report that depends on it. Neither problem is really about the exception itself; it is about how long it sat unresolved before the close deadline made the choice for you.

The AP aging report used for cash management is not built to flag this. It sorts by days outstanding for payment, not by days an exception has sat unresolved. An invoice can be current for payment purposes and still be an open, unverified exception for accuracy purposes.

A Controller reviewing only the standard aging report misses this distinction entirely. The fix is a second report, or a filtered view of the same data, that ages exceptions by days since flagged rather than days since invoice date, reviewed on its own before each close.

The guide on month-end close for multi-entity manufacturers covers how this compounds when the same exception type recurs across entities with separate AP teams and no shared exception log between them.

4. What documentation does an exception need to leave behind?

Every resolved exception needs three things on file: the reason it was flagged, the document referenced to resolve it, and the name of who approved it. Without those three, the resolution cannot be tested later, and a pattern across many invoices, such as a surcharge recurring after it should have expired, is invisible because nobody can query for it.

This documentation is what makes an exception process auditable rather than anecdotal. A general note in a comment field is not enough, because it cannot be aggregated across invoices or vendors.

Structure it as data instead: an exception type code, a resolution code, a referenced document, and an approver. That structure lets a Controller run a query at quarter-end and ask which vendors generate the most reference-document overrides, without reading every comment individually.

This documentation also becomes the evidentiary basis if a finding needs to go to the board. The guide on explaining an unexplained gross margin gap to your board or sponsor covers what that evidence needs to show once it leaves the AP function.

5. Can AP exception handling prevent margin drift, or only catch it after the fact?

Exception handling built on three-way matching is a detection control, not a prevention control: it catches variances against the PO, which is itself only as current as the last time someone updated it against the contract. It cannot test a clause the PO was never built to reflect, such as a volume tier trigger or a rebate condition living only in the contract PDF.

This is a mechanical limit, not a staffing problem. The PO is a snapshot taken when the order was placed. The contract can have terms that only activate later: a volume tier that triggers after a cumulative threshold, a rebate that accrues quarterly, an NTE cap that applies across multiple invoices rather than one.

None of those conditions live inside a single PO-to-invoice comparison. An exception process built only on matching will never flag them, because nothing about them looks like a variance at the line level.

Closing that gap requires checking the invoice stream against the contract terms directly, on a recurring basis, separate from the transactional exception queue. That is a periodic or continuous compliance check, not an AP exception workflow, and it is worth knowing the difference before assuming the exception queue already catches this.

6. How should a Controller staff and report on the exception process?

Staff the exception queue with a named owner per exception category, not a rotating shared queue, and report exception volume and aging to the Controller directly, on a cadence tied to close rather than folded into general AP metrics. A shared queue with no category ownership is where accountability for a specific recurring vendor issue disappears.

A rotating queue optimizes for clearing volume, which is the wrong metric here. It rewards fast resolution over correct resolution, and a fast, wrong resolution against a contract nobody checked looks identical in the metrics to a fast, correct one.

Named ownership by category, freight, contract labor, MRO, professional services, lets the same person see a recurring pattern across invoices from the same vendor, which a rotating assignment structure will not surface.

Whether that ownership sits inside the existing AP team or moves to a managed services arrangement is a separate decision, covered in the comparison of finance managed services against in-house AP. Either way, the reporting line to the Controller should not change: exception volume, aging, and override rate belong on a Controller-level report, reviewed before close, not buried in an AP team's internal dashboard.

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

7. Frequently Asked Questions (People Also Ask)

What is the difference between an AP exception and a discrepancy?

In practice the terms are used interchangeably. Both describe an invoice that failed some check, whether a match against the purchase order and receipt, or a check against contract terms. What matters for a Controller is which check failed, because that determines who has the standing to resolve it.

Should a Controller review every AP exception personally?

No. A Controller should review the aging and pattern report, and personally approve overrides above the escalation threshold. Reviewing every individual exception does not scale and pulls the Controller into transactional work that a routing table should handle instead.

Does ERP three-way matching already cover contract compliance?

No. Three-way matching checks the invoice against the purchase order and the receipt. It does not check the purchase order against the current contract, so a stale rate card or an expired surcharge can pass matching cleanly while still violating the contract.

What should trigger a second reviewer on an exception?

A dollar threshold set in advance, applied consistently regardless of vendor or approver seniority. Below the threshold a single named approver with a referenced document is sufficient; above it, a second reviewer is required as a standard segregation-of-duties control.

How long should an exception stay unresolved before it affects the close?

There is no single correct number without knowing your close calendar, but the point is to set one explicitly and track days-since-flagged separately from days-since-invoice-date, so an exception does not silently roll into an accrual estimate by default.

Can contract labor and freight exceptions be handled the same way?

The routing principle is the same, name an owner and require a referenced document, but the reference document differs: a freight exception typically references a rate schedule or fuel surcharge basis, while a contract labor exception references a rate card or an NTE cap in the staffing agreement.

What happens if an exception is approved with no reference document on file?

It clears the queue but leaves nothing to test later. If a pattern of overbilling from that vendor surfaces months afterward, there is no record of what was checked at approval time, which weakens both the internal control and any recovery claim against the vendor.

Is exception handling the same thing as an AP recovery audit?

No. Exception handling is a forward-looking, transaction-by-transaction control applied as invoices arrive. An AP recovery audit is retrospective, reviewing invoices already paid to find duplicate payments, overbilling, or unclaimed credits the exception process missed at the time.