Purchase Order → GRN → Vendor Bill: 3-way matching that actually works

Procurement • Accounts Payable • Controls

In many businesses, procurement leakage is not caused by a single big mistake—it is a thousand small ones: quantities not checked, invoices approved without receiving evidence, price changes that are never validated, and month-end surprises that require manual clean-up.

A clean purchase-to-pay flow connects three documents: the Purchase Order (PO), the Goods Receipt Note (GRN), and the Vendor Bill (AP). The goal is simple: if you pay a vendor, you should be able to prove what you ordered, what you received, and what you were billed for.

Why 2-way vs 3-way matching matters

2-way matching typically compares the vendor invoice against the PO. It answers: “Did we get billed at the price and quantity we ordered?” This is useful for services and direct invoicing scenarios.

3-way matching compares the vendor invoice against both the PO and the GRN. It answers: “Did we get billed for what we ordered and what we actually received?” This is critical for physical goods, partial receipts, and multi-location operations.

Core documents and responsibilities

Purchase Order (PO)

• Created by: procurement or requesting team
• Approved by: approvers based on amount thresholds
• Purpose: establish price, quantity, delivery terms, and budget intent

Goods Receipt Note (GRN)

• Created by: warehouse/store receiving team
• Purpose: record actual received quantities, dates, and any deviations
• Best practice: capture receiving evidence (photos, delivery challan, signed receipt)

Vendor Bill (Accounts Payable)

• Created by: AP team or automated capture flow
• Approved by: approvers based on policy (step approvals)
• Purpose: pay the vendor accurately and post to the ledger

Common failure modes (and how to prevent them)

1) Price drift between PO and invoice

This happens when prices change mid-month or a vendor applies updated rates without confirmation. The fix is not only matching—it is governance: approval templates that require review when variance exceeds a threshold.

2) Partial receipts that are billed as full

For partial deliveries, the invoice should match the GRN for the billed period. 3-way matching flags a bill that exceeds received quantities.

3) Duplicate bills

Duplicates often slip in when teams do not have a single source of truth. Use vendor bill numbering checks, audit logs, and a consistent AP workflow.

4) GRNI clearing confusion

GRNI (Goods Received Not Invoiced) clearing is an accounting concept used to track goods received but not yet invoiced. When your system connects GRN and vendor bills, GRNI becomes easier to manage because the linkage is explicit and auditable.

Workflow blueprint in NAViCalC

NAViCalC supports procurement controls through modules such as Inventory, Operations, and Accounting:

• Approval Templates: define approvers and steps for POs and vendor bills.
• Step approvals: multi-stage approvals for high-value purchases.
• Amount thresholds: route approvals based on total value.
• Audit logs and entity history: track changes to quantities, prices, and approvals.
• Vendor Bills (AP): link bills to POs/GRNs where configured.

Implementation checklist

• Standardize your vendor master and item master to avoid mismatched SKUs.
• Define who can create POs vs who can approve them (RBAC per module).
• Enforce GRN on receipt, even for partial deliveries.
• Require approvals on vendor bills above a threshold.
• Review variance reports weekly (price variance, quantity variance, unmatched bills).

Tolerance thresholds and exception handling

Matching is not always a strict yes/no decision. Real businesses deal with small price changes, substitutions, partial deliveries, and rounding differences. A mature purchase-to-pay process defines tolerances and makes exceptions visible.

• Price tolerance: allow small deviations (for example a minor rate difference) but require approval when variance exceeds a threshold.
• Quantity tolerance: prevent bills that exceed received quantities, but allow partial billing when policy permits.
• Receipt tolerance: handle damaged/short deliveries as explicit exceptions rather than silent edits.

The point of tolerances is speed with control: most transactions flow through, and only exceptions route to approvers.

GRNI clearing: what it means operationally

GRNI (Goods Received Not Invoiced) is often described as an accounting topic, but it has a practical operational meaning: your warehouse confirmed receipt, but finance has not yet received a vendor bill that matches that receipt. When GRN and vendor bills are linked, GRNI becomes measurable instead of mysterious.

A simple example

Assume you place a PO for 100 units. The supplier delivers 60 units this week and 40 units next week.

• Week 1: GRN for 60 units creates a “received” record.
• Week 1: No vendor bill yet, so those 60 units are “received not invoiced”.
• Week 2: GRN for the remaining 40 units completes receiving.
• Week 2: Vendor bill arrives for 100 units and is matched to both GRNs.

In this model, GRNI “clears” when the vendor bill is linked and approved. Your reports can show what is outstanding by vendor, by PO, and by aging.

Designing approval templates that teams actually follow

Approvals fail when they are vague. A good approval template has clear thresholds, predictable approvers, and a small number of required steps. NAViCalC supports approval templates and step approvals so you can define policies that scale.

• Keep steps minimal: too many stages pushes teams to bypass the process.
• Use thresholds: route only high-risk transactions (high value, high variance, sensitive category).
• Separate duties: requesters and approvers should be different roles (RBAC per module).
• Make exceptions explicit: require comments/reasons for overrides, then review them monthly.

Reports to review weekly

• Unmatched vendor bills: bills that have no PO/GRN linkage.
• Price variance: billed rate vs PO rate beyond tolerance.
• Quantity variance: billed quantity vs received quantity.
• GRNI aging: received items not yet invoiced, grouped by vendor and days outstanding.
• Approval overrides: transactions that bypassed standard approval paths (where tracked).

For scheduled delivery of these reports, use Reporting & Audit with report schedules and history.

FAQ

Do I need 3-way matching for services?

Not always. For services without receiving events, 2-way matching (PO vs vendor bill) can be sufficient. For physical goods, 3-way matching provides stronger control.

How do I handle partial receipts and partial billing?

Use GRN as the receiving truth, then allow partial billing that matches received quantities. Variances should be routed to approvers when they exceed tolerances.

How do I prevent back-dated changes?

Use period lock controls (where configured) and rely on audit logs/entity history so edits remain visible during reviews.

Mini case study: partial delivery with a price change

A common real-world scenario is a partial delivery followed by a vendor price revision. The safe approach is to keep documents linked and route variance for review.

• PO for 100 units at the agreed rate.
• GRN #1 receives 60 units. Vendor sends an interim bill for 60 units.
• Vendor later revises the rate for the remaining 40 units. This creates a variance vs the PO.
• Match the first bill to GRN #1, then route the second bill for approval because it exceeds the price tolerance.

This approach keeps procurement, inventory, and finance aligned and prevents silent rate creep that only appears during month-end analysis.

Where to go next

Learn more about Operations and Inventory Management, then review pricing to see how NAViCalC packages modules.