How-to · Zoho Books & purchasing

Zoho Books can match a bill to its PO automatically. Nobody explains what happens next

The short answer

Zoho Books matches a bill to its purchase order two ways — manually, by entering the PO number on the bill or picking it from Open Purchase Orders, or automatically, through the paid BillPay add-on's scanned-document matching, which needs a separate "Bill Reconciliation" setting turned on first. Either way, a matched PO only confirms the bill against your own order. It says nothing about whether that invoice sits in your GSTR-2B.

Search "Zoho Books purchase order matching" and you get Zoho's own two-paragraph help page and a handful of reseller listicles — nothing that walks an Indian AP team through the actual setup, what to do when a line refuses to match, or the question the PO screen never answers at all. This is that walkthrough.

Two things Zoho Books both call "matching a PO to a bill"

Search Zoho's own documentation and you'll find two genuinely different features that both get described as PO matching, and the paperwork trail for each is different enough that conflating them is the first mistake most teams make.

The first is manual linking, available in every Zoho Books plan. You either type the purchase order number into the Order Number field on a bill you've already created, or — while creating the bill in the first place — Zoho shows an Open Purchase Orders option under the item details for that vendor, documented on Zoho's Bills basics help page; select the PO(s) and click Add, and the line items pull in from the order. For bills you've already created in bulk, a Link to existing Purchase Orders button on the Bills list does the same lookup across multiple records at once — see Zoho's own Link Purchase Orders to Bills help page (which documents the Order Number field and the bulk-link button, not the item-details picker above). None of this checks that the quantities or rates agree — it's a reference link, not a control.

The second is automated matching, and it's a paid add-on called BillPay. This is the feature people actually mean when they ask about "PO matching" in Zoho Books, and it's also the one with a setup step nobody puts on the bill screen.

The setup step that isn't on the Bills screen

BillPay's PO matching needs two things to be true before you ever touch a bill. First, you need to have purchased the BillPay add-on — that's a subscription purchase, made from your organization's subscription/add-ons settings. Second, you need to have enabled Bill Reconciliation as a separate setting, which — per Zoho's own Bill Reconciliation help page — lives under Settings → Bills (under Purchases) → the General tab, not inside Purchases → Bills where you'd naturally go looking for "the matching feature." Turning the toggle on forces a choice most organizations make once at setup and never revisit: 2-Way Matching, which checks the bill's line items against the PO's line items only, or 3-Way Matching, which additionally checks the bill's line items against the purchase-receive items — what you actually recorded as received against that PO. Pick a method and click Save. That choice matters more than the setup screen suggests: Zoho's documentation doesn't describe any indicator of the active matching mode outside Settings — an org set to 2-Way Matching has silently opted out of the one check that verifies goods or services were received at all.

Because Zoho also renames and relocates settings between releases without much notice, the reliable way to confirm your account's current setup is to check Settings → Bills → General directly rather than trust a screenshot from an older help article, including this one.

Once both are on, here's what the automated match actually does, per Zoho's own documentation for the add-on:

  1. Go to Purchases → Bills → Uploaded Documents and upload or drag in the vendor's bill (PDF or image). Its status shows as Processed once Zoho has scanned it.
  2. Click Convert to Bill on the processed document.
  3. Zoho fetches the purchase order, ordered quantity and rate per item straight from the scanned bill and matches each line against the corresponding open PO, showing the result in an Order Details column.
  4. Review the matched details, fill in anything still missing, and click Save as Draft — the bill is created and the PO link is recorded at the same time.

That's a real automation: nobody re-typed a PO number, a quantity or a rate to get there. It's also the exact point where teams get stuck, because the documentation stops at "it matches" and says almost nothing about what to do when it doesn't.

When a line comes back "Mark as Non-PO Item" and you think it shouldn't have

Zoho's documentation is explicit about the escape hatch: "if the scanned details of any line item do not match with the corresponding purchase order," you can click Mark as Non-PO Item next to that line and the bill posts anyway, just without the PO link on that item. What it doesn't cover anywhere is what to check before you reach for that button on a line that should have matched.

Before accepting the mismatch, four things are worth ruling out first, in roughly the order they're cheapest to check:

  • The PO is already closed or fully billed. A purchase order that's been fully invoiced against once won't offer itself as an open match for a second bill against the same line — check the PO's own status before assuming the matching logic is wrong.
  • The scanned rate or quantity is an OCR misread, not a real discrepancy. Automated document scanning misreads a decimal point or a leading digit often enough that it's worth opening the uploaded file side by side with the matched fields before treating a rate mismatch as genuine.
  • It's the wrong PO number entirely. A vendor who supplies you against several concurrent purchase orders can put the wrong one on their invoice; the mismatch is on their side, not a Zoho matching failure.
  • The PO and the bill are for different vendors in Zoho's records even though they're the same real-world supplier — a duplicate vendor record from an old import will fail every match silently.

If none of those explains it, the mismatch is real and marking the line Non-PO is the correct call — but log a reason at that point rather than clicking through, because the same silent duplicate-vendor or wrong-PO pattern tends to recur across a whole month's bills from the same supplier, not just once.

Don't have BillPay? The manual match still needs a decision

If PO matching for your organization means the manual route — typing the Order Number field or using the Open Purchase Orders picker — the discipline that replaces Zoho's automated check is entirely yours to enforce. Nothing stops a bill from saving with the wrong PO number typed into it, or with no PO reference at all, whether or not one exists. That's the practical difference worth being honest about: a manually re-typed PO number that's wrong still lets the bill save and post exactly as if it were right, while a BillPay-matched bill with a genuine mismatch surfaces the discrepancy in the Order Details column and requires an explicit Mark as Non-PO Item decision on that line. Zoho's documentation for the add-on doesn't describe that as a save-blocking gate — it's an option offered on the line, not a hard stop. But it isn't a single quiet flag either: per Zoho's Bill Reconciliation help page, a mismatched or PO-less bill is flagged on the Bills List page and filterable there via All Bills → Violated Bills; the bill's own Details page carries a reasons banner and a View Item Details breakdown; and the warning resurfaces again on the Record Payment page before you pay it. None of that blocks the save, but it puts the mismatch in front of someone repeatedly, which the manual route never does. The manual route is available to every plan; the visibility is not.

What a matched PO still hasn't told you

Get either version of PO matching working perfectly and you've answered one question well: does this bill agree with what you ordered, at the rate and quantity you agreed to. That's real accounts-payable hygiene, and it's worth having regardless of company size.

It has not answered a second, separate question: is the input tax credit sitting on that bill actually yours to claim. Under Section 16(2)(aa) of the CGST Act, credit becomes available only once the supplier has furnished that invoice and it has been communicated to you "in the manner specified under section 37" — and it's Rule 36(4)(b) of the CGST Rules that specifies that communication happens via GSTR-2B under Rule 60(7). A PO number, a matched quantity and a matched rate say nothing about whether the supplier has filed anything at all. GSTR-2B itself isn't a fixed snapshot you check once, either: a draft appears on the 14th of the following month, and your IMS actions — or inaction, which counts as acceptance — can still change what it contains right up until you file GSTR-3B (as of September 2026 — this rests on current GSTN portal behaviour, not on Rule 60 itself, and GSTN has changed that behaviour by advisory before, without much notice).

Two matches, not one — and Zoho's receiving check is opt-in. A three-way match, in the classic accounts-payable sense, reconciles the purchase order, the goods or service actually received, and the vendor's invoice. Zoho Books does ship that third, receiving leg: it's the 3-Way Matching option inside Bill Reconciliation, which checks bill items against purchase-receive items, not just against the PO. But it's gated behind a method choice most organizations set once at BillPay setup and never look at again — an org set to 2-Way Matching has silently opted out of the goods-receipt check, without anyone necessarily deciding that on purpose. Even a genuine 3-way match still hasn't answered a fourth, separate question that matters for Indian GST purposes: whether the invoice behind that PO is in your GSTR-2B at all. That's a completely separate reconciliation, against a completely separate government record — see the next section for where Zoho actually runs it.

Where that second reconciliation actually happens

Zoho Books isn't blind to this leg either. Under GST Filing, select the filing month, open View Summary, and the GSTR-2B section has a Fetch Summary action — see Zoho's GSTR-2B reconciliation help page — that pulls the statement from the GST portal and buckets each record as Missing in GSTN, Missing in Zoho Books, Partially Matched, Matched, or Reconciled.

Two things that screen doesn't do are worth knowing before you lean on it. First, it's a fetch you trigger per filing month against a statement that keeps recomputing — as noted above, a Fetch Summary run on the 15th and one run on the 28th can legitimately disagree, because IMS actions taken in between change what's in 2B. That cadence isn't universal either — a QRMP taxpayer gets no GSTR-2B for the first two months of a quarter, only for the last, so a Fetch Summary run mid-quarter will simply error. Zoho documents a Regenerate button for exactly this — but on that same GSTR-2B reconciliation page, not on the IMS Dashboard: GST Filing → View Returns → GSTR-2B → View Summary → Regenerate, top right. Zoho's own wording is that when IMS records change after the 14th "it is necessary to regenerate GSTR-2B," and that there is no restriction on how many times it can be recomputed before you file GSTR-3B for that period — so the recompute is something you can re-run, not something you're stuck living with. Second, the bucket labels on this Fetch Summary screen describe whether a record is present, not why. A record you rejected — or left Pending — in IMS drops out of GSTR-2B entirely, so it does not appear as a 2B line at all — if you have booked the bill, it shows up as Missing in GSTN, indistinguishable on that screen from a supplier who simply never filed. One needs your IMS decision reversed; the other needs the supplier chased. Zoho does give you a place to see the IMS decision itself: GST Filing → View Returns → IMS Dashboard tracks Accept, Reject and Pending, with its own Matched / Partially Matched / Missing in Zoho Books buckets and a Push to GSTN tab. But it's a separate screen from the Fetch Summary above, and Zoho's documentation describes no view that joins the two — none that carries an IMS decision on a record through to its downstream effect on a specific purchase-register invoice — so on the documented screens, telling a rejected record apart from a never-filed one means holding both open rather than reading one. Both screens, in other words, are actions you have to remember to re-run rather than a permanent state either one shows you on its own.

A bill that fails PO matching in Zoho surfaces that in the Order Details column and asks for a Non-PO decision before you move past it. A bill whose underlying invoice never turns up in your GSTR-2B does no such thing on its own — it posts, it sits in your purchase register looking completely normal, and the only way to know it's a problem is a Fetch Summary run, or a line-by-line check against that month's 2B. Doing that at the cadence real bill volume needs, rather than once at month-end, is painful to do manually — which is where Recoup fits: it reconciles your purchase register against GSTR-2B continuously and names the specific invoice, supplier and IMS state behind any gap, PO-matched or not.

What to do when the supplier behind a PO-matched bill hasn't filed GSTR-1 and the full mechanics of GST reconciliation beyond the PO leg alone both go further into that second match than this guide does — this one stops at getting the bill itself right.

The PO matched. That doesn't mean the credit is safe.

Recoup reconciles your purchase register against GSTR-2B continuously and names the vendor behind every gap — before you file, not after.

Book a demo →

Related guides