Invoice 3-Way Matching & PO Receipt Audit

What does PO Invoice & Receipt Exception Report do?

Turn purchase orders, new invoices, prior invoices and split receipts into an evidence-backed review queue. Accounts-payable teams and purchasing operations can see which supplied PO lines need follow-up before completing their own invoice review. Receive a purchase-line reconciliation, exact decimal totals, CSV findings and a readable HTML report. Run it from Apify Console without installing software; API access is available for repeated exports.

For example, a new invoice bills 30 EA against 60 EA received. Viewed alone, that invoice does not show a quantity shortfall. Include the earlier 40 EA invoice and the two receipt records of 20 and 40 EA: the report shows 70 invoiced versus 60 received, with a 10 EA receipt shortfall. The starter kit and worked example contain the exact synthetic files and report. The result is a review exception in supplied evidence, not an invoice payment decision.

Why use this invoice and PO reconciliation?

Run the same checks each time you receive another invoice batch. The report identifies cumulative over-invoicing, invoice unit-price changes, receipt shortfalls, excess receipts, duplicate document lines, missing links and incompatible units or currencies. Exact identifiers keep evidence traceable. There is no fuzzy product matching or unexplained match score.

Apify API access, scheduling and integrations can run the report on repeated exports. Use the API tab for an invocation example. Every new run is a separate report, including a repeat of the same input.

How to use it

1. Open the Input tab in Apify Console. Leave its prefilled synthetic input unchanged for a first demonstration. A completed demonstration is a paid report at the displayed price.
2. Start the Actor. Open report.html in the completed run's Output; download findings.csv to review the exceptions and reconciliation.csv for the contributing PO-line totals. The prefilled example also demonstrates duplicates and incompatible evidence.
3. For a simpler one-line example, use demo/INPUT.json from the starter kit. Switch the Input editor to JSON and paste that object. Its expected result is 70 EA invoiced, 60 EA received and 10 EA shortfall.
4. For your own run, export the selected PO lines, all receipts in that cumulative scope, current invoice lines and all relevant historical invoice lines. Keep supplier, PO, document and line IDs as text, including leading zeros. The kit supplies four canonical CSV templates and a preparation guide; adapt source headers deliberately rather than guessing links.
5. Set the history and receipt coverage flags only after checking the complete scope. If an export is partial or unknown, leave its flag false and treat the result as incomplete. Download the report and inspect accepted/excluded references with the original records.

Unzip the kit and open prepare.html locally. Choose the four CSV files, review the history/receipt completeness and download Console-ready input JSON. No software installation, ERP login or extra service is needed; selected records stay in your browser. The optional Node.js 22 assembler supports scripted preparation without packages and preserves decimal strings.

Repeat the check when the next invoice arrives

Move previously reviewed current invoice lines into the historical export, replace the current batch, and refresh all receipts and PO lines in the same scope. Each invoice line belongs in either current or historical input exactly once. Save your input as an Apify task if useful; a task retains a configuration, so supply fresh exports for the next period. Use the API tab to integrate the same input/output contract with your workflow. Re-running unchanged data produces another billable report, not new evidence.

Input schemas and exact matching

The top-level tables are purchaseOrders, invoices, historicalInvoices and receipts. They are JSON arrays. The equivalent CSV fields are purchaseOrdersCsv, invoicesCsv, historicalInvoicesCsv and receiptsCsv. Omitted tables are empty. At least one row is required overall. The example input includes a matched line, multiple partial receipts, historical invoices, price deviations, currency/unit differences, duplicate PO and invoice lines, and missing links.

Table	Fields
All tables	supplierId, poId, poLineId, quantity, unit
Purchase orders	Common fields plus currency, unitPrice
Invoices and historical invoices	Common fields plus currency, unitPrice, invoiceId, invoiceLineId
Receipts	Common fields plus receiptId, receiptLineId

All quantities and prices must be decimal strings, such as "0.125" or "100". JSON numbers, thousands separators, exponent notation, negative values and leading zero decimal forms such as "01" are rejected. Up to 12 integer and 6 fractional digits are supported. Zero is allowed. Values are calculated with integer arithmetic; quantity × price retains up to 12 fractional digits without currency rounding.

Identifiers are strings up to 80 characters. Leading zeros remain significant: "001" and "1" differ. Matching is case-sensitive and uses exactly supplierId + poId + poLineId. No trimming or case conversion is performed; padded IDs are rejected. Missing/empty linking and document IDs produce findings and exclude affected evidence instead of inventing matches. Units are explicit, case-sensitive strings up to 24 characters. Currencies must be uppercase three-letter codes; the Actor checks exact equality, not currency-code validity or conversions.

Every occurrence of a duplicate PO key is ambiguous. Every occurrence of a duplicate document-line identity is excluded. Invoice uniqueness is supplier + invoice ID + invoice-line ID, across both current and historical tables. Receipt uniqueness is supplier + receipt ID + receipt-line ID. Different suppliers can reuse document numbers. An invoice line must appear in either current or history, never both.

CSV supports a UTF-8 BOM, quoted commas, escaped quotes and quoted multiline fields. Blank physical lines are skipped. Duplicate or padded headers, irregular row lengths and malformed quoting are rejected. By default headers must be canonical field names. To map source exports, use columnMappings, for example:

{
  "columnMappings": {
    "purchaseOrders": {
      "supplierId": "Vendor", "poId": "Order", "poLineId": "Line",
      "quantity": "Qty", "unit": "UOM", "currency": "Currency", "unitPrice": "Price"
    }
  }
}

Map each required field. Unmapped columns are ignored only when an explicit mapping is supplied. Unknown JSON row fields are rejected. Use the included CSV example to test a mapped import.

Coverage, tolerances and interpretation

historyComplete and receiptsComplete default to false. Set historyComplete: true when all relevant prior invoices are submitted, including when you know there are none. Set receiptsComplete: true when the submitted receipts cover the same cumulative scope. These are caller assertions, not facts verified by the Actor. Unconfirmed coverage marks all purchase lines incomplete.

tolerances accepts quantity and unitPrice, both nonnegative decimal strings defaulting to "0". Quantity tolerance applies to invoice-over-order, invoice-over-receipt and receipt-over-order differences. Unit-price tolerance applies to the absolute difference between each invoice price and its linked PO price, including historical invoices. A difference equal to tolerance is not flagged. There is no percentage tolerance. These numerical thresholds apply in each line's unit/currency; use separate runs if different lines need different thresholds.

Current and historical invoice quantities are summed. Receipt quantities are summed separately. Unit/currency mismatches, duplicate document lines and missing required identity are excluded from both quantities and money. Incomplete line totals describe accepted evidence only and are not final liabilities. A missing PO or ambiguous match produces a finding without allocation. Absent comparable receipts for a positive invoiced quantity remain incomplete even under a large tolerance.

orderedUnreceivedQuantity is an informational outstanding quantity, not a late-delivery finding. cumulativePriceVariance is the signed difference between accepted invoice value and accepted cumulative invoice quantity × PO unit price; it is not compared to the full PO value. Quantity over-invoicing is checked separately. No totals are summed across currencies or units.

Output and downloads

The default dataset contains one complete report item with summary, scope, rows and findings. You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. For a flat review workflow, use these dedicated key-value-store files:

File	Contents
OUTPUT	Full compact JSON report, including reconciliation and findings
reconciliation.csv	One row per submitted PO line, totals, status and evidence references
findings.csv	Stable finding ID, severity, reason, source references and applicable numerical evidence
report.html	Escaped, standalone readable report, with no external scripts or assets

Source references use the table name and 1-based data-row index, excluding CSV headers. For example receipts:2 refers to the second parsed receipt record, not necessarily physical file line 3 when quoting spans lines. Aggregate findings point to a purchase-row reference whose accepted/excluded reference lists identify all contributing evidence. Finding IDs are deterministic for the same input order, not permanent identifiers across reordered files.

no-exceptions means no checked exception in submitted comparable records under the configured tolerances. exceptions identifies review findings with otherwise comparable evidence. incomplete means identity, coverage or comparability prevents a complete reconciliation. Report-level reviewRequired also includes orphan source rows that cannot be assigned to a PO. CSV fields that could execute spreadsheet formulas receive an apostrophe prefix; use JSON when exact unmodified identifiers are needed.

Pricing and limits

The price is $0.50 per completed report, with platform usage included, for up to 10,000 combined rows and 4 MB of JSON input. One report-completed event is charged after all exports have been validated and saved, using one complete dataset item. There is no startup fee or additional dataset-item fee. Invalid input and insufficient report budget do not produce a report charge. New runs are billable again.

Full JSON is capped at 8 MB and each download at 9 MB. Exception-heavy data or long identifiers can reach those output limits before the row limit; split that input into smaller complete scopes. All output sizes are checked before any report event. Defaults are 1024 MB memory and a 180-second timeout.

If an execution stops while writing exports, some downloads can exist before billing; resume the same run to complete them. If a dataset write succeeds but charging is interrupted, resurrection validates the input fingerprint and deterministically rebuilt saved report before charging once. An already charged saved report regenerates downloads without another event. Do not change input, edit the saved dataset, or delete its only report before resurrection. Use a new run for revised data.

Limits, privacy and support

This Actor provides arithmetic exception review, not payment approval, invoice rejection, tax advice, accounting compliance, fraud detection or proof of receipt. It supports supplied cumulative snapshots, without dates or automatic period filtering. Callers must align the reporting scope. Credits, returns, cancellations, discounts, taxes, freight, OCR/PDF extraction, ERP synchronization and currency/unit conversion are outside this version. Negative values and unsupported fields are rejected.

Submit only records you are authorized to process. Inputs and generated reports are held in your Apify run storage under your account's access and retention settings; this Actor does not delete them automatically. Raw commercial rows are not logged. No customer data is sent to an external AI provider or target website. Refer to the Issues tab for reproducible problems using synthetic examples, and avoid attaching confidential invoices.

The distinction between unit-price and cumulative quantity checks is consistent with the terminology in Microsoft's invoice-matching overview. This Actor is an independent, narrower report and does not implement that system's accounting policies.

Download the synthetic worked HTML report. Open it locally to inspect the sample before starting a paid run.