Three-way matching across contract + PO + GRN + invoice — ap automation in under 90 seconds per bundle.
Manual three-way matching (contract + PO + invoice + GRN) breaks at scale. A controller at a mid-market company reconciles across five separate files and two or three spreadsheets before a single payment can clear — and three classes of variance slip through every cycle.
Contract, PO, MIS report, invoice, GRN — each in its own file, then stitched together in VLOOKUP-heavy spreadsheets. 2–4 person-days per close cycle just to assemble the matching trail.
The contract says ₹245 per unit, the invoice bills ₹258 — a 5% drift across 1,200 line items is ₹15,600 of silent overpayment. Manual reviewers don’t catch it because they check totals, not per-line rates.
PO and invoice agree on 10,000 units. The GRN records 9,400 received. Without placing all three side by side, the AP team pays the full invoice — recoverable only through a 30–60 day debit note process, often never fully recovered from international suppliers.
Contract says Net 45. Vendor invoice says Net 30. AP doesn’t spot the conflict and pays early — missing the working-capital benefit the procurement team negotiated. Or: contract is in USD with no GSTIN/PAN, but the validation engine flags it as a compliance failure rather than routing it through the international-vendor path.
The scale-break point for AP teams running three-way matching in Excel. Above ~100 open POs per month, the probability that at least one contract-to-invoice mismatch is missed exceeds 50%. Imported contracts denominated in USD with no GSTIN or PAN often surface the discrepancy only at the next statutory audit — well after the cash has left the building.
Three-way matching isn’t optional. Four overlapping control frameworks — two Indian, two US — require a documented matching trail for every significant payable. Skipping the structured comparison creates ITC exposure, audit findings, and recoverable-only-with-pain overpayments.
Input tax credit on domestic invoices is limited to what the supplier has reflected in GSTR-2B. A GRN that does not match the invoiced quantity creates an ITC-at-risk position — the buyer can’t claim credit on the unsupported delta.
For cross-border procurement, reverse-charge liability is computed from contract + invoice data. Without an accurate match between the contract value, the invoice and the GRN, the reverse-charge amount the buyer self-assesses can be wrong — understated or overstated.
US-entity procurement obligations fall under COSO 2013 Component 2 and are operationalised through PO-to-invoice matching controls. Mid-market companies relying on basic two-way matching (PO + invoice only) miss GRN quantity variance and payment-term drift entirely.
External auditors test the PO-to-invoice matching control under PCAOB AS 2110. A recurring gap — payments approved on invoices with no matching GRN or with terms differing from the contract — escalates the control from effective to deficient, or worse, a material weakness.
For controllers without a dedicated ERP configuration team, the practical failure looks like: a payment made on an invoice referencing a contract whose expiry_date is missing (no term-period validation possible), or a GRN that records 10–15% below the invoiced quantity. The vendor overpayment is recoverable only through a debit-note process that typically takes 30–60 days — and may never be fully recovered from international suppliers.
Seven deterministic steps that turn a folder of mixed procurement PDFs into a complete N-way match artifact. The whole pipeline runs in under 90 seconds per document bundle — the same procure to pay automation pattern mid-market controllers used to spend 2–4 days assembling by hand.
Accepts uploads of up to five document types simultaneously — Contract, Purchase Order, MIS Report, Invoice and Goods Received Note — and classifies each file by type using its registered schema before any field extraction begins.
Each document is parsed for its canonical fields: contracts yield contract_number, contract_value, payment_terms, effective_date, expiry_date, currency plus optional vendor_gstin / vendor_pan; POs yield qty + unit price + delivery date; invoices yield invoiced amounts + tax lines + due dates; GRNs yield received qty + acceptance date.
Seven validation checks per contract: Required Fields Present, Contract Value Optional, Date Format, GSTIN Length, PAN Length, Value Format, and Expiry vs Effective. Each returns pass, fail or ignore with a human-readable comment identifying the exact field and value that caused the result.
When neither vendor_gstin nor vendor_pan is present on a contract (e.g. USD-denominated cross-border contracts), GSTIN and PAN format checks are automatically set to ignore rather than fail — preventing false compliance alerts on international vendor documents.
Each source document (Contract or PO) is matched against its target document (Invoice or GRN) using the reconciliation engine. Matched pairs are recorded with a source_doc / target_doc identifier and a status of done once all applicable checks clear.
Documents that fail validation — contracts with a missing expiry_date, PDFs that return zero extracted fields (blank extraction), or invoices with payment terms that conflict with the originating contract — are held in a manual-review queue with the specific failing checks itemised, preventing any downstream payment action on an unresolved document.
Every extraction result, validation outcome and reconciliation pair is written to a structured output that maps each finding back to its source filename, document type and check name — producing a complete N-way match artifact ready for attachment to the AP close workpapers.
The workflow ships with a battery of synthetic test scenarios that exercise every failure mode we have seen in real-world data. Each scenario produces a deterministic outcome that an auditor or controller can verify in seconds.
Seeded sample files used to demonstrate this workflow. Each one exercises a specific scenario or failure mode.
USD-denominated supply contract between Misfits Market, Inc. and Xiamen OceanCarton Ltd. for 7,500 insulated mailers at USD 0.55/EA (contract value USD 4,125). Demonstrates missing expiry_date triggering dual validation failures and GSTIN/PAN ignore logic for cross-border vendors.
Domestic Indian service agreement with both GSTIN and PAN fields populated and validated. Shows a fully clean extraction pass — all seven validation checks return 'pass', including expiry date vs effective date comparison and 15-character GSTIN format verification.
USD supply contract with PolarPack Solutions Inc. (Winnipeg, Canada) for 6,000 gel ice packs at USD 0.38/EA (contract value USD 2,280). Illustrates Net 30 payment terms extraction and a blank validation_results array, indicating the document was queued but checks not yet executed.
Failed extraction case — both extracted_fields and validation_results are empty arrays. Represents a scanned or corrupted PDF that the OCR pipeline could not parse, used to demonstrate the workflow's unprocessable-document handling path.
For a mid-market AP team managing 80–120 open POs per month, this three-way matching engine collapses a 2–4 person-day exercise into a single 90-second automated pass — with check-level outputs every controller can audit line by line.
pass/fail/ignore + reasonPer-line price drift, GRN qty short-shipments and payment-term conflicts — the three classes that slip past header-only matching — are surfaced deterministically, with the failing field and value named in the exception.
Cross-border USD contracts with no GSTIN or PAN don’t generate false compliance alerts; the jurisdiction-aware routing sets those checks to ignore — so the queue carries only genuine anomalies, not format noise.
Every extraction result, validation check and reconciliation pair drops into a structured output that satisfies COSO 2013 and ICAI Guidance Note documentation tests — one referenced file in the AP close workpaper. The same artifact also drives purchase order matching and three way matching workpapers in the next AP cycle without rebuilding.
The questions accountants and finance controllers ask most often before deploying this workflow.
The workflow supports any combination of the five registered document types — Contract, Purchase Order, MIS Report, Invoice, and Goods Received Note — within a single matching run. A full five-way match is not mandatory; the engine will execute a two-way, three-way, or four-way match depending on which documents are uploaded, flagging any missing document type as an exception rather than blocking the run entirely.
For Indian entities, matching GRNs against invoices before payment supports the input tax credit conditions under Section 16(2)(aa) of the CGST Act, 2017, which requires that the supplier's invoice appear in GSTR-2B before ITC can be claimed. For US entities, three-way matching of PO, GRN, and invoice aligns with the internal control requirements described under COSO 2013 Control Activities and supports audit evidence requirements under PCAOB AS 2315 (Audit Sampling) by reducing the population of unmatched payables that auditors must test manually.
Cadel ingests documents as PDFs or structured exports; it does not require a live ERP connector to run matching. For Tally Prime and SAP Business One mid-market deployments, users export purchase registers and GRN logs as CSV or PDF and upload them as MIS Report documents. NetSuite users can export PO and vendor bill records via saved searches in CSV format. A bidirectional API is available for teams that prefer to push matched or exception records back into their ERP's payables module automatically.
Every document ingestion, field extraction, validation check result, and match decision is written to an immutable event log with timestamps and user identifiers. The log records the specific check name, pass/fail/ignore result, and the system comment (e.g., "Date comparison expiry_date gte effective_date passed"), which mirrors the evidence format expected under ICAI SA 230 (Audit Documentation). Internal auditors can export the full log as a structured JSON or PDF workpaper for inclusion in the audit file.
The workflow extracts the currency field from each document type independently and raises a currency-discrepancy exception when a PO or invoice currency does not match the originating contract currency. The exception holds the match in a pending state until a reviewer either enters the applicable exchange rate or uploads a corrected document. This prevents silent FX mismatches from reaching the payment run — a common source of variance in cross-border procurement for companies sourcing from China, Canada, or the EU.
Yes. For service-based procurement where no GRN exists, the workflow treats the GRN as an optional document type. The match proceeds on the available documents — typically Contract, PO, and Invoice — and logs the absence of a GRN as an informational note rather than a blocking exception. Teams can configure a service-acceptance certificate or a milestone-completion report as a functional substitute for the GRN, mapping it to the Goods Received Note document slot for validation purposes.
Classical three-way matching reconciles three documents: the Purchase Order (what was ordered), the Invoice (what the vendor billed), and the GRN (what was received). N-Way matching extends that by adding the originating Contract (terms, rate card, payment terms, expiry) and any MIS report (the operational log that captures actual usage, e.g. a vehicle-deployment log for a logistics contract). Adding those two documents catches the variances that pure 3-way matching cannot: unit-price drift between contract and invoice, payment-term conflicts (Net 30 vs Net 45), missing contract expiry dates that invalidate the entire term-period validation, and over-billed days where the invoice claims more service days than the MIS log records. For mid-market AP teams running procure to pay automation, N-Way is the upgrade path once 3-way matching has been instrumented.
Yes — this is exactly the case the jurisdiction-aware compliance routing was built for. When neither vendor_gstin nor vendor_pan is extracted from a contract (as with USD-denominated contracts to Chinese, Canadian or EU suppliers), the workflow automatically sets GSTIN and PAN format checks to ignore rather than fail. The reconciliation engine then runs against the remaining validation checks (contract value, dates, payment terms) and matches the international invoice on its native fields. This eliminates the false-positive compliance alerts that typically clog the exception queue in AP automation tools built only for domestic GST invoices.