TallyPrime links PO, GRN and invoice for you. The gaps start where the linking stops

TallyPrime will carry a Purchase Order's quantities and rates through a Receipt Note and into a Purchase Voucher automatically, and it will tell you, in a report, which orders and which receipts are still open. What it won't do is decide what a mismatched line means, or chase down a receipt that's been sitting unbilled for three months. That part is still a person's job.

What the three-way match actually is in TallyPrime

A Purchase Order records what you agreed to buy. A Receipt Note records what actually arrived at your dock. A Purchase Voucher records what you're being billed for. Three-way matching is simply checking that all three agree — quantity, rate and item — before you treat an invoice as settled. Tally's documentation doesn't use that term, but the linking is built into the same voucher chain (TallyPrime help documentation as of May 2026).

Per TallyPrime's own documentation, a Purchase Order "controls the purchasing of products and services from external suppliers" and you "can record a Purchase Order in TallyPrime to raise such demand indicating the types, quantities, and agreed prices" for products or services. You create one via Alt+G (Go To) > Create Voucher > F10 (Other Vouchers) > Purchase Order, pick the supplier, enter the order number in Party Details, then the due date and quantity for each stock item — the rate auto-fills if one is already available for the stock item, and you can still change it. (The order number only moves into the Stock Item Allocations screen, per item, if you switch on the F12 option "Provide Order No. for each Stock Item.") Once goods arrive, TallyPrime's documentation is explicit that "you can record a Receipt Note in TallyPrime to account for the goods received and against the existing Purchase Order as well" — you select the order number on the Receipt Note to pull the order's line items across, and from that point the receipt can be traced by its reference number both in the eventual Purchase Voucher and against the original Purchase Order. When you finally record the Purchase Voucher, "the details from the receipt note... will reflect in the purchase voucher" and both "Tracking No.: and Order No.: will be auto-filled by default based on the receipt note and order number reference."

That's the mechanism: the Order No. threads the PO through to the Receipt Note, and the Tracking No. threads the Receipt Note through to the Purchase Voucher. TallyPrime supports two sequences — Order > Receipt Note > Purchase for businesses that book goods in before the bill arrives, and a shorter Order > Purchase flow that skips the Receipt Note step entirely for suppliers where a separate GRN adds no value (a services-only vendor, say, or one where the invoice always arrives with the delivery).

The two reports, and what each one is actually telling you

TallyPrime doesn't run three-way matching as a single reconciliation screen the way it does for GSTR-2B — it splits the "what's still open" view across two separate reports, one per stage of the chain, and each answers a different question. The second of the two has a prerequisite: Tally's documentation states, verbatim, that "the Purchase Bills Pending report can be generated only when the option Tracking Numbers is set to Yes" — without it, the Order No./Tracking No. linkage that report relies on doesn't exist.

Read together, the two reports cover the whole chain from both ends: PO Outstanding tells you what's still on order and hasn't physically arrived; Bills Pending tells you both what's arrived and hasn't been billed, and what's been billed and hasn't arrived. Neither report tells you why a line is stuck there, and neither one closes itself — a stale entry sits exactly where it landed until someone acts on it.

Handling a partial delivery: what Tally already covers

Partial deliveries against a single PO are a documented, ordinary case, not an edge case. TallyPrime tracks the running balance automatically — Ordered Quantity minus what's been received across however many Receipt Notes you've raised against that order — and if a supplier is delivering in tranches with different expected dates, Tally's page tells you to set a due date per lot where an order is split across dates. For a PO that will genuinely never be completed — a vendor who's stopped supplying a discontinued line, for instance — there's a pre-closure feature: enter a Pre-Close Quantity and a Reason for Pre-Close, and the balance drops out of the outstanding report instead of sitting there indefinitely. That's a deliberate, documented action, not a workaround.

When the invoice doesn't match the Receipt Note

Tally's Purchase Order and Receipt Note documentation doesn't set out a rule for what to do when the number on the invoice doesn't match the number on the Receipt Note. The following is our own reasoning from how the voucher chain works, not a documented Tally procedure, and it's worth checking against your own auditor's preference before you standardise on it.

The distinction that matters is whether the disagreement is a short delivery, a genuine rejection, or a value correction — and it's easy to conflate the first two:

• A short delivery — the supplier billed for 100 units but only 90 physically arrived — needs no return voucher at all. Nothing extra ever entered your stock, so there's nothing to send back: the Receipt Note should simply record the 90 units that were actually received, and the shortfall shows up as a quantity mismatch against the invoice, not as inventory that needs correcting.
• Goods received and then rejected — 10 units arrived, were inspected, and turned out to be damaged, so they're going back to the supplier — is the case Tally's Rejections Out voucher is built for: goods that did enter your stock and are now physically leaving it again. Tally's documentation is specific about where it sits in the sequence, too — a Rejections Out voucher "is recorded after raising a receipt note but before raising a purchase voucher," i.e. between the two, not bolted on after the invoice is already booked.
• A value correction — the goods received match the Receipt Note in full, but the invoiced rate is different from the PO rate (a price revision, a discount applied at billing, a rounding difference) — involves no stock movement at all. Creating a return voucher here would misstate your inventory to fix a billing figure. The correct place to reconcile it is the Purchase Voucher itself: Tally's documentation confirms you can still "change" the rate and adjust "the stock item's Quantity and Rate on the Stock Item Allocations screen, if required" at the point of billing, so the voucher reflects what you're actually being asked to pay.

When the sequence breaks: invoice first, or GRN with no invoice for months

Two out-of-sequence cases come up constantly in practice, and both turn out to be more directly documented by Tally than the voucher-chain mechanics above might suggest.

The bill arrives before the goods. Tally documents this case by name: "If you want to record a purchase invoice before a receipt note, you can record the invoice with a tracking number and track it in the receipt note." Practically, that means recording the Purchase Voucher first (against the PO, if you're using Tally's documented Order > Purchase flow), and selecting New Number for the Tracking No. on the Stock Item Allocations screen instead of linking to an existing Receipt Note — Tally's documented steps for recording a purchase with a new tracking number don't themselves reference a PO selection, so combining the two flows this way is our own synthesis of two separately-documented procedures, not a single documented one. The voucher posts the transaction against the party ledger "without updating the stock value," and — tying back to the Bills Pending report above — shows up there as a Bills Recd. but Goods not Recd. line. When the goods eventually arrive, you raise the Receipt Note and enter that same tracking number on it, which links the two vouchers and closes out the pending entry. What Tally's documentation doesn't prescribe is which document should govern quantity if the two later disagree — say the Receipt Note ends up recording 95 units against an invoice billed for 100 — and that's a policy worth deciding deliberately for your own team, rather than assuming Tally will resolve it for you. It will keep the partially-closed line on the Bills Pending report — Tally's documentation confirms "a receipt note is closed if billed completely. The details appear in the Purchase Bill Pending report if it is partially closed" — but it won't tell you which number is right.

The goods arrived months ago and the invoice never came. This is the mirror case, and it's covered by the same report from the other side: a Receipt Note with nothing billed against it shows up as a Goods Recd. but Bills not Recd. line on the Purchase Bills Pending report. The report lists the pending line; nothing in Tally's documented options escalates it or tells you the receipt is three months old rather than three days old unless you read the date yourself.

Actioning a stale line, since the report itself won't tell you why

Purchase Order Outstanding does age its lines: press F6 (Age wise) on the All Orders view for an age-wise analysis, and the drill-down shows the number of days overdue. It's also actionable in-report — Alt+W (Preclose Orders) lets you pre-close a dead order, partially or completely, straight from the Purchase Order (Due Only) report, without opening the original voucher. Purchase Bills Pending has no equivalent age-wise view in Tally's documentation. What neither report does is tell you why a line is stuck there, or which of several very different situations it represents: an invoice that's genuinely on its way and slow; one that will never arrive because the order was informally cancelled and nobody recorded a pre-closure; a Receipt Note that was entered against the wrong PO by mistake; or goods that were received, used, and then simply forgotten in the paperwork. Each of those needs a different fix, and ageing or a days-overdue figure doesn't tell you which one you're looking at.

At one supplier, that's a phone call. Working through a Bills Pending report that's flagging a goods-received line with no matching invoice three months later — across a purchase register with hundreds of vendors, some of whom this happens to routinely — and figuring out which of those four situations each stale line actually is, is painful to do manually at any real volume. It's also, notably, the same three-way match problem repeated at scale rather than a new one: the fix is still "read the PO, the Receipt Note and the invoice together and decide," just done hundreds of times a month instead of once.

A matched three-way still isn't the same as eligible ITC

It's worth being precise about what a clean PO/GRN/invoice match actually proves, because it's less than it sounds like. It proves your books are internally consistent — you ordered what you say you ordered, received what you say you received, and are being billed accordingly. It says nothing about whether the input tax credit sitting on that Purchase Voucher is actually available to you.

For an ordinary vendor purchase, that's a separate, statutory test (position as of September 2026): under Section 16(2)(aa) (text) of the CGST Act, read with Rule 36(4), credit isn't available at all unless the supplier has furnished that invoice in their own statement of outward supplies — GSTR-1 (as amended in GSTR-1A) or the IFF — and it's been communicated to you — which in practice means it has to show up in your GSTR-2B. A three-way match in Tally checks your side of the transaction. It has no visibility into whether the supplier ever filed. A perfectly matched Purchase Voucher, for an invoice the supplier hasn't reported, is still a credit that isn't legally yours to claim yet — a different problem entirely, and one no amount of PO/GRN/invoice matching inside Tally can see.

Related guides