AP Exception Triage: How to Prioritize Which Invoices to Fix First

It's a Tuesday afternoon and the AP exception queue has 40 items in it. Nobody assigned them a priority. They're just sitting there in the order they landed, oldest at the top.

So the AP manager does what most people do with an unranked list: works top to bottom. Or, if a vendor called that morning, works whoever complained loudest.

Neither is a strategy. Working oldest-first means a $180 shipping variance from a low-volume vendor gets fixed before a $22,000 price discrepancy on an invoice that's two days from losing a 2% early-pay discount. Working loudest-vendor-first means the squeaky wheel gets the grease regardless of whether that vendor actually matters to the business.

Both approaches feel like progress. Neither one is prioritizing the exceptions that actually carry risk.

This is the natural follow-up to why invoice automation stalls once exceptions take over: once you accept that exceptions are where AP time actually goes, the next question is which ones to work first. That's what this post covers.

Why "Just Work Them in Order" Falls Apart at Scale

At low volume, arrival order is fine. Five exceptions a week, you can eyeball them and know which one matters. At 40, 100, or 300 a month, three variables start moving independently of each other, and none of them line up with "when did this land in the queue."

Dollar value varies independently of age. A $300 exception that's been sitting for three weeks isn't more urgent than a $40,000 exception that arrived yesterday, but oldest-first treats them the same.

Vendor relationship risk doesn't track with dollar value. A small-dollar exception with your single-source component supplier can matter more than a large one with a commodity vendor you could replace in a week. Dollar amount alone misses that.

Payment-term urgency runs on its own clock. An invoice with a 2/10 net 30 discount term has a hard deadline that has nothing to do with when it entered the queue or how much it's worth. Miss it by a day and the discount is gone regardless of how "important" the exception looked on paper.

Working exceptions in a single dimension, whichever dimension happens to be visible, means you're optimizing for the wrong thing most of the time. What's needed is a way to combine all three (plus one more: what actually caused the exception) into a single score that tells you what to open next.

A Practical Exception Scoring Framework

The goal isn't a complicated formula. It's a consistent way to rank exceptions across four dimensions that, together, capture most of what makes one exception more urgent than another.

Dollar amount. The most obvious dimension, and the easiest to score. Bucket invoices into ranges (for example, under $1,000, $1,000-$10,000, $10,000-$50,000, over $50,000) rather than trying to score exact amounts. Buckets are faster to apply consistently across a team than a precise formula, and precision doesn't add much value here.

Time to deadline. This is the dimension most triage systems miss entirely, and it's often the most costly one to ignore. Score based on days remaining until: the payment term lapses and the invoice risks going late, an early-pay discount window closes, or a vendor-imposed credit hold threshold is reached. An exception with 2 days left on a discount window should usually outrank a larger exception with 25 days of runway.

Vendor criticality. This one requires a one-time setup: tag vendors (or pull the tier from your vendor master if you already have one) as critical, standard, or low-risk based on factors like single-source dependency, contract terms, or historical relationship friction. A missing-receipt exception with a critical vendor deserves faster attention than the same exception type with a vendor you have three backup options for.

Root cause type. Not all exceptions take the same effort to resolve. A duplicate invoice flag might be closed in minutes once confirmed. A price variance tied to an email-approved change order can take days of back-and-forth. Categorizing by root cause (price variance, quantity/receipt mismatch, missing PO, duplicate, new vendor setup, GL coding ambiguity) helps route work to the right person and estimate how long it'll actually take, which matters when you're deciding what to start today versus what to schedule for later this week.

A simple way to combine them without building a data science project: score each dimension 1-3 (low, medium, high risk) and sum them. An exception scoring 10-12 gets worked today. One scoring 4-6 can typically wait a few days. This is intentionally rough. The point isn't statistical precision, it's replacing "whatever's on top of the pile" with a repeatable ranking your whole team applies the same way.

Setting Aging Thresholds That Actually Trigger Escalation

Scoring tells you what to work first today. Aging thresholds are what stop an exception from quietly sitting for three weeks because it never scored high enough to get picked up voluntarily.

The idea is simple: every exception gets a clock, and if it crosses a threshold unresolved, it escalates automatically rather than waiting for someone to notice.

The specific day counts should reflect your own payment terms and risk tolerance, not a fixed rule. Teams commonly set the first reminder somewhere around 2-4 days and the manager escalation somewhere around 5-10 days, adjusted down for anything with a discount window at stake. What matters more than the exact numbers is that the threshold triggers automatically instead of depending on someone remembering to check.

Combine the two systems and you get coverage on both ends: scoring surfaces what's most urgent right now, and aging thresholds guarantee nothing falls through simply because it was never the most urgent thing on any given day.

Escalation Paths: Who Owns What

A scoring and aging system only works if there's a clear answer to "who does this route to" for each type of exception. Without defined ownership, escalation just means the exception moves to a new queue and waits again.

A workable ownership model usually splits along root cause, since that's what determines who actually has the context to resolve it:

• Price variances typically route to the buyer or procurement contact who negotiated the PO. They can confirm whether a change was approved and where.
• Quantity and receipt mismatches route to whoever owns receiving or warehouse operations. AP can't resolve a "goods received but not logged" problem without them.
• Missing PO or new vendor setup routes to procurement or the requesting department, since AP usually isn't the one who initiated the purchase.
• GL coding ambiguity routes to the relevant cost-center owner or controller, not back to the vendor.
• Duplicate invoice flags can typically stay with AP itself; these rarely need outside input to close.

The pattern worth calling out: most exception types don't actually belong to AP to resolve. AP's job is closer to a dispatcher, routing the exception to whoever has the missing context, then tracking the response and following up if it stalls. That's the same coordination gap covered in more depth in the exceptions-stall-automation post: the bottleneck usually isn't AP's own workload, it's waiting on someone else who doesn't know they're being waited on.

Escalation should follow the same logic as the aging thresholds above: if the assigned owner hasn't acted within the threshold, it escalates to their manager, not back into a generic queue. A generic queue is where accountability disappears.

Before and After: A Worked Example

Here's a snapshot of the same 8-invoice exception queue, worked two different ways: oldest-first versus scored triage.

The oldest-first approach would have burned the morning on a $310 shipping variance while a $22,400 invoice quietly lost its discount window. That single miss costs more than a week of correctly triaged small exceptions saves. This is the practical case for scoring: it's not about working faster, it's about working the right one first.

When a Formal Triage System Is Overkill

None of this is worth building if your exception volume doesn't justify it.

If your team handles fewer than roughly 10-15 exceptions a week, a formal scoring model, defined escalation tiers, and routing rules are likely more overhead than the problem warrants. At that volume, an experienced AP lead can usually eyeball a short list and correctly judge what's urgent without a framework. Building out scoring criteria, training the team on it, and maintaining vendor criticality tags takes real setup time, and at low volume that time isn't paid back.

Formal triage earns its keep once exception volume is high enough that no single person can hold the full picture in their head, once the team is more than one or two people so consistency across reviewers matters, or once you've had at least one real incident (a missed discount, a strained vendor relationship, an audit finding) that a scoring system would have caught. Before that point, a short manual checklist ("check dollar amount, check deadline, check vendor tier") applied informally gets most of the benefit without the process overhead.

Frequently Asked Questions

What's the difference between exception triage and exception resolution?

Triage decides which exception gets worked next. Resolution is the actual work of closing it out (confirming a price change, chasing a receipt, correcting a GL code). A team can be efficient at resolution and still lose money if triage sends them to the wrong exception first.

Do I need software to run an exception scoring system?

No. A shared spreadsheet with the four scoring dimensions and a simple 1-3 scale can run a basic triage system for a small team. Software becomes worth it once volume is high enough that manual scoring itself becomes a time sink, or once you want scoring and escalation to happen automatically rather than depending on someone updating a sheet.

How often should aging thresholds be reviewed?

Most teams set them once and revisit quarterly, or after any incident where an exception aged past a point it shouldn't have. Thresholds tied to payment terms (like discount windows) should be checked whenever vendor terms change, since a threshold built around net 30 doesn't fit a vendor on net 15.

Should vendor criticality tags live in AP or procurement?

Procurement or vendor management typically owns the criticality assessment, since they have visibility into single-source risk and contract terms. AP consumes that tagging for triage purposes rather than creating it independently, which also keeps the tags consistent across other processes like sourcing and risk reviews.

What's a reasonable exception resolution time once triage is in place?

This varies by root cause and company, so treat any number as directional rather than a benchmark. Simple exceptions like confirmed duplicates often close same-day. Coordination-heavy exceptions involving vendor or cross-department follow-up commonly take several business days. Exception handling is also widely estimated to consume a meaningful share of total AP processing time, with industry estimates commonly landing in the 20-30% range (definitions vary, so treat it as directional), which is part of why prioritizing correctly inside that share matters.

Can triage scoring reduce the number of exceptions, not just prioritize them?

Not directly, but the root-cause categorization it requires often surfaces patterns worth fixing upstream. If a large share of high-scoring exceptions trace back to one vendor's consolidated billing or one buyer's missing PO discipline, that's a signal to fix the source rather than keep triaging the symptom.

Related reading

• Why Invoice Automation Stalls Once Exceptions Take Over — the coordination problem this triage system is built to manage
• 3 Way Matching in Accounts Payable — where exception queues originate in the first place
• Invoice Tolerance Policy: Setting AP Controls That Reduce False Exceptions — reducing exception volume at the source with better tolerance rules
• How Accounts Payable Teams Process 2x Invoice Volume Without Hiring — the throughput cost of an unmanaged exception queue