A coding or approval exception stops an invoice that may be perfectly accurate. The amount is right and the match may even have passed, but the invoice cannot post because it lacks correct general ledger coding, or it cannot pay because it falls outside the company's approval rules. These exceptions are about where the cost lands and who authorizes it.
They are common on non-PO invoices, where there is no order to inherit coding or approval from.
Accurate invoices still need a home and a signature
Two separate checks sit at the end of the invoice process. Coding assigns the invoice to the right general ledger account, cost center, and sometimes project or internal order, so the spend lands in the right place in the financial statements. Approval confirms that someone with authority has signed off. An invoice can fail either one independently of whether the amount is correct.
Miscoding distorts the numbers leadership relies on
A coding exception is raised when the account or cost center is missing, wrong, or ambiguous. On a PO-backed invoice the coding usually flows from the order, but a non-PO invoice arrives with none, and a clerk has to decide where it belongs. The judgment can be genuinely hard: a single repair invoice might split across two cost centers, or a service might map to different accounts depending on how it will be used. Getting it wrong creates rework and distorts the numbers a budget owner later relies on. See GL coding for the mechanics.
Approval delays are administrative, and they are avoidable
An approval exception is raised when an invoice falls outside the rules that decide who must sign off. The amount exceeds a threshold, the budget owner is out, the approver named on the order has left the company, or no one is clearly responsible for the spend. The invoice sits in a queue waiting for a signature, and the delay is administrative rather than a question of whether the invoice is correct.
Invoices wait on knowledge the systems never captured
Both types depend on knowledge the invoice does not carry. Correct coding depends on how the company organizes its accounts and how similar invoices were coded before. Correct approval depends on the current org chart and delegation of authority. When that context is out of date or lives in one person's head, invoices wait, and the wait is often longer than for a straightforward price or quantity gap.
Coding and routing should run on precedent, autonomously
A clerk codes the invoice using prior examples and the chart of accounts, then routes it to the right approver, chasing a backup when the named one is unavailable. Much of this is pattern-matching against how the same supplier and same kind of spend were handled before, which is exactly the sort of context a system can learn and apply.
Fragment codes invoices and routes approvals autonomously by reading the same general ledger logic and policy an experienced clerk applies, without ripping out or replacing your existing systems. See how it works or request a demo.