Stop posting everything to Suspense: mapping bank statements to Tally ledgers

Ask any article assistant what takes longest about a bank statement and they will not say “converting the PDF”. They will say the part afterwards: three hundred rows, each one needing a ledger head, most of them the same twenty payees repeating.

The Suspense A/c problem

Nearly every PDF-to-Tally converter produces a valid XML that imports cleanly and is almost useless. The reason is in the voucher structure. A Tally payment voucher needs two ledger entries — the bank account, and the other side. Converters know the bank account. They do not know the other side, so they write Suspense A/c and move on.

The file imports. Every transaction is now sitting in suspense, and someone has to reassign them by hand inside Tally, which is slower than typing them would have been.

How narration mapping works

The narration your bank already printed carries the answer most of the time. A row reading UPIAR/321216098504/DR/SURYA TU/PYTM/zomato is a food delivery payment. It says so. The work is matching that text against a table of rules and posting to whatever ledger the rule names.

The rules are ordered, and order decides ties. That sounds like a detail until you meet a salary credit: it arrives by NEFT, so a generic “NEFT means bank transfer” rule will claim it unless the salary rule is checked first. Every mapping table needs its specific rules above its general ones.

Why direction changes the ledger

The same word means different things depending on which way the money moved. Interest on a credit is income; interest on a debit is a cost. A rule that only looks at text will post both to one ledger and put half of them on the wrong side of the books.

Any mapping worth using lets a rule say “this applies to payments only” or “receipts only”. Interest, refunds and reversals all need it.

Building your firm’s mapping file

No two firms name their ledgers identically. One firm’s Staff Welfare is another’s Client Entertainment, and a default list will always be a starting point rather than an answer.

A mapping file is two columns — the text to look for, and the ledger to post it to:

match,ledger
ZOMATO,Client Entertainment
SWIGGY,Client Entertainment
RENT PAID,Rent
AWS,Software Subscriptions
ZERODHA,Investments

Build it from your own trial balance rather than inventing it: export your ledger list, take the twenty heads you actually use, and write the payee names you recognise against them. Twenty rules will cover most of a typical statement, because most transactions are the same handful of payees repeating.

What to do with unmatched rows

Some rows will not match anything, and they should not be guessed at. A blank you fill in yourself costs a few seconds. A confident wrong posting costs far more, because you have to notice it first — and a plausible-looking ledger on the wrong row is exactly what nobody notices.

Leave unmatched rows in suspense deliberately, then look at what keeps appearing there. Those are your next five mapping rules, and after two or three months the unmatched list is usually short enough to clear by hand in under a minute.

Why this does not need AI

Categorisation is the kind of problem that invites a model and does not need one. The narration is already structured text and the mapping is already a decision your firm has made. A table of rules gives you three things a model cannot: it is explainable (you can point at the rule that decided a posting), repeatable (the same statement categorises the same way every time), and it involves no third party — which for a CA handling clients’ financial data is not a nice-to-have.

It is also faster. Rule matching over three hundred rows completes in milliseconds, inside the same request that read the PDF.

BankXL assigns ledgers this way on every conversion, including the free tier. See how auto-ledger works, or read our guide to importing bank statements into Tally Prime. Questions: support@banlxlai.com.