What counts as an invoice exception?
An invoice exception is a discrepancy or missing prerequisite that prevents an invoice from following its normal processing route. The team might need a receipt, an explanation of a price difference, a credit note, or a decision about whether two submissions represent the same charge.
Three-way matching gives one familiar starting point. It compares invoice pricing with the purchase order and invoiced quantities with the corresponding receipts. Microsoft documents those checks, including configurable tolerances, in its Dynamics 365 invoice-matching overview.
An agent can gather the surrounding evidence when a check fails. Its first useful output is an explanation an AP reviewer can act on, with links to the records behind it.
For finance leaders, the outcome to measure is a correctly resolved obligation: what remains payable, what stays disputed, and what needs someone else's action.
Reconstruct the invoice before proposing a correction
Consider an illustrative case. A supplier invoices an order in full, while the warehouse has recorded a partial receipt. The supplier says another delivery has arrived and sends a revised document. AP now needs to establish whether receiving is behind, the invoice needs correcting, or the new document duplicates an existing obligation.
Start with the legal entity, supplier record, and invoice identifier. Connect individual invoice lines to purchase-order lines, receipts, and prior invoices. Retain the original submission alongside any revision so the reviewer can follow what changed.
The investigation should answer a small set of different questions:
| Record | What the agent needs to establish |
|---|---|
| Invoice and revisions | Which document is under review, and whether its lines or amount have changed |
| Purchase order | Which authorised order and line each charge relates to |
| Receipt or acceptance record | What has been accepted against that line, including relevant reversals or returns |
| Existing invoices and credits | What has already been recorded against the same obligation |
| Supplier correspondence | What the supplier is requesting and which supporting documents it supplied |
| AP and payment records | Which holds remain, the outstanding amount, and any payment processing already under way |
Use the source system's identifiers to preserve those relationships. If the warehouse record cannot be reliably connected to the invoiced delivery, the case should explain that missing link.
A delivery email may help the receiving team investigate. The workflow should obtain the required receipt or acceptance record before treating the goods as accepted under the organisation's process.
Give each discrepancy its own resolution
Partial receipts
Establish whether the remaining goods are still outstanding, have arrived but await recording, or were rejected. Check which quantities have already been invoiced against the received goods.
The receiving team owns the evidence of receipt. AP owns the permitted treatment of the invoice. Depending on the agreed process, the next step may be recording a supported receipt, obtaining a correction, or leaving the invoice waiting for the remaining delivery.
An agent should never create a receipt simply to make the matching result pass.
Price differences and credit notes
A promised credit still needs to be connected to the obligation it corrects. Preserve its supplier, reference, affected invoice lines, and amount, then use the approved AP operation to record the treatment.
Oracle's Credit Memo Matching Report exposes the relationship between credit memos and matched invoices, including distribution-level detail. That is a useful example of the evidence a reviewer should be able to inspect after a correction.
In the illustrative case, a revised invoice could replace an earlier submission or accompany a separate credit. Have AP establish which treatment applies before the agent creates another payable record.
Suspected duplicates
Compare the underlying charge as well as the document number. A reminder, corrected document, and genuinely separate invoice can look similar.
Oracle's additional duplicate-invoice check, when enabled, uses supplier, invoice type, amount, currency, and date together. Confirm what your system checks and give the reviewer the candidate records and their payment states.
A suspected duplicate requires a decision supported by that evidence. If one record has already been paid, route the case into the organisation's recovery process; cancelling an unpaid candidate cannot settle an existing overpayment.
Make the approval specific enough to execute
“Approved” is too little information for an agent to act on. The reviewer should see the invoice version, affected lines, evidence, proposed operation, and expected result. Approval might permit matching an existing credit or submitting an invoice correction. It should identify the exact scope.
Keep supplier-master changes in their own process. An invoice query that also requests new payment details introduces a different decision and verification requirement. The customised ERP guide follows that supplier-change approval path in detail.
After approval, reread the relevant records. A new receipt, revised invoice, or payment update may change what the reviewer authorised. Apply an agreed material-change rule and return changed cases for review when necessary.
The implementation must also preserve the ERP's validation behaviour. Oracle explains that some holds can be released manually, while others require a correction followed by validation. Its invoice-validation documentation illustrates both a missing receipt and a price correction. A general instruction to clear the hold loses that distinction.
Check the payment run before closing the case
Payment processing has its own state. The invoice may already have entered a selection or review stage while the investigation was open.
Oracle's payment-process documentation separates installment selection, document validation, payment validation, and payment-file processing. The available intervention depends on the stage and configuration.
Check that state before a consequential correction. If the case needs an intervention in an active payment run, route it to the authorised payments owner and verify their result. An invoice hold should not be assumed to reverse work already performed downstream.
After execution, read back the corrected lines, credit relationships, outstanding amount, and remaining holds. Record the observed payment status separately. The supplier-facing case can then say whether a correction is complete, an invoice awaits payment processing, or an issue remains open.
If an update succeeds but its response is lost, locate the resulting record before retrying. When the correction exists and only the case update failed, resume the case update using that reference.
Test the cases your AP team actually has to untangle
Start with one exception class and one agreed organisational scope. Use representative cases with approved, de-identified evidence, then introduce interruptions and changed documents before expanding access.
| Acceptance case | Result the AP owner should inspect |
|---|---|
| Partial receipt followed by a later delivery | The invoice uses the correct receipt lines and previous billing is accounted for |
| Credit received after review began | The credit is linked correctly and the proposed treatment reflects it |
| Revised invoice after approval | A material change triggers the agreed review requirement |
| Two submissions for one charge | The decision preserves the valid obligation and prevents duplicate processing |
| Invoice already in a payment run | The authorised payments owner handles any required intervention |
| Correction saved, response lost | Recovery finds the saved result and avoids repeating the correction |
Measure time to an accepted resolution, reviewer effort, and cases reopened because another system still needed work. Track unsupported releases, duplicate actions, and incorrect supplier updates explicitly. Set the pilot's acceptance thresholds with the AP owner before running it.
Where Monarch fits
Monarch can provide the application understanding and orchestration needed to connect an invoice investigation across enterprise systems. Its Product Graph maps operations and their requirements within the connected account's accessible, discovered, and verified scope, including available public APIs, private web operations, and UI paths.
For AP, evaluate the specific operations needed to read receipt evidence, inspect an invoice, carry an approved correction, and verify the result. Keep established matching and payment controls in the process. Finance supplies the authoritative policy, permitted treatments, and approval rules.
The useful proof is a completed exception whose financial records and case history agree, with any remaining action assigned to an owner.
Frequently asked questions
Can an AI agent approve invoice exceptions?
Approval authority comes from the organisation's policy and system configuration. Define which cases require a person and what any automated decision may authorise. Evidence preparation and execution permissions should reflect those choices.
Does a missing receipt mean the invoice is wrong?
The receipt may be late, incomplete, or linked incorrectly, or the delivery may still be outstanding. Investigate those possibilities with the receiving owner before deciding how to treat the invoice.
How should the agent handle a corrected invoice?
Retain the earlier version, identify what changed, and establish the approved replacement or credit treatment. Check for an existing payable and refresh any approval affected by the change before updating records.
When is an invoice exception resolved?
When the approved treatment is recorded and verified, the case reflects the resulting AP and payment states, and remaining work has an owner. Resolving a discrepancy does not itself establish that payment has completed.
Bring one invoice-exception process and the records your team has to reconcile. Talk to Monarch about a scoped pilot.