Zoho Books will auto-categorise your bank feed for you. One rule pattern quietly breaks your ITC evidence chain

Transaction rules are the highest-leverage automation Zoho Books offers an Indian finance team — a handful of rules can clear most of a bank feed without a human touching it. But the same mechanism that saves hours on bank charges and interest can, applied to vendor payments, quietly delete the one piece of evidence Rule 37 needs. This is the setup, five recipes worth building, and the one you shouldn't.

What a transaction rule actually does

Paths and options below are as of August 2026, Zoho Books India edition — Zoho ships banking changes without much notice, so treat the menu path as the current one, not a permanent one.

In Zoho Books, go to Banking, open the account you want to automate, click the gear icon next to Import Statement, and choose Manage Transaction Rules > New Rule. Name the rule, then choose whether it applies to Deposits or Withdrawals — a rule is always one-directional, never both. Add one or more conditions, matched on Payee, Description or Reference Number (operators: is, contains, starts with, is empty) or on Amount (equals, greater than, greater than or equal, less than, less than or equal), and decide whether all or any one of them must match. Save the rule and it applies immediately to every uncategorized transaction already sitting in that account — not just future ones — and to everything that lands afterwards. Editing an existing rule re-runs it the same way. This matters more than it sounds: a broad rule is dangerous retroactively, not just prospectively — it can sweep a backlog you were deliberately holding in Uncategorized Transactions for matching, not just miscategorise what arrives next.

The part worth reading twice is what a rule can record a transaction as. For deposits, the options include a sale without an invoice, a fund transfer, interest income, other income, or an expense refund. For withdrawals, they include an expense, a fund transfer, a card payment, or an owner's drawing. Whatever the full list runs to, notice what's absent from the withdrawal side: none of them is a match to a Bill. A rule can post a withdrawal straight to an expense account. It cannot mark a specific vendor Bill as paid. Only the Match action in Uncategorized Transactions — Zoho proposes a best match, and a human, or Recoup, confirms which open Bill a payment settles — does that. That single gap is the reason this article exists, and it is the reason the retroactive-sweep behaviour above is dangerous: a rule saved today can silently close out backlog Bill-matches you hadn't gotten to yet.

Five rules worth building

The traffic below is genuinely one-sided — nobody needs to know which invoice a bank charge "paid", because it didn't pay one. This is where rules earn their keep.

Two of these need a caveat. Zoho Books doesn't publish a fixed set of Indian bank narration codes, so the exact strings in the "Description contains" condition have to come off a real statement — pull a month of transactions first, read what your specific bank actually writes, and build the rule against that text, not a guess. And the UPI rule is intentionally the narrowest one on the table: it exists for businesses that genuinely take walk-in UPI payments with no invoice behind them. If your UPI receipts are customers paying invoices you raised, route them to matching instead, covered next.

The rule you should not write

The tempting version of automation is a rule like "Description contains [a regular vendor's name] > categorise as [expense head]" for a supplier you pay every month. It works, in the narrow sense that the transaction stops sitting in Uncategorized Transactions. It also means that payment is now an expense-account posting with no link to any Bill — the underlying invoice, if you'd already recorded one, stays open and unpaid in Zoho, or you close it separately and now carry a duplicate. And because a rule applies retroactively on save (above), writing it doesn't just miscategorise next month's payment to that vendor — it can immediately sweep every one of that vendor's past payments still sitting in Uncategorized Transactions, the moment you save the rule.

The fix isn't "never automate vendor payments" — it's drawing the line at the right traffic. Keep transaction rules for the genuinely one-sided items in the table above. Leave every line that could plausibly be a Bill payment — anything matching a known vendor's name or a recurring payment pattern — in Uncategorized Transactions, and close it with Match, not a rule. Match is slower per line — Zoho proposes a best match and you confirm it — but it's the only action that records which Bill a payment settled, at the bank's own value date.

UPI, income-tax TDS and GST TDS: why "amount equals invoice" rules misfire

A rule conditioned on Amount equals the invoice value looks precise and is often wrong, because two very different deductions can shrink what actually lands in your account — and they are not the same thing, though bank narrations rarely distinguish them.

• Income-tax TDS, deducted by many B2B customers under the Income Tax Act before they pay you for services, is common on ordinary invoices and has nothing to do with GST — it reduces the cash you receive, not the GST you're owed.
• GST TDS under Section 51 of the CGST Act is different, narrower and easy to conflate with the first: it applies where a deductor under Section 51(1) pays you — departments and establishments of the Central or State Government, local authorities and Governmental agencies are deductors under clauses (a) to (c) directly, while clause (d) delegates the rest to notification: bodies set up by an Act of Parliament or a State Legislature, entities established by any Government with 51% or more equity or control, Government-established societies and public sector undertakings (all notified by Notification 50/2018-CT dated 13 September 2018, which also commenced Section 51 w.e.f. 1 October 2018), and, since 10 October 2024, a registered person receiving metal scrap of Chapters 72 to 81 from another registered person (Notification 25/2024-CT dated 9 October 2024) — under a contract whose taxable value exceeds ₹2.5 lakh, deducting 2% (1% CGST + 1% SGST, or 2% IGST on inter-State supplies). The proviso to Section 51(1) switches this off where the supplier's location and the place of supply are both in the same State or UT as each other but different from the deductor's State of registration — in that situation no GST TDS is deducted at all. The deductor reports it in their monthly GSTR-7. Crucially, that deducted amount does not land in your bank feed at all, and it does not credit your electronic cash ledger automatically either — you have to accept the auto-populated entry and file the TDS/TCS Credit Received statement yourself before it becomes usable cash-ledger balance.

For an ordinary B2B customer, build the UPI/NEFT receipt rule on Description contains the customer's name or UTR pattern, not on an exact amount — and route it to Uncategorized Transactions for matching against the specific invoice rather than auto-posting as income, so the shortfall (whichever TDS caused it) gets reconciled against the right invoice instead of silently treated as a discount. For a notified GST TDS deductor specifically, treat the net receipt and the GSTR-7 credit as two separate reconciliation items — the bank rule only ever handles the first one.

GST challan payments: a transfer, not an expense

A GST liability payment made via challan shows up in your feed as an outgoing transaction, usually against a narration referencing the GST portal or your CPIN. It's tempting to write a rule that files this straight to a "GST Expense" or "Tax Paid" head. Better practice is to treat it as a transfer to whatever control account you use to track your electronic cash and credit ledgers, because a GST payment isn't an expense in the accounting sense — it's settling a liability already recognised when the supply was recorded, not a fresh cost. Zoho lists banking-type accounts — Bank, Credit Card and Cash — as Fund Transfer destinations; its own guidance for moving money from a bank to a liability account is to record an Expense against that liability account rather than a transfer. So create the control account under Banking as a Bank- or Cash-type account first. Once that account exists, keep the rule narrow: Description contains your specific GST-payment narration, direction Withdrawal, recorded as Fund Transfer — and reconcile that control account against your actual electronic ledgers separately, the same way you'd reconcile any clearing account.

Categorised is not reconciled

Every rule above, run correctly, gets you to a feed with almost nothing sitting in Uncategorized Transactions. That is a genuinely useful state — and it is not the same as a reconciled one. A transaction a rule filed to "Bank Charges" is done; a transaction a rule filed to "Expense" because it matched a vendor's narration is not done, it's just hidden. It still can't tell you which vendor invoice it actually paid, whether that invoice is now closed for Rule 37 purposes, or whether the vendor even filed the GSTR-1 your credit depends on under Section 16(2)(aa) read with Rule 36(4)(b). Getting from a clean feed to an answer on those questions is GST reconciliation proper, and doing it invoice by invoice across a real vendor list every month is painful to do manually — a rule can clear a feed in seconds; nothing in Zoho Books' rule engine can tell you, at the end of that, which of your open Bills are still exposed.

A five-minute monthly check on your rule set

1. Open Manage Transaction Rules and read the list. Rules accumulate. One added in a hurry six months ago, matching a vendor's name that has since become a recurring monthly payment, is the exact failure mode above.
2. Check Uncategorized Transactions isn't emptying itself of vendor payments. If a vendor name that used to show up there every month has quietly stopped appearing, a rule is probably auto-categorising it now — and because rules apply retroactively on save, that sweep could have happened all at once, not gradually, the day the rule was added or edited.
3. Spot-check five paid Bills against the bank line that closed them. If a Bill's payment was actually made via a rule-categorised expense line rather than a Match, the link doesn't exist and you've found the gap before an auditor does.

What Recoup does with the feed once the rules are set

Recoup works with Zoho Books and matches each bank payment to the specific Bill it settled — the step a transaction rule is structurally unable to do — so vendor payments stay linked to an invoice even while your bank charges, interest and transfers run on autopilot. It ages every unpaid Bill against its Rule 37 180-day payment deadline, off the matched payment date where one exists (the reversal itself falls due in the GSTR-3B for the tax period immediately following the 180-day period) — other than reverse-charge supplies and Schedule I supplies made without consideration, which the 180-day rule does not reach — and separately reconciles your Zoho Books ITC against your GSTR-2B, naming the vendor behind any gap. Rules handle the traffic that doesn't need a story attached. Recoup handles the traffic that does.

Related guides