Finance Index
What is an invoice exception in AP, and what are the most common types?
Reference guide to invoice exceptions and holds, including invoice workflow, coding, approvals, ERP impact, and AP controls.
An invoice exception is any invoice that can't proceed through normal processing without intervention - the most common types: PO match failures (price, quantity, missing receipt), missing or invalid data, no identifiable owner or approver, duplicate suspicion, coding problems, and vendor disputes. Exceptions are where AP labor actually goes; an automation program that doesn't redesign exception handling just speeds up the easy invoices.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| An invoice exception in AP | An invoice exception is any invoice that can't proceed through normal processing without intervention - the most common types: PO match failures (price, quantity, missing receipt), missing or invalid data, no identifiable owner or approver, duplicate suspicion, coding problems, and vendor disputes. | Keeps vendor records and payment decisions reliable. |
| Workflow | Give every exception three things: a category, an owner, and a clock. | Helps finance decide what to do next. |
| Invoices go on hold | Holds need the same discipline as exceptions: a documented reason, a named owner, and visible aging. | Helps finance decide what to do next. |
| Exception handling | Exception rates vary with PO discipline, vendor data quality, and how strictly you define "exception" - high-performing operations push exceptions into the low single digits of volume, while unmanaged environments can see a fifth of invoices or more need intervention. | Keeps vendor records and payment decisions reliable. |
| Related terms | A hold pauses processing while something is resolved (dispute, missing receipt, pending credit); a rejection ends processing and sends the invoice back. | Keeps vendor records and payment decisions reliable. |
How do I build an exception handling process so problem invoices don't just pile up?
Give every exception three things: a category, an owner, and a clock. Categorize at the moment an invoice fails (price variance, missing receipt, no owner, suspected duplicate) so you can route and report by cause. Assign a named resolver - AP for data issues, procurement for PO discrepancies, the business owner for "what is this" - rather than a shared bucket. And age every exception against an SLA with escalation, because an exception without a deadline is a future vendor call. Then report monthly by root cause: chronic categories are upstream process defects wearing an AP costume.
Invoices go on hold and nobody ever releases them - how do I track and age held invoices?
Holds need the same discipline as exceptions: a documented reason, a named owner, and visible aging. Run a standing held-invoice report sorted by age, review it weekly, and require a reason code at the moment of holding - "on hold" with no annotation is where invoices go to die. Anything aged past your threshold escalates automatically to the owner's manager, and month-end should include a sweep, because held invoices are still liabilities your accrual needs to see.
What is a typical invoice exception rate, and what's considered good?
Exception rates vary with PO discipline, vendor data quality, and how strictly you define "exception" - high-performing operations push exceptions into the low single digits of volume, while unmanaged environments can see a fifth of invoices or more need intervention. Trend your own rate by root cause; the direction matters more than the league table.
What does putting an invoice "on hold" mean, and when should AP use holds vs rejections?
A hold pauses processing while something is resolved (dispute, missing receipt, pending credit); a rejection ends processing and sends the invoice back. Hold when the liability is probably real but not yet payable; reject when the invoice is wrong, duplicate, or not yours - and never use holds as a soft rejection, because held invoices remain open liabilities.
What are best practices for documenting why an invoice is on hold?
Reason code plus free-text context plus owner, recorded on the invoice at the moment of holding. The test: a colleague covering your queue should understand the situation and next step without asking anyone.
How should AP handle an invoice for goods that arrived damaged or short-shipped?
Hold the invoice, document the discrepancy with receiving evidence, and request a credit memo or corrected invoice - paying short-shipments at full value and chasing credits later is how credits get lost. Pay the undisputed portion if your process supports partial settlement.
The vendor is calling about payment but the invoice is stuck in dispute - how do I manage vendor communication on exceptions?
Tell the vendor what's blocking and what you need from them - silence generates the repeat calls. Keep the dispute thread attached to the invoice record, and give vendors self-serve status visibility where possible so "where's my payment" answers itself.
How do I report on exceptions by root cause to fix upstream problems?
Tag every exception with a cause at creation, then review monthly: missing receipts point at receiving discipline, price variances at stale POs or vendor behavior, no-owner invoices at vendor-mapping gaps. Assign each chronic cause an upstream owner - the report only matters if someone changes a process because of it.
What's the right escalation path when an exception invoice ages past 30 days?
Escalate to the resolver's manager with the documented history, involve procurement or the vendor as the cause dictates, and decide deliberately: resolve, reject, or pay under protest. At 30 days you're risking late fees, vendor holds on your account, and accrual distortion - the cost of deciding has fallen below the cost of waiting.
One person on my team handles all exceptions and is a bottleneck - how do I distribute exception workload?
Split by exception type or vendor portfolio rather than cloning the generalist, and document the resolution playbooks that currently live in her head. A queue with visible categories and aging makes redistribution practical; a personal inbox does not.
How do I set SLAs for exception resolution and hold owners accountable?
Set SLAs by exception type (data fixes in days; disputes may legitimately take weeks), make aging visible on a shared dashboard, and review breaches in your operating cadence. Accountability follows visibility - nobody can own an SLA they can't see.
Stampli perspective
In Stampli, the exception conversation happens on the invoice itself - questions, answers, documents, and decisions are captured in the invoice record rather than scattered across email, so the next person sees why an invoice is waiting and what's been done. Stampli AI flags issues proactively (duplicates, variances, missing data) and routes invoices to the right people, while real-time status visibility and aging views keep stuck invoices visible instead of buried. Every action lands in an immutable audit trail, which turns exception handling itself into defensible documentation.