How to Analyse a 10,000-Row Bank Statement Without Excel Falling Over (2026)

Two numbers are worth committing to memory. A modern .xlsx worksheet holds 1,048,576 rows. The older .xls format, which some bank portals and legacy accounting exports still hand out, caps at 65,536 rows. That second number is a genuine trap: a busy trading account can cross it in a single year, and when you open an oversized file in the old format Excel silently truncates the overflow. Your statement looks complete, the last visible row has a sensible date, and a chunk of the year is simply gone.

For ten thousand rows in .xlsx, though, the grid is not the problem. Calculation load is. Every formula you paste down ten thousand rows is ten thousand live calculations. Add three or four helper columns and a full-column lookup, and you are asking Excel to hold and re-evaluate tens of thousands of dependencies on every keystroke. Point two pivots at the same range and each keeps its own cached copy of the data. The workbook is now doing far more work than the analysis actually requires, and it shows.

The performance drag is almost always one of a short list of culprits. Knowing them by name tells you exactly what to change.

None of these is exotic. Together, on a large statement, they are the difference between a responsive workbook and the spinning wheel. The fixes are equally boring, and I set them out in the manual workflow below.

Speed is the trap you notice. The narration problem is the trap you do not, and it is the one that ends up wrong in your file.

The whole point of the exercise is party-wise: who paid whom, netted per counterparty, so you can scrutinise the ledger and see the real relationships. But bank narration is free text, and the counterparty name sits in a different place depending on the channel and the bank. A UPI debit, an IMPS transfer, an NEFT credit, and a cheque payment each carry the payee in a different position, with a different number of delimiters, and a cheque often carries no name at all. If you have not seen how much the strings vary, line up a few channels from any single bank statement side by side.

TEXTSPLIT needs a consistent delimiter and a consistent token position to work. Across a mixed statement you have neither, so a single split formula cannot pull the name cleanly for every row. You end up building a forest of nested IF and SEARCH logic to handle each channel, which is both slow and brittle, and it still misses the cases you did not anticipate.

Then comes the deeper problem, the one a pivot cannot see. The same counterparty appears under many strings:

A plain pivot treats each of those as a distinct party and fragments one counterparty into four ledger lines. At two hundred rows you catch it by eye. At ten thousand you do not. The party-wise ledger looks complete, reconciles to nothing in particular, and is quietly wrong. That is why the narration problem is more dangerous than the lag: the lag stops you, but this ships.

Beyond narration, a handful of mechanical issues survive quietly into working papers unless you check for them deliberately.

There is one check that catches most of these at once. Your party-wise ledger, credits minus debits, must reconcile to the statement's own movement from opening balance to closing balance. If the totals do not tie, the rollup is wrong somewhere, and you do not sign anything until they do. That single control total is also what confirms the reportable items, cash deposits against Section 269SS and 269ST and high-value entries that will surface in AIS and SFT, are sitting on a complete base.

Sometimes you will do it by hand, and it can be done cleanly. The order matters more than any single trick.

1. Fix the format first. If the export is .xls, confirm the row count against the bank's transaction total so nothing was truncated, then re-save as .xlsx or CSV. 2. Convert the range to an Excel Table. Structured references stay bounded to the data instead of scanning whole columns, and formulas fill down consistently. 3. Switch calculation to Manual. Under Formulas, Calculation Options, set Manual, and recalculate with F9 when you are ready rather than on every keystroke. 4. Establish the control total up front. Opening balance, total credits, total debits, closing balance. These must tie before you trust anything downstream. 5. Derive one signed amount column once, from whatever Dr or Cr shape the bank used, so the rest of the workbook reads a single clean number. 6. Build a counterparty mapping table. A two-column list of raw narration fragment to canonical party name. Populate it as you scrutinise, and resolve every row through one lookup against it, not through scattered IF logic. This is the manual version of what a clean party ledger actually needs. 7. De-duplicate repeated header rows and overlapping-range entries before you pivot, not after. 8. Categorise through a mapping table too, so the same merchant always lands in the same category regardless of when you reach it. 9. Only now pivot, party-wise, and reconcile the pivot totals back to the control total from step four. 10. Flag the reportables and carry them into your ITR summary: cash against the 269 thresholds, high-value AIS and SFT items, and any related-party movement you need to disclose.

This works. It is also, honestly, a half-day of careful work on a ten-thousand-row mixed-narration statement, and your mapping tables will not be complete on the first pass. You will keep finding a new spelling of a party you thought you had already resolved.

Look at that list again. Steps five through nine, the narration parsing, the counterparty normalisation, the categorisation, the pivot, and the reconciliation, are pure mechanics. None of them is judgement. Judgement is scrutinising the resolved ledger, deciding what is a related-party transaction, and forming a view on the reportables. The mechanical layer is exactly the part a tool should absorb so your attention goes to the audit, not to string-wrangling.

That is the specific job Greenote does, and it is worth being precise about what it is. You upload the bank's Excel or CSV export. It reads .xls, .xlsx, and .csv. It does not read PDF; converting a PDF statement is a separate desktop tool, and Greenote Lite is an analyser, not a converter. What comes back is a four-sheet, audit-ready workbook: a party-wise ledger with counterparties resolved across narration variants and the genuinely unattributable rows parked honestly in a Suspense line rather than hidden, every transaction categorised and named, a category summary, and an ITR summary with AIS and SFT flags. The statement is processed in memory and deleted the moment the report is ready. It is never stored.

On commercials, be clear-eyed. The first statement is free up to a transaction cap, then it is pay per statement, Rs 49 for one, with packs available and no subscription, no card, and a one-time code to your email instead of a login. A ten-thousand-row trading statement will usually run past the free cap, so the sensible move is to run the free statement on a smaller client first, confirm the output matches how you would have built it by hand, then bring the big one through. If you want the manual and automated approaches weighed side by side before you decide, that comparison is here, and the wider set of options is on the alternatives page.