Ledger scrutiny from a bank statement: a working method for finalisation

Why the bank statement anchors the scrutiny

At finalisation you are testing the books your client prepared against a record they did not: the bank statement issued by a third party. That independence is what gives it evidential weight under SA 505 for confirmations and SA 520 for analytical procedures, and it is why fraud-risk work under SA 240 so often starts here. The books can be shaped; the statement is what actually moved.

The difficulty is structural. A statement arrives date-wise, in strict chronological order, so a single counterparty who transacts forty times across the year is scattered across forty rows separated by hundreds of unrelated entries. The human eye cannot hold that shape. You can scroll a thousand-line statement and still miss that one party sent money out and took a near-equal sum back three days later, because the two rows are two hundred lines apart.

The move that unlocks everything is to convert the date-wise statement into a party-wise view. Group every debit and credit by counterparty so that each party collapses to a single line carrying total received, total paid, net position, transaction count, and first and last date. That one re-organisation is the whole craft. Once the account is arranged by who rather than by when, concentration, circularity, and threshold-gaming stop hiding in the timeline and start standing out on the page.

Building the party-wise view by hand

You do not need software to do this properly. You need a clean export and the discipline to normalise names before you pivot. The tedious part is step three, and it is also the part that decides whether the whole exercise is trustworthy.

1. Export the statement to Excel or CSV. Every bank encodes the counterparty differently: an HDFC UPI narration, an ICICI NEFT or IMPS reference string, and an SBI account download each bury the payer or payee name in their own layout, prefixes, and reference codes.
2. Parse the narration into a clean counterparty. Strip the channel tag (UPI, NEFT, IMPS, RTGS, ACH), the reference and UTR numbers, and the bank codes, and keep only the name or VPA of the person on the other side.
3. Normalise the name variants. RAJESH KUMAR, RAJESH K, and R KUMAR ENTERPRISES may all be one party; build a mapping so that a party is counted once, not three times. This is where most manual scrutiny silently goes wrong.
4. Roll the transactions up by normalised party: sum the credits, sum the debits, compute the net, and count the entries with first and last date. This is your party ledger.
5. Park what you cannot attribute honestly in a Suspense or Unknown bucket instead of forcing a name onto it, and quantify that bucket as a percentage of turnover. A large suspense is itself a finding, not a rounding error.
6. Sort the party ledger by gross throughput, credits plus debits, so the counterparties that actually carry the account rise to the top for review.

The five patterns a party-wise view exposes

With the account arranged party-wise, the patterns that matter at finalisation become almost self-announcing. Each of them is nearly invisible in a date-wise list and obvious once a party is one line with an in-total, an out-total, a net, and a frequency.

• Party concentration: a handful of counterparties accounting for a disproportionate share of turnover. This is legitimate for many businesses, but it drives related-party enquiry under AS 18 or Ind AS 24, targeted confirmations under SA 505, and a going-concern question if the account depends on one customer or supplier.
• Out-and-back loans: a sum paid to a party and a near-equal amount received back within a short window, typically director or related-party bridge funding. It is a related-party disclosure regardless of mode, and if any leg is in cash it engages sections 269SS and 269T.
• Round-tripping: funds that leave and return through one or more intermediaries to inflate turnover or dress up receivables and creditworthiness. In a party-wise view, a cluster of parties whose in-totals and out-totals match within a period is the signature you are looking for.
• Splitting or structuring: one economic payment or receipt broken into several sub-threshold amounts to the same party on the same or adjacent dates, engineered to stay under a statutory limit. High frequency combined with amounts sitting just below a round threshold is the tell, and it only reads as a pattern once the party is aggregated.
• Cash-law exposure: outsized ATM withdrawals, cash deposits, and self-transfers that fund off-book cash operations. The statement rarely shows the breach itself, but it points you precisely at the cash book you now need to test.

Cash-law exposure and the 3CD clauses it feeds

The cash provisions are the ones with teeth, because the penalties are not a percentage, they are the amount itself. Keep the four thresholds in front of you while you scrutinise.

Section 269SS bars accepting a loan, deposit, or specified sum of Rs 20,000 or more otherwise than by account-payee cheque, draft, or electronic mode, with a penalty under section 271D equal to the amount. Section 269T mirrors it on repayment, with a penalty under 271E. Section 269ST prohibits receiving Rs 2,00,000 or more in cash, whether in aggregate from a person in a day, in respect of a single transaction, or in respect of transactions relating to one event or occasion, and the penalty under section 271DA equals the amount received. Section 40A(3) disallows cash expenditure exceeding Rs 10,000 to a person in a day, with the limit raised to Rs 35,000 for payments to a goods carriage operator.

These are not abstract; they are line items you certify. Loans and deposits caught by 269SS and 269T, and receipts and payments caught by 269ST, are reported in clause 31 of Form 3CD, and the 40A(3) disallowance surfaces in clause 21(d). A pure cash 269ST receipt bypasses the bank by definition, so you will not see the breach on the statement. What the statement gives you is the behaviour around it: the cash withdrawals that feed the till and the deposits that follow sales, which is exactly the trail that sends you to test the cash book and the counterparty confirmations.

Tying the party ledger back to AIS and SFT

The scrutiny does not end at the statement, because you now have a third independent data point in the client's Annual Information Statement. Banks and other reporting entities file Statement of Financial Transaction returns for high-value activity, aggregated cash deposits and withdrawals among them, and those entries flow into the client's AIS and TIS.

Reconcile your party ledger against the AIS. The high-value transfers and cash lines you isolated should tie to the SFT entries the department already holds, and the interest income and TDS the bank reported should match the books. The value is in the mismatches: interest the client omitted, a high-value transaction absent from the ledger, a cash figure the client cannot explain. Each gap is a specific enquiry point rather than a general doubt, and clearing it before you sign is far cheaper than clearing it after a notice.

Doing this at scale without the drudgery

The method above is sound, and on one statement it is a productive afternoon. The problem is that name-cleaning and pivoting is the bottleneck, so in practice scrutiny gets done on a sample while the full population goes unread, which is precisely where the out-and-back leg and the split receipt survive to the next year.

This is where automating the mechanical part pays for itself. Greenote Lite takes an Excel or CSV bank statement, auto-detects the bank's narration format, and returns a four-sheet audit-ready workbook: a party-wise ledger with counterparties resolved across narration variants and the unattributable rows honestly in suspense, every transaction categorised and named, a category summary, and an ITR summary carrying AIS and SFT flags. The statement is processed in memory and deleted the moment the report is ready, so nothing is stored, which matters when the file is a client's. The first statement is free, there is no card and no sales call, and the point is simple: let the tool do the aggregation so your judgement goes to the exceptions it surfaces. If you review bank statements every finalisation season, run one client's statement through it and compare the party ledger against the one you would have built by hand.