Reading Cash-Law Risk (269SS, 269T, 269ST) Off a Bank Statement

What each section actually penalises (and what it does not)

The three sections are often lumped together as "the cash sections," but they cover different acts and, importantly, catch different parties. Read them as a set of three distinct events on a single flow of money.

Section 269SS governs acceptance. A person must not accept a loan, a deposit, or a specified sum (an advance in relation to transfer of immovable property, whether or not the transfer goes through) of Rs 20,000 or more otherwise than by account payee cheque, account payee bank draft, or a prescribed electronic mode. The aggregation is per person and per outstanding balance, so small tranches that build a balance of Rs 20,000 or more are caught. The penalty under Section 271D equals the amount accepted.

Section 269T governs repayment. The same Rs 20,000 threshold and the same permitted modes apply, but here to the repayment of a loan, deposit or specified advance. The penalty under Section 271E equals the amount repaid. So a genuine loan can attract a penalty on the way in under 269SS, and a second penalty on the way out under 269T, if either leg was in cash.

Section 269ST is different in kind. It is a general ceiling on cash receipts, not confined to loans or deposits. No person may receive Rs 2,00,000 or more otherwise than by the permitted modes: (a) in aggregate from one person in a day, (b) in respect of a single transaction, or (c) in respect of transactions relating to one event or occasion from a person. The penalty under Section 271DA equals the amount received. Note the direction: 269ST penalises the receiver, not the payer.

Two points are easy to get wrong and worth fixing in your own head before you touch the statement. First, genuineness is not a defence to mode. The Assessing Officer can still consider reasonable cause under Section 273B for 271D and 271E, and 271DA has its own proviso for good and sufficient reasons, but the starting position is that the wrong mode attracts the penalty. Second, the permitted electronic modes are wider than cheque and draft: Rule 6ABBA notifies net banking, IMPS, UPI, RTGS, NEFT, debit and credit card, and BHIM Aadhaar Pay. Anything moving through those channels is compliant on mode.

• 269SS: acceptance of loan/deposit/specified sum, Rs 20,000 or more, wrong mode. Penalty 271D = amount accepted.
• 269T: repayment of loan/deposit/specified advance, Rs 20,000 or more, wrong mode. Penalty 271E = amount repaid.
• 269ST: receipt of Rs 2,00,000 or more (per person per day / single transaction / one event), wrong mode. Penalty 271DA = amount received, levied on the receiver.
• Permitted modes for all three: account payee cheque, account payee draft, or a Rule 6ABBA electronic mode.

What a bank statement can prove, and what it cannot

This is where most reviews go wrong, so be strict about it. A bank statement is a record of your client's side of transactions, and only the banking leg of each one. It can establish that cash physically entered or left the account, on what date and in what amount. It cannot, by itself, establish the nature of the underlying transaction or the identity of the other party to a cash movement.

Start with what the statement rules out. Every NEFT, RTGS, IMPS, UPI or card entry is, by definition, a prescribed electronic mode. A loan received by NEFT does not attract 269SS. A loan repaid by RTGS does not attract 269T. A sale receipt of any size collected by UPI does not attract 269ST. So on the statement, the only rows that can themselves evidence a breach are the cash legs: cash deposits and cash withdrawals, and the rare bearer or non-account-payee instrument. The transfer rows matter as context, for tracing and for building a structuring narrative, but they are not violations of these three sections regardless of amount.

Now the harder point. A cash deposit into your client's own account is not, in law, the moment of receipt for 269ST. It is your client banking cash they already hold. If that cash was the day's till takings from three hundred customers, no single receipt may have touched Rs 2,00,000, and there is no 269ST issue at all. If it was a single Rs 2,50,000 cash payment from one buyer, there is a clear 269ST issue, and your client, the receiver, is exposed. The deposit looks identical in the statement in both cases. The statement flags that a cash receipt occurred; the cash book and party ledger prove what it was.

Cash withdrawals are even more one-sided. The statement shows your client taking their own money out. What they did with it, paid a supplier, repaid a lender, is invisible in the banking record. A cash loan repayment (269T) or a cash payment that makes the counterparty the receiver under 269ST both live in that second, unseen leg. This asymmetry, that a cash payment out of the account often creates a 269ST exposure for the person receiving it rather than for your client, is exactly the kind of thing a bank statement cannot show and a working paper must spell out.

Treat the statement, then, as a flagging instrument, not a proof instrument. It tells you where to look. It rarely closes the question on its own.

The patterns that flag it

Working from that discipline, a small number of patterns reliably deserve a second look. Isolate the cash legs first, then scan for these shapes.

Large single cash deposits or withdrawals near or above the thresholds are the obvious ones: a Rs 2,00,000-plus cash deposit is a direct 269ST prompt, and any sizeable cash movement tied to a loan account is a 269SS or 269T prompt. Aggregation matters as much as any single figure, so total the cash deposits from the same source on the same day before you clear anything.

Splitting below thresholds is the pattern people most often misjudge. Several cash deposits of Rs 18,000, or of Rs 1,90,000, appearing close together is a classic marker of an attempt to stay under Rs 20,000 or Rs 2,00,000. Be precise about what splitting does and does not achieve, because a senior reviewer will test you on it. Structuring only helps where the limit is a per-day aggregate; it does nothing against the single-transaction and one-event limbs of 269ST. Chopping a Rs 5,00,000 sale into daily cash chunks does not escape 269ST if it is one transaction or one event. And note that splitting is only relevant to the cash rows: breaking a banking-channel transfer into small pieces is irrelevant to all three sections, since the mode is compliant either way.

Out-and-back party flows are the last shape worth naming: money paid to a party and returning shortly after, a "loan" received by transfer and repaid in cash, or cash withdrawn and a matching credit reappearing from a related name. These round trips rarely resolve at the bank statement alone. They point you to genuineness questions (and to Section 68 on unexplained cash credits) as much as to cash-law, and they are the flows most worth reconciling against confirmations and agreements.

All of this depends on being able to see one counterparty as one counterparty. The same lender can appear as a full name, initials, a UPI handle and a truncated NEFT narration across a single year, and cash deposits often carry no counterparty at all. Narration formats differ by bank, so the same economic event reads differently on an HDFC, an ICICI or an SBI statement, which is precisely why manual rollups miss aggregation. Resolving those variants into one party line, and pushing the genuinely unattributable cash into an honest suspense head rather than guessing, is the tedious core of the exercise; a tool like Greenote automates that party-wise rollup so the aggregation is done for you.

• Large single cash deposits (269ST) or cash movements on loan accounts (269SS/269T).
• Same-day aggregation of multiple cash deposits from one source.
• Amounts parked just below Rs 20,000 or Rs 2,00,000 (structuring), keeping the 269ST single-transaction and one-event limbs in mind.
• Out-and-back flows and mixed-mode loans (received by transfer, repaid in cash, or the reverse).
• Counterparty names that fragment across narration variants and need resolving before you total anything.

Testing the 269ST limbs by hand

When a cash receipt surfaces, run it through all three 269ST limbs rather than only the day aggregate, because the other two are where structuring is defeated.

Take an illustration. A client's statement shows three cash deposits of Rs 80,000 on the same day, all traced in the cash book to one buyer against one invoice. The per-day aggregate from that person is Rs 2,40,000, so limb (a) is breached. Even if those three deposits had fallen on three different days, limb (b) would still bite, because it is a single transaction of Rs 2,40,000. And if the invoice related to one wedding or one order fulfilled over a fortnight, limb (c) would catch it as one event. The only genuine escape is genuinely separate transactions, each under Rs 2,00,000, from the same person on different days, with nothing tying them into one transaction or occasion.

For 269SS and 269T, the test is per person and per running balance. Total every cash tranche that built a lender's balance to Rs 20,000 or more, and check the mode of every acceptance leg and every repayment leg separately. A loan received by NEFT but repaid Rs 25,000 in cash is clean on 269SS and exposed on 269T. Do not let a compliant inward leg lull you on the outward one.

Keep one adjacent section in view while you are in the cash legs, even though it sits outside this trio: Section 40A(3) disallows business cash payments exceeding Rs 10,000 to a person in a day (Rs 35,000 for plying, hiring or leasing goods carriages). A cash withdrawal followed by a cash supplier payment is a 40A(3) question, not a 269 one, but it lives in the same rows and a thorough review notes it.

Documenting it: working papers and Form 3CD

The output of the exercise is a working paper that ties each flagged row to a conclusion. Build it as a schedule with, at minimum: date, amount, mode, counterparty, the nature of the underlying transaction, the section potentially attracted, the corroborating document you relied on, and your conclusion. The corroboration is the part that turns a flag into a finding: a loan confirmation, the cash book folio, a sale invoice, a sale agreement for a property advance. Where you could not attribute a cash deposit at all, say so in the paper and keep it under a labelled suspense line rather than forcing a counterparty. An honest "unresolved" is more defensible than a wrong attribution.

The reporting home for the conclusions is clause 31 of Form 3CD, which now carries separate sub-clauses for loans and deposits accepted (269SS), specified advances, repayments (269T), and receipts and payments hit by 269ST. Remember your role at this point: the tax auditor reports the particulars, the Assessing Officer levies the penalty under 271D, 271E or 271DA, and the assessee may plead reasonable cause under Section 273B (or good and sufficient reasons under the 271DA proviso). Your job is complete, defensible disclosure, not adjudication, and your working paper should read as though it will be handed to someone testing that disclosure.

A practical caution on scope. Clause 31 asks for particulars "during the previous year," which includes transactions that never touched the bank at all, cash loans settled in cash between two people, for instance. The bank statement is your best structured lead, but it is not the boundary of the clause. Cross-check against the ledgers and the cash book so the 3CD particulars are complete, not merely bank-derived.

Doing this on every audit, at scale

Worked by hand, this method is sound and completely tool-independent: isolate the cash legs, resolve counterparties, aggregate per person and per day, test the three 269ST limbs and both loan legs, corroborate, and write it up against clause 31. On a thin statement it takes an hour. On a trading client with hundreds of cash deposits and a dozen narration variants per lender, the aggregation alone eats an afternoon, and that is where genuine breaches slip through, not because the CA missed the law but because the totalling was manual.

That mechanical middle is what Greenote is built to remove. Feed it the client's Excel or CSV bank statement and it returns an audit-ready workbook: a party-wise ledger that resolves narration variants into one line per counterparty, every transaction categorised and named, a category summary, and an ITR summary with AIS and SFT flags, so the cash legs and per-party aggregates you need for a 269 review are already totalled. It reads Excel and CSV, not PDF; for PDF statements the separate Greenote Desktop app converts and exports first. The judgement stays yours, but the counting is done. The statement is processed in memory and deleted the moment the report is ready, which matters when the file is a client's confidential bank data.

If you want to see whether it saves you the afternoon, the first statement is free for the first block of transactions, with no card and no sales call, just email verification. Run it on one messy client statement, compare the party ledger it produces against your own manual rollup, and judge it on that.