Three-Way Invoice Matching in Procurement — Resolving Mismatches Systematically
Published: April 10, 2026
In any procurement operation, the moment a vendor submits an invoice is when the organisation's exposure becomes real. Until that point, the purchase order is a commitment and the goods receipt is a record of what arrived. The invoice is the vendor's claim for payment. If the invoice does not match the PO and the GRN, the organisation faces a choice: pay the wrong amount, or investigate the discrepancy.
Most organisations investigate manually. Someone in accounts payable opens the invoice, pulls up the PO in one window, checks the GRN register in another, and compares line by line. For a single invoice with three line items, this takes minutes. For hundreds of invoices per month with varying quantities, prices, and tax treatments, the manual approach consumes days — and errors still slip through.
This article explains how three-way matching works in a structured procurement system, what types of mismatches arise, and how each is resolved systematically.
1. The Problem — Why Manual Invoice Verification Fails
Manual invoice verification suffers from predictable failure modes:
- Overpayments: The vendor invoices at a higher price than the PO, and the accounts team does not catch the difference. Over time, small per-unit overcharges compound into significant overpayments.
- Duplicate payments: The same invoice is submitted twice (or a credit note is submitted alongside the original invoice), and both are processed. Without systematic matching, duplicates are caught only during reconciliation — if at all.
- Quantity disputes: The vendor invoices for 100 units, but the GRN records only 95 as received. Without matching, the organisation pays for 5 units it never received.
- GST mismatches: The vendor charges IGST when the transaction is intra-state (should be CGST + SGST), or applies an incorrect tax rate. The organisation claims incorrect input credit, creating a liability during GST audits.
- No accountability: When mismatches are discovered during the annual audit, there is no record of who approved the payment, whether the mismatch was known at the time, or what the resolution was.
The common thread is the absence of a systematic comparison step between the three documents — PO, GRN, and invoice — before payment is authorised.
2. What Is Three-Way Matching
Three-way matching compares three documents for every invoice line item:
| Document | What It Records | Who Creates It |
|---|---|---|
| Purchase Order (PO) | What was agreed — item, quantity, unit price, tax rate, delivery terms | The buying organisation, after approval |
| Goods Receipt Note (GRN) | What was actually received — item, quantity received, condition, receipt date | The store or receiving department |
| Invoice | What the vendor is billing — item, quantity billed, unit price, tax amount, total | The vendor |
For each line item, the system compares:
- Quantity: PO quantity vs GRN received quantity vs invoice quantity. All three should match, or the differences should be within acceptable tolerances.
- Unit price: PO agreed price vs invoice price. The GRN typically does not carry price information — price matching is PO-to-invoice.
- Tax amount: Expected tax (computed from PO price and applicable GST rate) vs invoiced tax. This includes verifying the correct GST split (CGST/SGST vs IGST).
Three-way matching is not a new concept — it is standard practice in any properly governed accounts payable function. What changes with a structured system is that the comparison happens automatically, tolerances are configurable, and every match or mismatch is recorded with an audit trail.
3. Types of Mismatches
3.1 Quantity Mismatch
The most common mismatch. It arises when the quantity received (per GRN) differs from the quantity invoiced by the vendor.
- Under-receipt: The vendor invoices for 100 units, but only 95 were received. The organisation should not pay for 5 units it does not have.
- Over-receipt: The GRN records 105 units received against a PO for 100. The vendor invoices for 100. The extra 5 units need to be addressed — either returned, or the PO amended to cover the excess.
- Partial delivery: The PO is for 100 units, the vendor delivers 60 in the first shipment (GRN records 60), and invoices for 60. This is not a mismatch — it is a partial fulfilment. The system tracks the remaining 40 as outstanding against the PO.
3.2 Price Mismatch
The vendor's invoice shows a unit price that differs from the price agreed in the purchase order.
- Price increase: The PO states Rs 1,000 per unit, but the invoice shows Rs 1,200. This could be a legitimate price revision (communicated but not updated on the PO) or an error.
- Price decrease: The invoice shows a lower price than the PO — less common, but it happens with promotional pricing or negotiated discounts applied after PO issuance.
Tolerance-based handling helps here. If the organisation configures a 2% price tolerance, a PO price of Rs 1,000 and an invoice price of Rs 1,015 would auto-accept. An invoice price of Rs 1,050 (5% above) would be flagged for manual review.
3.3 GST Mismatch
GST mismatches are particularly consequential because they affect input tax credit claims:
- Wrong GST type: The vendor charges IGST on what should be an intra-state supply (CGST + SGST), or vice versa. This is determined by comparing the vendor's GSTIN state code with the organisation's GSTIN state code.
- Wrong rate: The vendor applies 18% GST when the item falls under 12% or 5%. The applicable rate depends on the HSN code.
- Arithmetic error: The tax amount does not match the taxable value multiplied by the stated rate.
4. Resolution Workflow
When a mismatch is detected, it follows a structured resolution path:
- Detection: The system automatically compares the invoice against the PO and GRN at the point of invoice entry. Mismatches are classified by type (quantity, price, GST) and severity (within tolerance, outside tolerance).
- Flagging: Mismatches outside tolerance are flagged and assigned to the appropriate person for review — typically the procurement officer who raised the PO or the accounts payable team lead.
- Investigation: The reviewer examines the mismatch, contacts the vendor if needed, and determines the root cause — was it an error, a legitimate change, or a dispute?
- Resolution: The reviewer selects a resolution action:
- Accept: Accept the vendor's invoice as correct (e.g., a price revision was agreed verbally but the PO was not updated).
- Reject: Reject the invoice and ask the vendor to resubmit with corrected amounts.
- Raise debit note: Accept the invoice partially and raise a vendor debit note for the disputed amount.
- Approval: The resolution decision goes through its own approval workflow. A junior accounts officer cannot unilaterally accept a Rs 50,000 overcharge — the resolution must be approved by someone with the appropriate authority.
Every step — detection, flagging, investigation notes, resolution decision, and approval — is recorded with timestamps and user identities. This creates a complete audit trail for each mismatch from discovery to closure.
5. Vendor Debit Notes
When the resolution is to reduce the amount owed to the vendor, a vendor debit note (VDN) is raised. There are four common scenarios:
| Type | Trigger | Example |
|---|---|---|
| Price Overcharge | Invoice price exceeds PO price beyond tolerance | PO: Rs 1,000/unit. Invoice: Rs 1,200/unit. Debit note for Rs 200/unit x quantity. |
| Quantity Excess | Invoice quantity exceeds received quantity | Invoiced: 100 units. Received: 95 units. Debit note for 5 units at PO price. |
| Quality Rejection | Goods received but rejected during inspection | Received 100 units, 8 rejected on quality. Debit note for 8 units. |
| Damage | Goods received in damaged condition | Received 100 units, 3 damaged in transit. Debit note for 3 units. |
Each debit note carries the correct GST treatment — if the original purchase was intra-state with CGST/SGST, the debit note reverses the proportional CGST and SGST amounts. If it was inter-state, the debit note reverses the proportional IGST. This ensures input tax credit claims remain accurate.
Debit notes follow their own approval workflow before being communicated to the vendor. The vendor receives the debit note and can either accept it (adjusting their receivables) or dispute it (triggering a further round of negotiation).
6. The Role of Gate Entry
Before a GRN is created, goods physically arrive at the organisation's premises. Gate entry is the first checkpoint in this process.
When a delivery arrives at the gate, the security or stores team records:
- The vendor and delivery challan details
- The number of packages, cartons, or units received
- The PO number referenced by the vendor
- Any visible damage to packaging
This gate entry record serves as preliminary evidence of receipt. The formal GRN — which involves detailed inspection, quantity counting, and quality checking — happens after the goods move from the gate to the stores or inspection area.
The gate entry and GRN together form the "receipt" side of the three-way match. If the gate entry records 100 cartons but the GRN (after unpacking and counting) records only 95 usable units, the discrepancy between gate entry and GRN itself becomes a data point for investigation — was there damage during unpacking, or did the vendor short-ship within sealed cartons?
7. Impact on Books — How Resolved Mismatches Flow to Accounting
Every resolved mismatch produces an accounting consequence:
- Accepted invoice (no mismatch): A standard purchase voucher is generated — debit the asset or expense account, credit the vendor, post GST to input credit ledgers, deduct TDS where applicable.
- Price overcharge debit note: A debit note voucher is generated — debit the vendor's account (reducing the payable), credit the asset or expense account (reducing the capitalised cost), and reverse the proportional GST input credit.
- Quantity rejection debit note: Similar to price overcharge — the debit note reduces the vendor's payable by the value of rejected units, including proportional GST reversal.
- Partial acceptance: The accepted portion generates a purchase voucher at the accepted quantity and price. The rejected portion generates a debit note. Both vouchers are linked to the same invoice for traceability.
When the Tally integration module is enabled, these vouchers are generated automatically with the correct ledger mappings, GST treatment, and TDS deductions. The finance team reviews the generated vouchers and imports them into Tally.
The accounting treatment of mismatches is not optional. Every rupee of difference between what was ordered, what was received, and what was invoiced must be accounted for — either through the purchase voucher, a debit note, or a provision. A structured matching system ensures that none of these differences are lost or ignored.
8. Frequently Asked Questions
How does invoice matching work under GST?
GST invoice matching has two layers. The three-way match at receipt (PO vs GRN vs invoice) checks quantity, price, and tax before payment. The GSTR-2B match at return filing compares vendor-reported invoices against your purchase records. A mismatch at either layer blocks payment or triggers an input tax credit reversal.
How do I handle mismatches between PO, invoice, and receipt?
Compare quantity, unit price, and GST across all three documents. A quantity mismatch reduces the payable amount to the received quantity. A price mismatch triggers approval at the PO owner's level with a variance reason. A GST mismatch blocks payment until the vendor issues a corrected invoice.
What is 3-way matching in procurement?
Three-way matching is the process of comparing three documents before approving a vendor payment: the purchase order (what was agreed), the goods receipt note or service acceptance (what was actually received), and the vendor's invoice (what the vendor is billing). The comparison checks quantity, unit price, and tax amounts. When all three documents align within acceptable tolerances, the invoice is cleared for payment. When they do not, the mismatch must be investigated and resolved before payment proceeds.
How are quantity mismatches handled?
A quantity mismatch occurs when the quantity on the vendor's invoice differs from the quantity actually received (as recorded in the GRN). For example, the vendor invoices for 100 units but only 95 were received. The system flags this as a quantity mismatch and presents the user with resolution options: accept the invoice quantity (if the remaining 5 are expected in a subsequent delivery), reject the excess (and raise a debit note for the 5 units), or partially accept (accept 95 and dispute 5). Each resolution is recorded with the user's decision and timestamp.
What happens when the invoice price differs from the PO price?
A price mismatch occurs when the unit price on the invoice differs from the unit price agreed in the purchase order. If the difference falls within a configured tolerance (for example, within 2%), the system can auto-accept the invoice price. If the difference exceeds the tolerance, the mismatch is flagged for manual review. The reviewer can accept the vendor's price (if a price revision was agreed but not updated on the PO), reject the invoice price and raise a debit note for the overcharge, or negotiate with the vendor and update the resolution accordingly.
Can mismatches be partially accepted?
Yes. Partial acceptance is supported for quantity mismatches. If the vendor invoiced for 100 units, 95 were received, and the organisation decides to accept 95 and dispute 5, the system records this as a partial acceptance. The accepted portion (95 units at the agreed price) clears for payment processing, while the disputed portion (5 units) generates a debit note or remains in dispute until resolved. This avoids holding up the entire invoice over a partial discrepancy.
How do resolved mismatches appear in Tally?
When the Tally integration module is enabled, resolved mismatches generate the appropriate accounting vouchers automatically. An accepted invoice generates a purchase voucher with the final agreed amounts. A debit note for a price overcharge generates a debit note voucher that reduces the vendor's account and reverses the proportional GST input credit. A quantity rejection generates a similar debit note voucher. Each voucher maps to the correct Tally ledgers — vendor, asset or expense account, GST components, and TDS where applicable. The finance team reviews and imports these vouchers into Tally.