If you run accounts payable in a company of 50 to 500 people, on a purchase order cycle, and your exception queue keeps growing even though detection already works, this page is for you. It is not an interview answer, and it is not about chasing customer deductions on the receivables side.
An invoice discrepancy is a difference between a supplier invoice and the records that authorize paying it: the purchase order, the goods receipt, the contract, or a previously posted invoice. Detecting one is the cheap half of the job. The expensive half is what the flag triggers, because a flag only becomes a control when it carries four things: a numeric tolerance that decides whether it fires at all, a named outcome, a person accountable for reaching that outcome, and a date by which it must be closed. Strip any one of those and you have not replaced a control, you have built an alert queue that someone will eventually clear in bulk.
Key takeaways
- A discrepancy is usually an error, not fraud, and treating the two the same way produces a control that is both too slow for errors and too weak for fraud.
- SAP checks invoice variances against eight configurable tolerance keys, and one of them (BD) posts small differences to an expense account automatically, so part of your discrepancies is absorbed before anyone sees it.
- When an upper tolerance limit is exceeded the invoice is blocked for payment, and SAP's own documentation states it must then be released in a separate step, which makes release a control point in its own right.
- Paying the clean lines while holding only the disputed line closes far more exceptions than holding the whole invoice, because most discrepancies affect one line out of many.
- The honest health metric is the ageing of open exceptions, not the auto-match rate, because an auto-match rate stays flat while the unresolved queue quietly gets older.
A discrepancy is not fraud, and the difference decides your control
The two get bundled together constantly, and the bundling is expensive. Wise splits invoice discrepancies into intentional and unintentional, which is the right cut: the unintentional ones are keying errors, stale price files, partial deliveries, freight added after the order, and duplicate submissions. The intentional ones are a different problem with a different owner, a different escalation path and a different legal exposure.
The practical consequence is that the same detection logic cannot serve both. Fraud controls are designed to be slow, suspicious and rare: you want a second pair of eyes on a changed bank account, and you accept the friction because the loss is catastrophic and the volume is tiny. Error controls are the reverse: high volume, low unit loss, and any friction you add is paid on thousands of invoices a month. Run your error queue at fraud-grade suspicion and you will not clear it. Run your fraud checks at error-grade tolerance and you will pay the fake invoice.
This page covers the error side. Deliberate manipulation, supplier impersonation and bank detail changes are a separate control family, and we treat them in invoice fraud detection with AI.
Your ERP already decides which discrepancies you never see
Before you add an agent, find out what your system is currently configured to ignore. This is not a settings detail, it is the boundary of your visibility, and it is documented by the vendor.
SAP's S/4HANA documentation (version 2025 FPS01, February 2026) states it plainly: "When processing an invoice, the system checks each item for variances between the invoice and the purchase order or goods receipt. The different types of variances are defined in tolerance keys." There are eight of them, set per company code: AN and AP for item amounts, BD for small differences, DQ and DW for quantity variances, PP for price variance, ST for date variance, and VP for moving average price variance. Only DQ and PP accept both absolute and percentage limits in both directions. The rest accept an absolute upper limit and nothing else.
Two of those keys deserve your attention today.
BD absorbs discrepancies silently. SAP describes it as follows: the system checks the invoice balance against the absolute upper limit, and if the limit is not exceeded, "the system automatically creates a posting line called Expense/Income from Small Differences, making the balance zero and allowing the system to post the document." Read that again with a controller's eye. Below your BD threshold, discrepancies are not flagged, not reviewed and not recovered: they are posted to a P and L line and the document goes through. Whatever that threshold is, multiplied by your invoice volume, is a number nobody in your finance team can currently quote.
DW blocks by default when you do nothing. SAP: "If you have not maintained tolerance key DW for your company code, the system blocks an invoice for which no goods receipt has been posted yet." Plenty of exception backlogs are not a matching problem at all, they are an unconfigured key plus a receiving process that lags invoicing.
So the first question to ask is not "can an agent detect discrepancies", it is "what are the eight numbers currently set in my system, who set them, and when". If nobody can answer, your detection coverage is unknown, and any claim about how many discrepancies you catch is unverifiable.
The four decisions every flag has to carry
A flag with no decision attached is a notification. A flag becomes a control when it arrives with all four of the following already determined, ideally by rule rather than by whoever opens the queue that morning.
| Decision | The question it answers | What goes wrong when it is missing |
|---|---|---|
| Tolerance | Below what absolute and percentage variance does this not fire at all? | Either everything fires and the queue is noise, or the threshold is invisible and losses accumulate below it |
| Disposition | Which of the finite ways of closing this applies: credit note, price correction, partial release, accrual, write-off? | The exception stays open because nobody has decided what "resolved" means for this type |
| Owner | Which named role acts next: buyer, receiver, AP, the supplier? | The item bounces between AP and procurement and ages without anyone being late |
| Deadline | By which date must it be closed, given the payment terms and the close calendar? | Discrepancies are discovered again at month end, as a reconciliation problem instead of a purchasing one |
Note what is not on that list: severity scores, confidence percentages, risk ratings. They are pleasant to look at and they decide nothing. A ranked queue with no disposition rules is still a queue.
Note also that tolerance is a business decision, not a technical one. A 2 percent variance on a commodity with volatile pricing is normal. The same 2 percent on a contracted service line is a breach of the rate card you negotiated, and it should fire every time. This is the point where a reconciliation layer that works line by line earns its place, because a single tolerance applied to a whole invoice is always wrong somewhere.
How a discrepancy actually closes
There is a finite list. Writing it down is most of the work, because it converts an open-ended investigation into a routing decision.
| Disposition | When it applies | Who acts |
|---|---|---|
| Credit note requested | The supplier billed more than was ordered, delivered or contracted, and agrees | AP raises, supplier issues, AP matches the credit to the original invoice |
| Price or order corrected | The invoice is right and the reference record is stale: an approved increase never loaded, a change order never posted | Buyer updates the order or the price file, then the match runs again |
| Partial release | Only some lines are in dispute, which is the common case on multi-line invoices | AP pays the clean lines on time and holds only the disputed line |
| Accrued and carried | The goods arrived, the receipt is missing, and the period is closing | Accounting accrues, receiving posts the receipt, the accrual reverses |
| Written off within policy | The variance is real, small, and costs more to chase than to absorb | A named approver, above a stated threshold, with the write-off recorded |
Partial release is the one most teams skip, and it is the highest-yield change available. A practitioner in r/Accounting put it in one line when asked how they handle exceptions that fail three-way matching: "we stopped holding the whole invoice when only one line was unreceipted. Pay the clean lines, hold the disputed." Holding a full invoice because of one line converts a line-level problem into a supplier relationship problem, an early payment discount lost, and a call you have to take.
The last row matters too, and it is the row nobody writes down. If write-off is not a documented disposition with a threshold and an approver, it still happens: it happens invisibly, through the BD tolerance key, with no approver at all.
Who releases a blocked invoice, and who must not
SAP is unambiguous about the mechanics: when an upper limit is exceeded "the invoice is blocked for payment when you post it. You must then release the invoice in a separate step." That separate step is a control, and it is the one most frequently collapsed.
Collapsing it looks like this, and it is documented publicly by the people doing it. A Workday user describes the plan on r/workday: "the AP team to compile a list of invoices, post-analysis and approval, which can then be processed for match override in bulk." Bulk match override is what a flag degrades into when the four decisions above are missing. The detection still runs. The queue still fills. And then it is emptied in one action, by the same team that is measured on how fast invoices clear.
The rule to hold is simple: whoever is accountable for the throughput of the payment cycle should not be the only person able to dismiss the reason an invoice was stopped. In a small team you cannot separate those duties by headcount, so you separate them by rule instead: a release above a stated amount requires the budget owner, releases are logged with a reason code, and the log is reviewable. Reason codes are also what turn a queue into data. Without them you can report how many exceptions you had, but never the root cause, and therefore never fix the source. No amount of automation substitutes for that one field. Broader patterns for designing these checks sit in the internal controls library.
The metric that tells you the control is working
Most AP dashboards lead with the automatic match rate. It is the wrong headline, for a structural reason: it is a ratio over the population that was matchable in the first place. Push it from 85 to 95 percent and you have removed a slice of the cheapest work in the process. The exceptions were always the expensive part. A poster on r/CFO framed it the right way round: "Before automating AP, I'd measure how many invoices are exceptions", listing no PO number, PO amount not matching the invoice, and missing goods receipt as the drivers.
Two measures are worth putting on the dashboard instead.
The same thread on r/Netsuite, from a team whose invoice volume was rising while headcount was not, names where the time should go: "AP should spend its time on mismatches, unusual vendors, missing receipts, and approval exceptions." That is a description of a queue, and a queue needs a clock on it rather than a percentage next to it.
The ageing profile of open exceptions. Not the count, the age distribution: how many are over 15 days, over 30, over 60. It degrades the moment the team falls behind, where an auto-match rate stays reassuringly flat. It also maps directly onto cash, because an exception older than your payment terms is a late payment you have already caused.
First-time-error-free disbursements, which APQC tracks as a standard accounts payable benchmark. It measures the source rather than the cleanup.
Cost per invoice deserves one warning, because it is quoted loosely. KlearStack, ranked on this exact query, states that AI-powered invoice processing cuts cost per invoice "by over 80%, from ~$15 to as low as $2.78". APQC's Open Standards Benchmarking puts the median total cost to process accounts payable at $6.00 per invoice. A $15 starting point is not the typical organisation, it is the expensive end of the distribution. If you are anywhere near the median, the saving on offer is a fraction of the one advertised, and the real money is in the exception queue rather than in the per-invoice unit cost.
If you want to see what this looks like on your own volumes rather than on a benchmark, that is a 30 minute conversation with your invoice data.
What to give an agent, and what to keep for a person
An AI agent is a piece of software that carries out a defined finance job end to end, on your own data, and shows its work at each step. Phacet builds them for finance work specifically, on top of a table and an audit trail rather than a chat box. On discrepancies, the split is clean.
Give the agent the parts that are mechanical and that no one does consistently at volume: reading every line of every invoice rather than a sample, comparing each line against the order, the receipt and the contracted rate, applying the tolerance you set instead of the one the ERP shipped with, grouping repeat offences by supplier so the pattern surfaces, and routing each exception to its disposition and its owner with the clock already running. The three-way matching agent does exactly this comparison, and every step it takes is written to an audit trail a reviewer can open.
Keep for a person the parts that are judgment: setting the tolerance in the first place, deciding whether an unexplained increase is renegotiated or refused, approving a write-off, and deciding that a supplier who generates the same discrepancy every month is a commercial problem rather than an accounting one. That is not a limitation of the technology, it is what the control is for.
The gain is visible in the mix of the day rather than in a headline percentage. At Astotel, an 18 hotel group, price control used to run on sampling, and a Phacet agent checking every line surfaced around 400 euros of billing errors per month on a single supplier, close to 5,000 euros a year. "I spot errors I would never have seen on my own", says Valerie, Purchasing Director. The point is not the sum, it is that the sum was previously invisible: it sat below the sampling rate, exactly where a tolerance key would have posted it to small differences without anyone deciding to let it go.
Frequently asked questions
What happens if a PO does not match an invoice?
The invoice is held rather than rejected. If the variance exceeds a configured tolerance limit, the ERP blocks the item for payment at posting and it must be released in a separate step. Below that limit it posts straight through, sometimes into a small differences account. What happens next depends on which disposition applies, not on the size of the gap alone.
What if PO quantity is mismatched with vendor invoice?
Quantity variances are checked separately from price variances, against their own tolerance, and the comparison uses the goods receipt rather than the order when one has been posted. A quantity gap usually means a partial delivery, an over-shipment, or a receipt that was never entered. The fix is a receipt correction or a credit note, not a price adjustment.
Should a purchase order match an invoice?
Not to the cent, no. Every AP system is configured with a tolerance band because insisting on a perfect match stops legitimate invoices over rounding and freight. The useful question is what band you have set, per variance type, and whether anyone chose those numbers deliberately rather than inheriting a default.
Can you give me an example of an invoice discrepancy?
A supplier delivers 48 of the 50 units ordered, invoices for 50 at the ordered price, and adds a fuel surcharge that is not in the contract. That single invoice carries three discrepancies: a quantity variance against the goods receipt, no price variance at all, and an unauthorized charge against the contract. They close three different ways.
What does discrepancy mean in accounting?
A discrepancy is a difference between two records that should agree, identified before the accounts are considered reliable. In accounts payable it means invoice against order, receipt or contract. In the general ledger it means a balance against the evidence that supports it. Same idea, different reference document.
