3-way matching, explained with a real invoice

Take one invoice: ₹8,20,000 for software licenses. Before anyone pays it, three questions need answers. Did we order this? Did we receive it? Are we being charged what we agreed? Three documents answer them: the purchase order, the goods/service receipt, and the invoice itself. Checking them against each other is 3-way matching.

The manual version

In most AP teams this means pulling the PO from one system, finding the GRN in another (or an email), and comparing line by line. It takes minutes per invoice when everything agrees and hours when it does not. Under month-end pressure, the temptation is to pay first and reconcile later, which is exactly how duplicate and over-billed payments happen.

The automated version

In Cimmra, the invoice arrives already linked to its PO, either submitted by the supplier through the portal against the PO, or captured and matched on entry. The platform compares quantities, rates, and totals across all three documents automatically:

• Clean match: PO ₹8,20,000, GRN ₹8,20,000, invoice ₹8,20,000. The invoice goes straight through to payment approval. No human touches it.
• Exception: the invoice says ₹8,61,000. The match fails with a reason: rate variance on line 2. It routes to the buyer who owns the PO, with both documents side by side.

What the numbers look like

Well-run implementations see the majority of invoices match without touch, cycle times drop from weeks to days, and payment-on-time rates climb, which suppliers notice. Every match and exception is logged with its resolution, so the audit trail is complete by construction.

Two-way matching (PO and invoice only) is available for service categories where receipts don't apply. The principle is the same: agreement is verified before money moves, not after.