🎧 Listen to this article (14 min)
Most procurement teams can tell you how many purchase order exceptions they got last week. Far fewer can tell you how long the average exception sat before someone resolved it, or how many of them were the same exception showing up for the third time.
That gap matters. Detection is mostly a solved problem now. Plenty of teams have alerts, flags, and dashboards that surface a late acknowledgement or a changed ship date. What they do not have is a resolution process that keeps pace with detection. So the alerts pile up, the buyers triage by whoever emailed loudest, and the backlog quietly becomes the real constraint on the procurement function.
This is about the second half of the problem. Not how to find exceptions, but how to clear them faster with the team you already have.
An exception is any purchase order that stops behaving the way the plan assumed. The supplier never acknowledged it. The acknowledged date moved. The quantity came back short. The unit price on the confirmation does not match the PO. The promised date passed with no shipment and no update.
A backlog is the set of those exceptions that have been identified but not resolved. Resolution means the PO is either back in agreement with the plan or the plan has been updated to reflect reality. An exception that someone looked at, sighed about, and left open is still in the backlog.
The reason backlogs are invisible in most organizations is that exceptions live in email. A buyer sees a flag in the ERP, sends a message to the supplier, and then the thread leaves the system entirely. There is no timestamp on resolution, no aging clock, and no record that the same supplier did the same thing last month. The work happens, but it is unmeasurable, so it is unmanageable.
According to Gartner, 50% of purchase order lines undergo changes after issuance, making real-time supplier visibility a procurement priority. Half your lines moving is not an anomaly to be handled case by case. It is the normal operating condition, and it needs a process built for volume.
Three things drive backlog growth, and none of them are fixed by hiring another buyer.
The first is that detection scales and resolution does not. Once you put monitoring in place, you surface every deviation, including the ones that used to slip past unnoticed. Intake volume jumps. Resolution capacity stays flat because it is still one person writing one email at a time.
The second is the confirmation loop. A single exception rarely takes one message. It takes a message, a wait, a partial answer, a clarifying message, another wait, and then an update. Each round trip adds a day or more. The actual work is maybe four minutes of a buyer's time. The elapsed time is a week. Backlogs are made of elapsed time, not effort.
The third is recurrence. If you resolve an exception without recording why it happened, the same supplier generates the same exception again. A team that resolves 80 exceptions a week and regenerates 30 of them is running to stand still.
A Deloitte supply chain study found that 70% of supply chain disruptions originate before materials leave the supplier's facility. That is precisely the window exception backlogs cover. Every day an exception sits unresolved is a day you are carrying a disruption you already know about.
Before changing anything, get a baseline. These four measures are enough, and you can usually assemble them from ERP data plus a sample of buyer inboxes.
For every open exception, count days since it was flagged. Then look at the distribution rather than the average. Averages hide the tail, and the tail is what hurts you. A team with a 3 day average and a 40 day ninety-fifth percentile has a serious problem that the average conceals entirely.
How many separate messages does it take to close one exception? Count both directions. Anything above three suggests the first message is not asking for the right information, or is asking a supplier who cannot answer it.
What share of this month's exceptions came from a supplier and failure mode that also appeared last month? A high recurrence rate means you are treating symptoms. This number usually surprises people the first time they calculate it.
Fully loaded buyer time per exception, plus the downstream cost when resolution arrives too late to act on. The second part is harder to quantify but far larger. An exception resolved after the production schedule locked did not really get resolved.
The single biggest source of wasted capacity in exception handling is treating a cosmetic price variance the same as a missing acknowledgement on a long lead time component. Sort your exception types into three tiers and handle each differently.
Tier one, auto-resolve. Deviations inside a tolerance band you have already decided you accept. A ship date that moved two days on a part with four weeks of buffer. A quantity variance under a defined threshold. These should be recorded and closed without a human touching them. Set the tolerances deliberately, then stop looking at what falls inside them.
Tier two, chase automatically. Missing information. No acknowledgement, no ship date, no response. There is nothing for a buyer to decide here. The task is to obtain a fact from a supplier, and that is a follow-up sequence, not a judgment call. This tier is usually the largest share of volume and the easiest to remove from human hands.
Tier three, escalate to a person. Genuine conflicts. A date that moved past the need date. A price change that breaks the contract. A short shipment on a constrained part. These deserve buyer attention, and they get it faster when tiers one and two are no longer competing for the same attention.
Most teams find that tier three is somewhere between 10% and 20% of total exception volume. That is the real workload. Everything else is administrative throughput that was never a good use of a buyer.
The fastest single improvement is asking for everything you need in the first message. Most follow-up emails ask a supplier to "confirm the PO." That invites a one line reply that answers nothing. A structured request that names the PO, the line, the current promised date, the quantity, and asks for a specific confirmation of each gets a usable answer in one round trip instead of three.
This is mechanical, which means it can be generated rather than written. Our approach to systematic exception handling starts here, because compressing three round trips into one cuts elapsed resolution time by more than any other change.
Tier two exceptions need persistence, not intelligence. A follow-up that fires on a schedule, escalates to a second contact after a set interval, and stops the moment a usable reply arrives will clear more of the backlog than a buyer working the same list manually, because it never gets distracted by tier three work.
Aberdeen Group research shows that automated PO tracking reduces operational costs by up to 30% for mid-market manufacturers. The savings do not come from eliminating people. They come from eliminating the elapsed time that turns a small exception into a schedule problem.
Shared exception queues create diffusion of responsibility. Every exception should have a named owner from the moment it is created, assigned by supplier, category, or plant rather than pulled from a pool. Ownership is what makes aging data actionable, because an aging report with no owner column is just a list of complaints.
If a supplier confirms a new date by email and a buyer updates the ERP by hand, two things go wrong. The update is delayed, and sometimes it does not happen at all. Resolution has to land in the ERP automatically for the backlog number to mean anything. This is also what makes recurrence measurable, since you need a structured record of what happened to detect that it happened before.
Whether your procurement team runs on SAP, Oracle NetSuite, Microsoft Dynamics 365, Epicor, or Infor, the exception backlog problem is broadly the same, because none of these systems were designed to manage an inbox. They track what the PO says and what was received. The negotiation in between happens somewhere else.
For teams running Microsoft Dynamics 365, whether Business Central, Finance and Supply Chain, or Navision, Leverage AI integrates directly with your existing ERP environment to automate supplier PO confirmations, flag exceptions in real time, and surface OTIF data without custom development or ERP modification. The same pattern applies regardless of platform, which is why we treat this as an ERP-agnostic problem rather than a module question. A deeper look at the Dynamics case is available in our guide to Dynamics 365 procurement automation and PO visibility.
IDC projects that 60% of enterprise procurement teams will transition to AI-powered automation by 2025. The teams getting value from that transition are generally not the ones who automated detection. They are the ones who automated the response.
Days 1 to 30, measure and tier. Pull every open exception into one list with a flag date and an owner. Calculate the four baseline numbers. Sort your exception types into the three tiers and write down the tolerance bands for tier one. Expect this step to be uncomfortable, because the aging tail is usually worse than anyone believed.
Days 31 to 60, automate tier one and tier two. Turn on auto-close for in-tolerance deviations. Stand up structured follow-up sequences for missing information. Do not try to automate tier three. Measure the change in intake volume reaching buyers, which should drop sharply.
Days 61 to 90, attack recurrence. With clean structured data on what failed and why, identify the suppliers generating disproportionate exception volume. Take that data into supplier reviews. Recurrence is a supplier performance conversation, and it only becomes possible once you have a record.
This sequencing matters. Teams that try to fix recurrence first fail, because they do not have the data. Teams that automate before tiering end up automating the wrong things.
Track the same four numbers monthly. The pattern of a healthy program is aging distribution tightening first, then touches per resolution falling, then recurrence declining over a couple of quarters as supplier conversations take effect. Cost per exception moves last, and it moves the most.
Connect the backlog metrics to delivery performance as well. Exception resolution time is a leading indicator of OTIF, and OTIF is what the rest of the business actually feels. Our guide on tracking supplier OTIF when ERP data is incomplete covers how to connect the two, and the PO tracking automation ROI model shows how resolution time translates into dollars.
According to McKinsey, companies with mature supply chain visibility capabilities outperform peers by 15-20% on OTIF metrics. That advantage is not built on knowing about problems sooner. It is built on closing them faster. You can see how the full workflow fits together on our product overview.
It is the set of purchase order exceptions that have been identified but not yet resolved. An exception is resolved when the PO matches the plan again or the plan has been updated to match reality. Exceptions that have been seen but not closed still count toward the backlog.
It depends on tier. In-tolerance deviations should close automatically the same day. Missing information exceptions should close within two to three business days with an automated follow-up sequence. Genuine conflicts requiring buyer judgment vary, but they should be owned and aging-tracked from day one rather than sitting in a shared queue.
Because you are now seeing deviations that previously went unnoticed. The underlying rate did not change. This is expected and is not a reason to turn monitoring off. It is the reason to build tiering and automated response at the same time rather than afterward.
ERP systems track what the PO states and what was received. They generally do not manage the supplier correspondence that resolves the difference, because that happens over email. Most teams need a layer that captures those replies, structures them, and writes confirmed changes back into the ERP.
Teams measuring it for the first time often find 30% or more of exceptions repeat from the same supplier and failure mode. Bringing that below 15% through supplier performance conversations is a reasonable first target, and it compounds, since every avoided recurrence is an exception that never enters the backlog.
Usually not. In most backlogs, 80% or more of the volume is in tiers one and two, which are administrative rather than analytical. Automating those tiers typically frees enough capacity to clear the tier three work without adding people.