PO Invoice Price Basis & Receipt Preflight

Compare one supplier invoice with one purchase order and cumulative split receipts. Normalize per-piece, per-100, per-1000, or another explicit price basis before comparing net unit prices. Supply structured JSON; receive an evidence-based exception report through the dataset and a downloadable JSON report.

For example, a PO quotes USD 50 per 100 EA, while the invoice says USD 0.50 per EA. Those prices agree. If the order is for 100 EA, earlier invoices billed 20 EA, the current invoice bills 40 EA, and two receipts contain 20 and 40 EA, the cumulative quantity also agrees. If the current invoice instead bills 50 EA, the report identifies a 10 EA receipt shortfall in the supplied scope.

Use it between an export or extraction step and human accounts-payable review. API users can put the same deterministic checks in n8n, Make, a spreadsheet workflow, or their own code. No LLM, paid external API, image/PDF download, fuzzy SKU match, or source-system connection is used.

Input

Paste the following object as JSON text into caseJson. API input uses the same string field. Every identifier must be a string; leading zeros are preserved. Quantity units must match exactly, including letter case. Prices must already be net of discounts and exclusive of tax and freight.

{
  "purchaseOrder": {
    "id": "PO-DEMO",
    "currency": "USD",
    "lines": [{
      "id": "001", "sku": "BOLT-001", "quantity": "100", "unit": "EA",
      "unitPrice": "50", "pricePerQuantity": "100", "previousInvoicedQuantity": "20"
    }]
  },
  "invoice": {
    "id": "INV-DEMO",
    "currency": "USD",
    "lines": [{
      "id": "1", "poLineId": "001", "sku": "BOLT-001", "quantity": "40", "unit": "EA",
      "unitPrice": "0.50", "pricePerQuantity": "1", "lineAmount": "20.00"
    }]
  },
  "receipts": [
    {"receiptId": "REC-A", "lineId": "1", "poLineId": "001", "quantity": "20", "unit": "EA"},
    {"receiptId": "REC-B", "lineId": "1", "poLineId": "001", "quantity": "40", "unit": "EA"}
  ],
  "receiptsComplete": true,
  "priorInvoicesComplete": true
}

pricePerQuantity defaults to 1 when omitted. previousInvoicedQuantity defaults to 0; confirm that zero is the full prior history before setting priorInvoicesComplete=true. Optional lineAmount is the declared net line amount. Optional sku is checked when supplied on both sides. All other displayed fields are required, except the receipt array and coverage flags. Unsupported fields are rejected, so tax, freight or discount values cannot be silently ignored.

Set receiptsComplete=true only when receipts cover the same cumulative PO-line scope as prior and current invoices. Missing flags produce INCOMPLETE_REVIEW. An explicitly confirmed empty receipt array means nothing has been received. Duplicate receipt keys or mismatched units make affected cumulative checks uncheckable instead of guessing a total.

Checks and output

• Net unit-price differences after dividing by each explicit price basis.
• Current plus previous invoiced quantities beyond the ordered quantity.
• Cumulative invoice quantities beyond confirmed received quantities.
• Excess receipts, duplicate PO/invoice/receipt line keys and missing references.
• Currency, quantity-unit and supplied SKU mismatches.
• Declared net amounts versus quantity × unitPrice / pricePerQuantity.

The dataset contains one report per run, with findings, invoice-line checks, per-PO-line quantities and decimal totals serialized as strings. REPORT contains the same full report in the key-value store. OUTPUT contains processing and budget status. No report is written when the report charge cannot fit the budget.

Statuses:

Status	Meaning
MATCHED_WITHIN_CHECKED_RULES	Supplied evidence and supported rules produced no discrepancies; this is not payment approval.
REVIEW_FINDINGS	Coverage is confirmed but discrepancies need human review.
INCOMPLETE_REVIEW	Missing scope, ambiguous references, incompatible units or currencies prevent a complete comparison.

paymentApproved is always false. A completed report may contain errors or incomplete coverage; those are useful findings, not an Actor execution failure.

Tolerances

priceTolerancePercent defaults to 0 and flags absolute deviations on either side of the PO price. quantityTolerance defaults to 0 and applies in each line's exact quantity unit. lineAmountTolerance defaults to 0.01 in the invoice currency; adjust it to your currency and rounding policy. Monetary arithmetic uses Decimal, with price-tolerance boundaries checked using cross-products. There is no inferred exchange rate, unit conversion or currency rounding rule.

Pricing

$0.05 per completed report ($50 per 1,000 reports), event report. Each report supports up to 500 PO lines, 500 invoice lines and 1,000 receipt lines, within 1 MiB of JSON text. Individual findings and lines are not separate billing events. Malformed inputs rejected before a report is generated are not billed as report events. Each repeated successful run is a separate completed report. The live Apify pricing configuration is authoritative.

Data handling and scope

Input is processed on Apify and stored under its normal run-input controls. Reports remain in the user's private run dataset/key-value store. The code makes no external data calls and does not log input documents, line identifiers or report contents. Provide only authorized data; omit banking details, names, addresses and unnecessary fields. Use your Apify account controls to delete run/storage records.

This version supports one PO and one current invoice, plus explicit previously billed quantities and multiple receipts. It does not allocate specific receipt lots to invoice lines or check historical invoice IDs for duplicate payments. It does not read PDFs, support credit notes/returns, verify documents, calculate taxes/freight/discounts, screen fraud, connect to an ERP or approve payment. Exact supplied PO-line IDs are required; these limits are deliberate so missing evidence is visible.

Rule background

Product rules were checked on October 9, 2026 against these primary references. This Actor is an independent deterministic preflight and does not reproduce an ERP's complete policy engine:

• Microsoft: Accounts payable invoice matching overview
• Microsoft: Invoice matching validation and tolerances
• Oracle: Two-, three- and four-way approval

For support, use the Actor Issues tab with a small synthetic or redacted case and the ruleset version. Never submit credentials or unredacted private records in a public issue.