What Happens When an Automated Invoice Match Fails?

A failed invoice match should become an assigned investigation, with the invoice, purchase order, relevant receipt and discrepancy kept together. The reviewer resolves the underlying difference or records an authorized exception. Changing the data or widening a tolerance simply to obtain a pass can hide the problem the match was meant to reveal.

In both Oracle and Microsoft finance software, a failed match stops the invoice short of payment. Oracle Payables places a matching hold on an invoice that falls outside the price or quantity tolerances, and the hold must be released before the invoice can be paid. Dynamics 365 Finance flags the discrepancy and lets the invoice be saved until it is approved for posting or the vendor sends a correction. The software stops the money; people still have to settle the difference.

This is a guide to purchase-order invoice exceptions for finance and purchasing teams. For the wider implementation decision, start with what to automate first in accounts payable.

Explore an illustrative finance exception and review workflow.

First identify which check failed

Microsoft’s Dynamics 365 Finance documentation distinguishes price checks in two-way matching from the additional receipt-quantity checks in three-way matching. A price match can therefore coexist with a missing or incomplete receipt. These are product-specific controls to inspect in your ERP, not an approval policy for every invoice.

A tolerance sets how much difference is allowed before a line fails. In Microsoft's example, a legal entity allows a 5 percent net unit price tolerance: against an order price of 1.00 per battery, an invoice at 1.05 passes and one at 1.10 fails. For price totals, the tolerance can be a percentage, an amount (Microsoft calls it a not-to-exceed amount) or both, and exceeding either one creates a discrepancy. Net unit price tolerances can be set for items, item groups, vendors, vendor groups, item and vendor combinations or the whole legal entity. Treat any tolerance change as a policy decision with its own approver, never as a way to clear a queue.

Read the failure at line level. Is the supplier identity wrong, the purchase-order reference missing, the quantity different, the price outside tolerance, or a charge unexpected? Check whether the software compared the intended records before asking someone to authorize the difference. A legitimate invoice associated with the wrong purchase order is a record-selection problem, not a reason to approve a price variance.

Make the next action unambiguous

The following resolution method is a proposed design for your team to adapt, not a client implementation.

Each queue record should show the entity and location, source document, affected order line, original and extracted values, failed rule, current owner, due date and required closure evidence. Keep AP accountable for tracking the item while assigning the factual question to the person who can answer it.

Service invoices need service-acceptance evidence where policy requires it. Do not manufacture a goods receipt for a service simply because the software expects a third document. Non-PO invoices also need an explicit alternative approval path.

Walk a short receipt through to closure

This is an illustrative transaction, not a client record: the order and invoice each show 100 units, while the selected receipt shows 80.

AP first verifies that the invoice and order refer to the same item and unit. Receiving checks whether the remaining 20 units arrived in another delivery, whether an existing receipt was omitted, or whether the supplier billed ahead of shipment. Until that question is answered, the system preserves the discrepancy.

If another valid receipt exists, the reviewer links it and reruns matching. If only 80 arrived, the buyer follows the company’s policy for supplier correction, partial invoicing or an authorized exception. The selected treatment and supporting records become part of the history. The software does not silently rewrite the invoice to 80 and describe it as a successful match.

A resolved queue item still needs a controlled handoff

Define separate states for investigation complete, ready for approval, approved for posting and paid. Resolving a match does not itself complete payment authorization. When a corrected document arrives, retain the earlier version and rerun the relevant checks. Reopen the item if the correction introduces a different discrepancy.

For an integration, retain the source invoice identifier and destination transaction identifier. After a timeout, check whether the destination already created the transaction before retrying. Send unresolved failures to an owner; an invisible retry loop is not a recovery process.

AI assistance can propose fields or summarize the discrepancy, with the original document visible. Do not let a confident summary substitute for the receipt, agreement or duplicate investigation needed to settle it.

Judge the queue by its unresolved work

Before a pilot, record exception volume, time awaiting each owner, oldest open item and reopened cases. Test partial shipments, unit changes, duplicate submissions and an unavailable ERP. Inspect a sample of cleared items too: a falling queue is useful only if differences are being resolved correctly.

A practical acceptance requirement is that every failed match remains visible until a named person records the approved resolution and its evidence. Apply the same standard across locations; the finance operations overview shows how this fits a broader improvement effort.