An invoice exception is a supplier invoice that fails automatic matching or validation and has to be routed to a person before it can be approved and posted.
An invoice exception is any supplier invoice that cannot complete its automated path and stops for human judgement. The trigger can be a mismatch, where the price, quantity or currency differs from the purchase order or the receipt, or a validation failure, where the invoice has no order reference, an unknown vendor, missing tax details, an incomplete coding or the same number as an invoice already posted. The word describes the state of the document, not its fate: most exceptions turn out to be legitimate invoices that simply need a decision.
Exceptions are where the cost of accounts payable actually sits. A matched invoice consumes machine time; an exception consumes a person's attention, usually more than once, plus an email to a buyer and often a call to the supplier. The delay has second order effects: the invoice sits unposted, so the liability is known but not in the ledger, the accrual position at month end is wrong, early payment discount windows expire while the question is open, and the supplier chases payment on a statement the accounting team cannot reconcile. A high exception volume also hides genuine problems, because a real overbilling looks identical to a rounding difference in an undifferentiated queue.
Business Central handles the mismatch case by refusing to post: quantities to invoice above quantities received produce an error at posting time, which is a hard stop rather than a managed exception. There is no standard exception object with a status, an owner, a reason code and an age, and no queue that lists everything currently blocked. Incoming Documents can hold a captured invoice that is not yet linked to a purchase document, which is the closest native holding area, and approval workflows can route a document to a person, although approval answers a different question from exception resolution. Teams therefore either accept manual triage or add a layer on top; the accounts payable automation guide covers what that layer usually needs to do.
Example: an invoice from a tooling vendor bills 120 units at CHF 12.50, so CHF 1,500, while the order priced them at CHF 11.90, so CHF 1,428. The CHF 72 gap is five percent and no one is authorised to release it silently. Payment terms are 2/10 net 30. If the query takes eleven working days to resolve, the two percent discount worth CHF 30 is gone, and the invoice still has to be paid in full at day 30.
The classic failure is that exceptions live in an email inbox, so nobody can say how many are open, how old the oldest is, or which vendors cause them. Teams that manage this properly assign a reason code at the moment the exception is raised, then look at the distribution: price differences, quantity differences, missing orders, coding gaps. Useful measures are the exception rate as a share of invoice volume, the average age of open exceptions, and the concentration, since a small number of vendors and a small number of buyers usually generate most of them.
No. An exception means the automated path stopped and a person has to decide. Most exceptions end in a posted invoice, sometimes after a price correction or a credit memo; rejection is only one of the possible outcomes.
There is no universal number, and it depends far more on your purchasing discipline than on your software: orders raised after the fact, loose price maintenance and missing receipts all convert directly into exceptions. Measuring your own rate by reason code over a few months is more useful than any benchmark.
Zentriq's AI tools automate many of the manual processes around invoice exception in Business Central. Learn about the Zentriq Agent or try Zentriq PunchOut to see how AI simplifies procurement in BC.