Invoice Three-Way Match Anomaly Detection

Three-way match compares a supplier invoice to the purchase order and the goods receipt before anyone posts payment. Anomaly detection scores quantity, price, and tax differences on that match so an AP lead can see which invoices look wrong before they enter the approval queue.

This page is for manufacturing accounts payable: plants that receive against POs, invoice in SAP, Coupa, or AvidXchange, and still require a person to approve or reject payment. The model does not post, park, or release invoices. It flags mismatches. AP still decides.

The working unit is one supplier invoice line, or header tax, matched to the related PO line and the cumulative goods-receipt quantity for that line. The model looks for three discrepancy classes.

Quantity covers invoiced units that do not line up with received units, including over-billing, under-billing, and unit-of-measure confusion such as each versus case.

Price covers unit price or extended amount that does not match the PO, including unagreed surcharges, freight billed on the goods invoice, and a price that still reflects an old PO version after a buyer amended the order.

Tax covers tax code, rate, or recoverable versus expense split that does not match the PO, the plant jurisdiction, or the supplier tax setup.

This is not OCR, vendor-master cleanup, or duplicate-invoice detection. Those are separate controls. It is also not two-way match, invoice versus PO only, and it is not the SAP GR-based invoice verification posting rule by itself. GR-IV can still block posting. This layer ranks which failed matches look like cost leakage and which look like timing.

Manufacturing AP sees a lot of legitimate noise: partial receipts, backorders, consignment, and subcontracting. The useful output is a scored exception, not a binary fail. A one-line overage on a high-volume MRO invoice is a different problem from systematic unit-price drift on a raw-material contract.

In SAP, the source objects are the incoming invoice (MIRO or the invoice document), the PO, and the material document for goods receipt. Many plants already run GR-based invoice verification. The anomaly layer reads the same three documents after they exist, including parked or held invoices that have not posted. Do not treat inventory movements AP cannot use as a match basis, such as storage-location transfers or scrap, as a goods receipt.

In Coupa, the match sits on the invoice against PO lines and receiving records in Coupa receiving or an ERP receipt fed through integration. Coupa already has matching tolerances. This check is for residual anomalies inside or outside those bands: tax the tolerance ignored, quantity that passed because a plant-level band is wide, or a price that matched after a buyer edited the PO to clear the invoice.

In AvidXchange, invoices often arrive after delivery, with PO and receipt data coming from the ERP. The model needs the ERP PO and GR identifiers on the Avid invoice record. If AP codes invoices as non-PO in Avid to speed processing, this use case has nothing to score. Those invoices belong in a different control.

Shared rules: vendor, company code, PO number, PO line, material, plant, invoice number, and invoice line must align. Run after GR (or Coupa receiving) and invoice capture, before AP approval. Convert to PO currency and UoM first. Do not flag FX rounding inside treasury policy. Quantity and price at line; tax at line when item tax exists, otherwise header-level.

Do not treat this as a month-end report. The cost outcome depends on catching the discrepancy before approval and before the payment proposal.

Quantity flags that matter on a plant floor include invoice quantity greater than cumulative GR for the PO line after subtracting quantity already invoiced; invoice quantity that matches a GR for a different PO line or plant; catch-weight items where invoiced weight sits outside the expected band; and service or subcontracting lines invoiced as if goods were received, or the reverse.

Price flags include unit price versus PO net price after known conditions already on the PO (incoterms, freight, discounts); extended amount that does not equal quantity times price within rounding; a price that matches an old PO version after an amendment AP never saw; and surcharges billed as a new line with no PO reference.

Tax flags include a rate that does not match the tax code on the PO or the plant jurisdiction; tax charged on a reverse-charge or intra-company scenario that should be self-assessed; and a recoverable versus expense split that would post to the wrong GL if approved as billed.

Do not treat these as anomalies by default: invoices that arrive during a documented in-transit window if policy allows parking until GR; penny rounding; and tax differences the tax engine already recalculated and AP is instructed to accept. Those belong in a policy table, not in a silent model override.

Freight billed on a supplier invoice is a different audit than three-way match on the material lines. See Freight Invoice Audit. Whether a surcharge was allowed often sits in the contract, not on the PO snapshot. See Contract Clause Extraction.

This use case returns empty when the GR or the PO is missing. That is the correct behavior.

Without a PO, there is no contracted quantity or price to compare. Non-PO invoices, employee expenses coded through AP, and true emergency buys need other controls: an approval matrix, a duplicate check, and, for small repetitive buys, Tail Spend Taxonomy Classification so the spend at least lands in a category.

Without a goods receipt, you do not know whether the plant received the goods. Matching invoice to PO only is two-way match. In manufacturing, two-way match on inventory materials is a control gap: you can pay for goods that never hit the dock. The model should not fabricate a receipt from an ASN, bill of lading, or warehouse task confirmation unless finance policy has designated that document as the official GR.

Invoices that arrive before GR should wait in a pending-receipt state. Do not score them as quantity anomalies; they are incomplete. Returns and reverse goods receipts must update cumulative received quantity, or later invoices will false-flag. Drop-ship or customer-direct scenarios need an explicit receipt proxy, such as a customer GR or a vendor ASN that policy treats as GR. If that proxy is not in the system of record, leave the result empty and route to a drop-ship desk.

Treat empty output as "this invoice is not in the three-way-match population," not as "the invoice is clean."

The model produces a recommendation: match, review, or hold for buyer or receiving. It does not approve.

Clear into the existing approval workflow only when quantity, price, and tax sit inside documented tolerances and both PO and GR are present. Send quantity exceptions to the plant clerk who posted the GR, with PO line and GR numbers on the ticket. Send price exceptions to the buyer who owns the PO. Send tax exceptions to tax or AP tax-code owners, not to the plant. A second approver must sign any override that pays above PO plus tolerance, and the reason must name the discrepancy class.

Do not bypass SAP release strategy or flexible workflow, Coupa approval chains, or AvidXchange routing. If a bot approves inside the model, you have changed the control environment.

Measure invoices scored versus skipped (empty), time from capture to exception ticket, and amount held from the payment proposal. Those figures are plant-specific. Do not use an industry average.

Require PO and GR for the population you want to score. If buyers create POs after the invoice arrives, fix that first. Capture must keep PO line numbers. Write tolerances by company code and material type and have the model read them. Keep vendor tax classification stable enough that tax flags are about the invoice. Name an AP owner for the queue, with SLAs to receiving and procurement.

Start with one company code and one high-volume plant, quantity and price only, on invoices that already have PO and GR. Add tax after tax confirms the code mapping. Hold out subcontracting, consignment, and pipeline until those GR types are mapped. AP should then spend approval time on invoices that failed a real three-way comparison, not on invoices with no receipt.