Matching invoices and flagging exceptions — with dunning
Two workflows that share the same substrate: one matches every invoice against its PO and receipt, auto-accepting clean variance and drafting disputes with cited line items. The other chases past-due invoices with tier-appropriate follow-ups that respect standing disputes and payments already in flight. Both are audit surfaces. Both require the same discipline around the fraud hard-stop.
Invoice exception triage uses AI to match every invoice against its PO, receipt, and tolerance rules — auto-approving clean matches, drafting disputes with cited line items, and holding anything that looks like fraud for mandatory human verification.
Paired with dunning, the same substrate chases past-due invoices with tier-appropriate follow-ups that respect open disputes and payment-in-transit signals — and log every suppression for audit.
Invoice exception triage
Workflow map
Data in
Start
- Invoice — header, line items, amounts, dates, bank details
- PO and goods-receipt note (GRN)
- Vendor master (identity, historic bank, prior mismatch rate)
- Payment terms and approval matrix
- Tolerance rules per vendor
- Fraud signals — bank change, new vendor, unusual amount
Mid-stage
- Exception classification (price / quantity / date / missing PO / bank)
- Clerk resolution taken (accept / dispute / adjust / hold)
- Vendor response and updated PO or GRN
- Audit annotation and approver identity
Transforms
- Ingest invoice
- 3-way match (invoice ↔ PO ↔ GRN)
- Classify any exception
- Check fraud signals
- Propose resolution (accept / dispute / hold / request updated PO)
- Hand to clerk with reasoning
Integrations
In
- ERP (SAP / Oracle / NetSuite)
- AP automation (Coupa / Bill / Basware)
- Banking feed
- Vendor master system
- Fraud-signal service
Out
- ERP exception queue
- Dispute / ticket system
- AP approval workflow
- Audit log (per invoice, per decision)
- Banking (payment-release call, post-approval)
Outputs
- Pre-resolved exceptions (within tolerance)
- Disputed invoices with cited reason
- Fraud-flag holds — mandatory human-verify gate
- Audit log entry per invoice
- Weekly audit sample of auto-resolved set
Posture decision
Assist → Automate. Start with assist for the first six weeks. Move tolerances and routine exceptions to automate only after the audit is clean for eight weeks.
Why this matters. The blast radius of a wrong invoice decision is a payment you can't get back. Every auto-accept is a real euro leaving the company; every auto-dispute is a supplier relationship you just strained. The assist posture forces the audit that makes automate safe.
The fraud hard-stop is not negotiable at any posture. Bank-detail changes, first-time vendors, unusual amounts for a vendor's history — these never auto-resolve, regardless of how confident the model is. They hold, and a human verifies by calling a known number, not the reply-to on the email.
What changes when you move to Automate
- Automate becomes right when
- Eight consecutive weeks of clean audit (no unexpected pattern in the auto-resolved set), a fraud hard-stop verified through at least one red-team test, and tolerance thresholds owned by finance (not the AI team), documented per vendor.
- Agentic becomes right
- Later. An agent that proposes new vendor tolerances or clears its own exceptions is a material governance problem — one you solve after the substrate is trusted, not before.
- Co-designed becomes right
- When the workflow becomes a new Finance function — continuous close narrative, live APR forecasting. That's the Transform stage.
Baseline
Measure these for three weeks before any auto-resolution
The baseline covers the four things finance already tracks — don't invent new metrics until these exist as numbers you trust.
- Exception rate — % of invoices that don't auto-match, split by exception type
- Cycle time — invoice receipt → resolution, in business days
- Cost per invoice processed — full-loaded, including the resolution layer
- Same-day resolution rate — % of exceptions cleared within the day they arrived
Metrics
| Metric | Baseline | Target | Fail if | How measured |
|---|---|---|---|---|
| Exception rate | [% from baseline] | −30% to −50% | Improvement < 20% | AP system, weekly |
| Auto-resolve rate | 0% | 40%–60% | < 30% | AP system, weekly |
| Cycle time | [days] | −50% to −70% | Improvement < 35% | AP system, weekly |
| Cost per invoice | [€] | −40% to −60% | Improvement < 25% | Full-loaded, monthly |
| Fraud auto-resolve | 0 incidents | 0 | Any 1 | Weekly audit + incident log |
| Vendor complaint rate | [baseline] | Flat or lower | Any rise | Vendor relations inbox |
Traps
-
Auto-resolving bank-detail changes
The single most expensive AI-adjacent AP failure in the last decade. A vendor email says "please update our bank account," the workflow treats the update as part of the invoice match, and the payment goes to a fraudster. This is not a technology problem — it's a policy failure that technology makes faster.
Prescription: Bank-detail changes are a hard-stop exception. Never auto-resolve. Always human-verify. Always verify out-of-band — a phone call to a known number on file, not the reply-to in the email requesting the change. This is the one rule that must survive any change to the workflow.
-
A tolerance that treats all vendors equally
A global 0.5% tolerance either accepts variances finance would never accept, or blocks vendors whose documented history justifies flexibility. Either way, the numbers stop matching what the AP owner actually wants.
Prescription: Set tolerance per vendor based on 12-month historic variance. A vendor with a clean record gets 0.5% or lower. A vendor with frequent short-deliveries gets 1.5% or higher — documented, quarterly-reviewed, owned by the AP manager, not the AI team.
-
Not auditing the auto-accepted set
When the agent — assist or auto — starts treating exceptions as routine, it stops looking for the ones that aren't. Small fraud looks like small variance to a model trained on clean data.
Prescription: Audit the auto-resolved set weekly for at least 90 days. Fifty invoices per week, sampled across vendors. Look for patterns you didn't expect — a new vendor bank pattern, a rounding error that repeats, a vendor whose mismatch rate jumped. That's where the surprises live.
-
Per-vendor pattern blindness
A vendor whose invoices mismatch 40% of the time has a data-quality problem at their source, not an exception rate to be triaged. Automating the triage makes the symptom go away without fixing the cause.
Prescription: Weekly "top exception by vendor" report. Fix the three worst vendors at source — updated PO templates, better GRN discipline, cleaner invoices. The automation is a safety net, not a substitute for upstream quality.
Go/no-go
Scale to Automate
- 8 consecutive weeks of clean audit
- Fraud hard-stop verified in a red-team test
- Tolerances documented, owned by finance
- Vendor complaints flat
Iterate
- Audit finds 1+ pattern not covered by rules
- Auto-resolve rate drifting below 30%
- Any single vendor pattern unowned
Stop
- Any fraud incident
- External auditor flags the workflow
- Vendor complaints rise materially
- Bank-detail change auto-resolved even once
Worked example
Two invoices, two outcomes
- Invoice A
- €40,000.00, net-30, from vendor ABC. PO: €40,000.00. GRN: €39,850.00 (three units short-delivered). Variance: €150.00 = 0.375%. Vendor's 12-month variance: 0.4% average, 0.8% max. Tolerance: 0.5%.
- System decides
- Within tolerance. Auto-accept with variance note. Audit log entry references the GRN and the vendor tolerance. Payment released on net-30. No human touch.
- Invoice B
- €18,000.00, net-30, from vendor XYZ. Vendor master on file: bank ending 4471. Invoice PDF: same amounts, same PO, but bank ending 8238. Vendor master was updated two days ago from an email requesting the change.
- System decides
- Bank-detail mismatch — hard-stop hold. No auto-resolve, regardless of confidence. Clerk receives the invoice with a note: "Bank-detail change 2 days ago, verify out-of-band." Clerk calls the number on file, reaches the vendor's controller, learns the email was a spoof. Payment held. Fraud prevented.
Dunning and invoice follow-ups
Workflow map
Data in
Start
- AR aging report (per invoice, per customer)
- Account context — tier, relationship, payment history, prior DPD
- Open disputes (must suppress)
- Open support tickets (must suppress)
- Payment-in-transit signals from bank feed
- Promise-to-pay windows
- Dunning tier rules per segment
Mid-stage
- Customer response signals — open, click, reply, dispute
- Promise-to-pay updates and follow-ups
- Tier transitions and reasons
- Escalation-to-collections decisions
Transforms
- Segment by tier and relationship
- Suppress if disputed, in-transit, or in promised window
- Select dunning tier (30/45/60/90+)
- Draft message per tier + history + relationship
- Propose self-serve pay link or plan
- Log response and update tier
Integrations
In
- AR subledger
- Bank feed (for in-transit)
- Dispute ticket system
- Support ticket system
- CRM (relationship context)
- Email / SMS / portal channels
Out
- Dunning channel
- Payment-link provider
- Collections case system (escalations only)
- AR update (per message, per response)
- Suppression log — mandatory for audit
Outputs
- Dunning messages sent, per tier
- Tier transitions logged
- Collections handoffs (with context)
- Suppression entries (audit trail)
- DSO and DPD metrics
- Response-rate trend per tier and channel
Posture decision
Automate from day one — because the human gate belongs on the suppression rules and the collections escalations, not on the send action.
Why this posture differs from exceptions. Dunning without timing is dunning without value. If every message waits for human approval, the customer has already paid or already churned by the time the message goes out. The safety system is the suppression list, checked before drafting — not the send button.
What stays human: the suppression rules themselves, the exception queue of suppressed-and-escalated customers, and any dunning on the top 20 strategic accounts. Those are the decisions where a person reading the account history matters more than speed.
What can drift, and how to catch it
- Suppression accuracy
- Audit weekly. For every customer not contacted, confirm the reason is still true. If suppression accuracy drops below 98% for two consecutive weeks, pause the workflow and fix the rules.
- Response-rate drift
- A tier that used to convert stops converting. That's a signal that the message is landing in the wrong inbox or the tone is off. Re-eval the message before the DSO starts climbing.
- Complaint rate
- Any rise in "you contacted me when you shouldn't have" complaints is a stop signal, not an iterate signal. It means the suppression layer is wrong in a way that costs customer trust more than it recovers cash.
Baseline
Measure these before turning dunning on
The exception baseline covers cycle time and cost per invoice — you don't need to re-measure those. Add three:
- DSO — days sales outstanding, overall and by segment
- DPD distribution — how many customers are in 30 / 45 / 60 / 90+ buckets, per segment
- Response rate to manual dunning — per tier, per channel, over the last 90 days
Metrics
| Metric | Baseline | Target | Fail if | How measured |
|---|---|---|---|---|
| DSO (target segment) | [days] | −5 to −15 days | Improvement < 3 days | AR aging, monthly |
| DPD 30+ reduction | [%] | −15% to −30% | < 10% | AR aging, monthly |
| Response rate | [%] | +20% to +40% | < +10% | Channel analytics |
| Suppression accuracy | N/A | > 98% | < 95% | Weekly audit of suppressed customers |
| Customer complaint rate | [baseline] | Flat or lower | Any rise | CRM, CX, and account-owner inboxes |
Traps
-
Dunning without suppression
Sending "your invoice is overdue" to a customer whose dispute is open, or whose payment is already in transit, damages trust more than it recovers cash. Worse: the customer calls, the dispute is confirmed, and now the CFO believes the dunning system works but the customer doesn't.
Prescription: A mandatory suppression list, applied before the dunning message is drafted — not before it's sent. Check: open dispute, open support ticket, payment-in-transit signal, promise-to-pay window still valid, strategic-account flag. Log every suppression for audit. The log is your defence when a customer asks why they weren't contacted.
-
Tone-deaf dunning by segment
A 90-day overdue invoice on a top-20 strategic account is a relationship problem, not a collections problem. Automated tier messages make it worse — the account owner finds out from the customer, not from you.
Prescription: Segment dunning by account tier, not just by days overdue. Top-20 accounts get a human-owned sequence, with the AI drafting but not sending. Everything else can go automated up to the collections-escalation gate.
-
Suppression as a checkbox
The suppression list works when it's a hard block in software. It fails the moment it becomes a checkbox an operator can override for one "quick follow-up" — because that override is exactly where the costly customer complaint comes from.
Prescription: Suppression is a hard gate in the software, not a soft recommendation in a runbook. Overriding requires a named decision-maker and a logged reason. Anything else and the suppression becomes a suggestion within two months.
-
Compressed timelines after a dispute closes
A dispute takes a week to resolve. When it closes, the "was it 30 days" clock hasn't moved — but you now have three dunning tiers to catch up on. The customer gets three messages in a week because of an internal backlog.
Prescription: When a dispute closes, resume dunning on the original schedule — do not compress. The customer's clock doesn't restart because yours did. Document this rule; it will be tested within the first quarter.
Go/no-go
Scale
- Suppression accuracy >98% for 8 weeks
- Complaint rate flat or lower
- DSO trending down on target segment
- Strategic-account suppression verified
Iterate
- Suppression accuracy 95%–98%
- Complaints rising slightly
- Response rate drifting below +20%
Stop
- Any material inappropriate-contact complaint
- Any regulator inquiry
- Suppression accuracy below 95%
- Any strategic-account auto-dunning sent
Worked example
A dunning sequence — and where it stops
- Invoice
- €12,400.00, net-30, customer AC-203.
- Day 31
- Suppression check: no open dispute, no open support ticket, no payment-in-transit, no promise-to-pay. Customer's historic DPD: 12 days average over 24 months. System drafts tier-1 message — cooperative tone, self-serve pay link, "no action needed if payment is already in flight."
- Day 38
- No payment, no response to tier 1. Suppression check: still clean. System drafts tier-2 message — firmer tone, self-serve pay link plus two payment-plan options. Customer average DPD justifies tier 2 at this point; top-20 accounts would still be human-owned.
- Day 45
- Still unpaid. Suppression check runs before drafting tier 3: an open support ticket surfaced the previous day, marked "urgent — invoice question." Suppression fires. Tier-3 message not drafted. Collections case created with the ticket context attached. Human collections agent takes over with full context — including that the customer has an open question.
Regulatory notes
Regulatory and audit-surface note
Both workflows are audit surfaces. SOC 2, SOX, and statutory record-keeping rules in most jurisdictions apply. The AI layer must augment the audit trail, not replace it — every auto-resolve, every suppression, every dunning message must be independently reconstructable from the log, months later, by an auditor who wasn't in the room. Verify with your auditor before go-live. This is not a design constraint to solve in code; it's a control-environment requirement to solve in the workflow.
What good looks like
One dashboard, five numbers. If any is off, the workflow isn't ready for the next stage.
Exceptions + dunning at a glance
Open this and know, in 60 seconds, whether the workflow is healthy.
- Auto-resolved exceptions above 40%, with a weekly audit sample clean
- Fraud hard-stop triggered on every bank-detail change — count matches the number of changes, not fewer
- Suppression accuracy above 98% for the last four weekly audits
- DSO trending down on the target segment, complaints flat
- Auditor signed off on the audit-trail reconstructability
Frequently asked questions
Should tolerance thresholds be global or per-vendor?
Per-vendor. A global tolerance either accepts variances finance would never accept, or blocks vendors whose documented history justifies the flexibility. Set tolerance per vendor based on their prior 12-month variance history — a vendor with a clean record gets 0.5%, a vendor with frequent short-deliveries gets 1.5% or higher. Review quarterly. The threshold is a business decision, not a technical one, and it belongs to the AP owner, not the AI team.
What's the right human-in-the-loop gate for dunning?
The gate is the suppression list, not the send action. Dunning that requires human approval per message defeats its purpose — timing is the whole point. Instead: automate sending, but require human judgment on three things — the suppression rules themselves, the exception queue of suppressed-and-escalated customers, and any dunning on the top-20 strategic accounts. Response rate improves when drafting and sending are automated but suppression and strategic accounts stay human-owned.
How do we handle a customer with an open dispute?
Suppress dunning entirely while the dispute is open, and log the suppression. When the dispute closes, the dunning sequence resumes on the original timeline, not a compressed one — the customer shouldn't get three dunning messages in a week because the dispute took a week to resolve. This is the single most important suppression rule, and it should be a hard gate in the software, not a checkbox on a form.
How often should we refresh the eval set?
For exception triage: quarterly, plus whenever your vendor master changes materially, plus whenever tolerance thresholds change. For dunning: quarterly, plus whenever the aging report shows a new exception pattern — a segment that stopped responding, a channel that stopped converting. The eval set is not a one-time artifact. In practice the vendor-master-change trigger fires more often than most teams expect; plan for it.