---
title: What Counts as a PO Exception? Types, Tolerances, and Resolution Owners
description: A PO exception is any gap between what your purchase order says and what the supplier confirmed. The seven types worth tracking, how to set tolerances that cut noise, and who should own resolution for each.
image: https://tryleverage.ai/hubfs/blog-covers/cover-po-exception-types-tolerances-resolution-owners.png
---
[Skip to main content](https://tryleverage.ai/blog/pf/po-exception-types-tolerances-resolution-owners#main-content)
[   ](https://tryleverage.ai)
- Show submenu for Platform Platform
- [CONNECT: Integrations](https://tryleverage.ai/integrations)
- [PARSE: Document Parsing](https://tryleverage.ai/document-parsing)
- [MEASURE: Supplier Performance](https://tryleverage.ai/supplier-performance)
- [PAY: Trade Finance](https://tryleverage.ai/payments)
- [ENGAGE: PO Automation](https://tryleverage.ai/purchase-order-automation)
- [TRACK: Shipments](https://tryleverage.ai/shipment-tracking)
- [COPILOT: AI Agents](https://tryleverage.ai/artificial-intelligence)
- Show submenu for Case Studies Case Studies
- [Manufacturing](https://tryleverage.ai/case-study-manufacturing)
- [Distribution](https://tryleverage.ai/case-study-distribution)
- [Pharma & Biotechnology](https://tryleverage.ai/case-study-pharma-biotechnology)
- [Food Production](https://tryleverage.ai/case-study-food-production)
- [Furniture](https://tryleverage.ai/case-study-furniture)
- [Supplements](https://tryleverage.ai/case-study-supplements-manufacturing)
- [Packaging](https://tryleverage.ai/case-study-packaging-manufacturing)
- [Automotive Parts Distributor](https://tryleverage.ai/case-study-auto-parts-distributor)
- [Commercial Equipment](https://tryleverage.ai/case-study-commercial-equipment)
- [Wood Processing Equipment](https://tryleverage.ai/case-study-wood-processing-equipment)
- Show submenu for Company Company
- [Our Story](https://tryleverage.ai/our-story)
- [Podcast](https://tryleverage.ai/podcast)
- [Blog](https://tryleverage.ai/blog)
- [Careers](https://tryleverage.ai/careers)
- [Partners](https://tryleverage.ai/partners)
- [Contact Us](https://tryleverage.ai/contact)
Open main navigation
Close main navigation
- Show submenu for Platform Platform
- Platform
- [CONNECT: Integrations](https://tryleverage.ai/integrations)
- [PARSE: Document Parsing](https://tryleverage.ai/document-parsing)
- [MEASURE: Supplier Performance](https://tryleverage.ai/supplier-performance)
- [PAY: Trade Finance](https://tryleverage.ai/payments)
- [ENGAGE: PO Automation](https://tryleverage.ai/purchase-order-automation)
- [TRACK: Shipments](https://tryleverage.ai/shipment-tracking)
- [COPILOT: AI Agents](https://tryleverage.ai/artificial-intelligence)
- Show submenu for Case Studies Case Studies
- Case Studies
- [Manufacturing](https://tryleverage.ai/case-study-manufacturing)
- [Distribution](https://tryleverage.ai/case-study-distribution)
- [Pharma & Biotechnology](https://tryleverage.ai/case-study-pharma-biotechnology)
- [Food Production](https://tryleverage.ai/case-study-food-production)
- [Furniture](https://tryleverage.ai/case-study-furniture)
- [Supplements](https://tryleverage.ai/case-study-supplements-manufacturing)
- [Packaging](https://tryleverage.ai/case-study-packaging-manufacturing)
- [Automotive Parts Distributor](https://tryleverage.ai/case-study-auto-parts-distributor)
- [Commercial Equipment](https://tryleverage.ai/case-study-commercial-equipment)
- [Wood Processing Equipment](https://tryleverage.ai/case-study-wood-processing-equipment)
- Show submenu for Company Company
- Company
- [Our Story](https://tryleverage.ai/our-story)
- [Podcast](https://tryleverage.ai/podcast)
- [Blog](https://tryleverage.ai/blog)
- [Careers](https://tryleverage.ai/careers)
- [Partners](https://tryleverage.ai/partners)
- [Contact Us](https://tryleverage.ai/contact)
- [Login](https://app.lvrg.ai/signin)
[Request Demo](https://tryleverage.ai/request-a-demo)
[Login](https://app.lvrg.ai/signin)
[Request Demo](https://tryleverage.ai/request-a-demo)
# What Counts as a PO Exception? Types, Tolerances, and Resolution Owners
By [Mary Chauvin](https://tryleverage.ai/blog/author/mary-chauvin) · Oct 23, 2026, 6:47:15 AM
🎧 Listen to this article (16 min)
Your browser does not support the audio element.
Most procurement teams can tell you how many purchase orders they issued last month. Far fewer can tell you how many of those orders changed after they were sent, which ones changed without anyone noticing, and how long it took to close the gap.
That second set of numbers is where the cost lives. A purchase order is a forecast, not a fact. The supplier confirms a different ship date, the price moves because a material surcharge kicked in, the quantity comes up short because a line was allocated to a larger customer. Each of those is a PO exception, and each one quietly invalidates the plan your MRP run produced.
According to Gartner, 50% of purchase order lines undergo changes after issuance, making real-time supplier visibility a procurement priority. Half your open book is moving. The question is whether you find out when it moves or when the dock is empty.
This guide defines what actually counts as a PO exception, breaks down the types worth tracking, covers how to set tolerances so your team is not buried in false alarms, and maps who should own resolution for each category.
## What a PO exception actually is
A PO exception is any difference between what your purchase order says and what the supplier has committed to or delivered. That is the whole definition. It sounds obvious, but the definition matters because it sets the detection boundary.
Three things follow from it.
First, an exception requires a supplier commitment to compare against. If a supplier never acknowledged the PO, you do not have a price variance or a date variance. You have a missing acknowledgement, which is its own exception type and arguably the most important one, because it means you are planning against a number nobody on the other side has agreed to.
Second, exceptions are time-sensitive in a way most procurement metrics are not. A price variance caught at PO acknowledgement is a negotiation. The same variance caught at invoice match is a three-way-match failure that ties up AP, procurement, and the supplier for a week. The exception did not change. The cost of handling it multiplied.
Third, exceptions are not errors. This is where a lot of teams get the framing wrong and build a workflow that treats every variance as a supplier performance problem. Most exceptions are legitimate. Lead times move, materials get allocated, freight gets rebooked. The goal is not zero exceptions. The goal is zero *unknown* exceptions.
## The seven PO exception types that matter
Teams that track exceptions well usually land on a taxonomy close to this one. The categories matter because each has a different owner, a different urgency, and a different resolution path.
### 1. Unacknowledged PO
The supplier has not confirmed receipt or terms within your acknowledgement window. This is the foundational exception. Every other comparison depends on having a confirmed baseline, and without one you are tracking an assumption.
Most mid-market teams set the window at 48 or 72 hours for standard orders and 24 hours for expedites. The trap is treating a silent supplier as an implicit yes. Silence is the single most common precursor to a late delivery.
### 2. Promise date variance
The supplier confirms a ship or delivery date that differs from the date on the PO. This is the highest-volume exception type at most manufacturers and the one with the most direct downstream impact, because it is the input your production schedule actually consumes.
Track it in both directions. A date that pulls in is also a variance, and it can create receiving and cash-flow problems just as a slip creates line-down risk.
### 3. Price variance
Confirmed unit price does not match the PO price. Causes split roughly into contract issues (the PO was cut against a stale price list), surcharges (material, energy, freight), and genuine quoting errors.
Price variances are the most likely to be caught late, because many teams only compare price at invoice. Catching it at acknowledgement moves the conversation from dispute to negotiation.
### 4. Quantity variance
The supplier confirms or ships a quantity different from what was ordered. Short-ships and partial allocations are the common cases. Over-shipments matter too, especially where minimum order quantities or pack rounding silently inflate what you receive and pay for.
### 5. Partial or split shipment
The supplier splits one PO line into multiple deliveries. Technically a quantity and date variance combined, but it deserves its own category because it breaks receiving logic and because a split that is tracked as a single late line produces misleading OTIF data.
### 6. Substitution or specification change
The supplier confirms a different part number, grade, revision, or country of origin. Lower volume than the others and much higher risk, because these frequently require engineering or quality sign-off before acceptance and can carry compliance implications.
### 7. Cancellation or non-supply
The supplier declines the order outright or cancels an acknowledged line. Rare, but it needs a hard escalation path because the resolution is sourcing, not expediting.
## Setting tolerances so your team is not buried in noise
The fastest way to kill an exception program is to flag everything. If a buyer opens the queue and sees two hundred items, most of them one-day date shifts on non-critical C parts, they will stop opening the queue.
Tolerances are what separate a signal from a log. Set them along three axes.
**Magnitude.** How far off does it have to be before anyone cares? A reasonable starting point for most mid-market manufacturers is plus or minus two days on promise date, 2% on price, and 5% on quantity. These are starting points, not standards. Calibrate them against your own data after a quarter.
**Material criticality.** Tolerances should tighten as criticality rises. A two-day slip on packaging film is noise. A two-day slip on a single-sourced casting that feeds your constraint work center is a production meeting. Most teams use ABC classification or a simple critical-part flag to drive this.
**Supplier reliability.** A supplier with 98% OTIF over twelve months has earned a wider tolerance band than one running at 71%. Tying tolerance to measured performance also gives you something concrete to put in front of the supplier during a business review. If you are not yet measuring this cleanly, our breakdown of [supplier OTIF tracking when ERP data is incomplete](https://tryleverage.ai/blog/pf/supplier-otif-tracking-erp-incomplete-data-1) covers how to build the baseline.
One rule that saves a lot of pain: never suppress an unacknowledged PO with a tolerance. Magnitude tolerances apply to variances. A missing acknowledgement has no magnitude. It is binary and it always surfaces.
## Who owns resolution
Exception programs fail more often on ownership than on detection. A flagged exception with no named owner becomes a queue item that ages.
A workable default split:
- **Buyer or planner:** date variances, quantity variances, partial shipments, unacknowledged POs. These are the daily volume and they resolve through supplier contact.
- **Category or sourcing manager:** price variances above tolerance, repeated variances from the same supplier, cancellations. These need commercial authority.
- **Engineering or quality:** substitutions and specification changes. Procurement routes, but does not approve.
- **Finance or AP:** variances that survive to invoice. Ideally a small number, because the rest were caught upstream.
Pair ownership with a resolution clock. Unacknowledged POs and critical-part date slips want a same-day target. Price variances can run two to three days. Substitutions take as long as the engineering review takes, but the routing should still happen same-day.
A Deloitte supply chain study found that 70% of supply chain disruptions originate before materials leave the supplier's facility. That is the case for pushing resolution upstream. By the time the exception is visible in receiving, the options have narrowed to expedite freight or miss the schedule.
## What exception data tells you that OTIF does not
Once you have clean exception records, you get a diagnostic layer that delivery metrics alone do not provide. OTIF tells you a supplier missed. Exception data tells you how they missed, when they told you, and whether they told you at all.
Three patterns are worth watching for, because each points at a different fix.
**High variance, early notice.** The supplier confirms a different date or quantity most of the time, but they confirm it promptly and the confirmed date holds. This is not a performance problem. It is a planning-parameter problem. Your lead times are wrong, and the supplier has been absorbing the difference by telling you. The fix is updating the item master, not a supplier conversation.
**Low variance, late notice.** Confirmations are accurate when they arrive, but they arrive days after the acknowledgement window or only after a buyer chases them. The supplier is reliable and their process is not. This is the easiest category to fix and usually resolves with an agreed acknowledgement SLA.
**Confirmed date drift.** The supplier acknowledges on time, then revises the confirmed date one or more times before shipping. A single acknowledgement looks healthy here, which is why this pattern hides from most reporting. Tracking revisions per line rather than just first-confirmation accuracy is what exposes it.
That third pattern is the strongest argument for keeping a full history on every PO line rather than overwriting the promise date each time it changes. The sequence of commitments is the data. A single current value throws away the thing you most want to measure.
Bring these patterns to quarterly business reviews instead of a single OTIF percentage. A supplier can dispute a delivery score. It is much harder to dispute a list of their own confirmations and revision timestamps.
## Why your ERP alone does not surface most of this
This is the part that surprises people. Teams assume that because the PO lives in the ERP, exception detection should be an ERP function. In practice it usually is not, for a structural reason.
ERP systems are systems of record. They store what was ordered and, eventually, what was received. The supplier's commitment, the thing you need to compare against, almost never arrives in a structured format. It arrives as an email reply, a PDF order confirmation, a spreadsheet attachment, or a phone call that someone may or may not write down.
Whether your procurement team runs on SAP, Oracle NetSuite, Microsoft Dynamics 365, Epicor, or Infor, the PO record is only as current as the last manual update someone typed into it. The ERP will happily show you a promise date that a supplier revised three weeks ago in an email thread nobody re-keyed.
So the gap is not a reporting gap. It is a capture gap. The data exists, in the supplier's reply, and it never becomes structured. That is also why bolt-on modules inside the ERP tend to underdeliver here, a tradeoff we go through in more detail in our comparison of [ERP-agnostic PO automation versus built-in ERP modules](https://tryleverage.ai/blog/pf/erp-agnostic-po-automation-vs-built-in-erp-modules).
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 [Dynamics 365 procurement automation walkthrough](https://tryleverage.ai/blog/pf/dynamics-365-procurement-automation-po-visibility) covers that setup specifically.
## Building the workflow
Four steps, in order. The order matters because each one depends on the previous.
**Step one: close the acknowledgement loop.** Before you can detect variance you need a confirmed baseline on every PO. That means an acknowledgement request on issue, a follow-up on a timer, and an escalation when the window expires. Teams that skip straight to variance detection end up measuring a fraction of their book.
**Step two: capture confirmations as structured data.** Supplier replies need to become fields, not attachments. Confirmed date, confirmed price, confirmed quantity, confirmed part. This is the step most teams underestimate, and it is the one that determines whether everything downstream works.
**Step three: compare and classify.** Run the comparison against the PO, apply tolerances, assign the exception type and the owner. Automatically, on arrival. An exception found during a weekly review is a status update, not an intervention.
**Step four: measure the program, not just the exceptions.** Track exception rate by supplier, by type, and by part class. Track time to resolution. Track what percentage are caught at acknowledgement versus at receipt versus at invoice, because moving that distribution upstream is the actual objective.
Aberdeen Group research shows that automated PO tracking reduces operational costs by up to 30% for mid-market manufacturers. That number comes almost entirely from steps one through three, the elimination of manual follow-up and re-keying, rather than from better reporting at the end.
If you want a working checklist to audit your current state, start with our [PO exception management checklist](https://tryleverage.ai/blog/pf/po-exception-management-checklist). To size the business case before you build anything, the [PO tracking automation ROI model](https://tryleverage.ai/blog/pf/po-tracking-automation-roi-model) walks through the cost-per-PO math. You can also see how the capture and comparison steps work in practice on our [product overview](https://tryleverage.ai/product).
## Frequently Asked Questions
### What is a PO exception?
A PO exception is any difference between what a purchase order specifies and what the supplier has confirmed or delivered. Common types include unacknowledged purchase orders, promise date variances, price variances, quantity variances, partial shipments, part substitutions, and cancellations.
### What is the difference between a PO exception and a PO change order?
A change order is a formal, mutually agreed revision to the purchase order, usually initiated by the buyer and documented as a new PO revision. An exception is an unplanned difference, usually surfaced by the supplier, that may or may not result in a change order. Exceptions are the detection event. Change orders are one possible resolution.
### What is a reasonable PO exception rate?
There is no universal benchmark, and the rate matters less than the detection point. Gartner's finding that roughly half of PO lines change after issuance suggests that a very low reported exception rate usually indicates a detection problem rather than a stable supply base. A more useful measure is what share of exceptions you catch at acknowledgement rather than at receipt or invoice.
### Which PO exception should we tackle first?
Unacknowledged purchase orders. Every other exception type requires a confirmed supplier commitment to compare against, so acknowledgement coverage sets the ceiling on everything else you can detect.
### Can our ERP handle PO exception management on its own?
Partially. ERP systems record what was ordered and received, but supplier confirmations usually arrive as unstructured email or PDF, so the confirmed values never enter the ERP unless someone re-keys them. The limitation is data capture rather than reporting, which is why exception detection typically requires a layer that reads supplier replies and writes structured values back into SAP, NetSuite, Dynamics 365, Epicor, or Infor.
### How do we set exception tolerances?
Start with plus or minus two days on promise date, 2% on price, and 5% on quantity, then tighten for critical or single-sourced parts and for suppliers with weak delivery performance. Review the thresholds after a quarter against your own exception volume. Never apply a magnitude tolerance to unacknowledged purchase orders, since those are binary and should always surface.
About Mary Chauvin
Mary is an Account Executive at Leverage AI, where she helps wholesale distributors and manufacturers automate purchase order follow-up and cut down on manual work. She works closely with procurement leaders to show how AI-driven PO tracking protects revenue and frees up teams to focus on higher-value work.
[LinkedIn](https://www.linkedin.com/in/mary-chauvin-70741615b/)
## Related Articles
### See Leverage in Action
Stop chasing suppliers by email. Get real-time PO tracking and delivery visibility for your entire supply chain.
[Request a Demo](https://tryleverage.ai/request-a-demo)
#### Works with your ERP
Epicor, Infor, SAP, NetSuite, Microsoft Dynamics, and more. No EDI or supplier portal required.
[](https://tryleverage.ai)
Leverage AI delivers an end-to-end supply chain visibility platform powered by artificial intelligence that enables teams to ensure on-time delivery, in-full completion, within-budget costs, and high-quality standards.
Copyright © 2026 LVRG, Inc.
- Platform
- [CONNECT: Integrations](https://tryleverage.ai/integrations)
- [PARSE: Document Parsing](https://tryleverage.ai/document-parsing)
- [MEASURE: Supplier Performance](https://tryleverage.ai/supplier-performance)
- [PAY: Trade Finance](https://tryleverage.ai/payments)
- [ENGAGE: PO Automation](https://tryleverage.ai/purchase-order-automation)
- [TRACK: Shipments](https://tryleverage.ai/shipment-tracking)
- [COPILOT: AI Agents](https://tryleverage.ai/artificial-intelligence)
- Case Studies
- [Manufacturing](https://tryleverage.ai/case-study-manufacturing)
- [Distribution](https://tryleverage.ai/case-study-distribution)
- [Pharma & Biotechnology](https://tryleverage.ai/case-study-pharma-biotechnology)
- [Food Production](https://tryleverage.ai/case-study-food-production)
- [Furniture](https://tryleverage.ai/case-study-furniture)
- [Supplements](https://tryleverage.ai/case-study-supplements-manufacturing)
- [Packaging](https://tryleverage.ai/case-study-packaging-manufacturing)
- [Automative Parts Distributor](https://tryleverage.ai/case-study-auto-parts-distributor)
- [Commercial Equipment](https://tryleverage.ai/case-study-commercial-equipment)
- [Wood Processing Equipment](https://tryleverage.ai/case-study-wood-processing-equipment)
- Resources
- [Security & Trust](https://tryleverage.ai/security)
- [Terms of Service](https://tryleverage.ai/terms)
- [Privacy Policy](https://tryleverage.ai/privacy)
- [Vulnerability Disclosure Policy](https://tryleverage.ai/vdp)
- Company
- [Our Story](https://tryleverage.ai/our-story)
- [Podcast](https://tryleverage.ai/podcast)
- [Blog](https://tryleverage.ai/blog)
- [Careers](https://tryleverage.ai/careers)
- [Partners](https://tryleverage.ai/partners)
- [Contact Us](https://tryleverage.ai/contact)
-
-
-
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Mary Chauvin",
"url" : "https://tryleverage.ai/blog/author/mary-chauvin"
},
"datePublished" : "2026-10-23T10:47:15.000Z",
"headline" : "What Counts as a PO Exception? Types, Tolerances, and Resolution Owners",
"image" : [ "https://tryleverage.ai/hubfs/blog-covers/cover-po-exception-types-tolerances-resolution-owners.png" ],
"mainEntityOfPage" : {
"@id" : "https://tryleverage.ai/blog/pf/po-exception-types-tolerances-resolution-owners",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://tryleverage.ai/hubfs/Logo%20+%20Name%20Dark.png"
},
"name" : "Leverage AI"
}
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "Organization",
"contactPoint" : {
"@type" : "ContactPoint",
"contactType" : "sales",
"telephone" : "+1-929-470-3086"
},
"description" : "AI-powered purchase order automation and supplier performance platform for manufacturers and distributors.",
"logo" : "https://tryleverage.ai/hubfs/leverage-logo-dark.png",
"name" : "Leverage AI",
"url" : "https://tryleverage.ai"
}
```