Producing bank statements as numbered exhibits

Counsel has asked for the bank statements to be produced as numbered exhibits, and you have eighteen months of statements for three accounts sitting as separate statement documents. The numbering itself is mechanical. The part that goes wrong later is the connection between the stamped pages and the spreadsheet everyone actually works from, because once a paralegal is querying rows in Excel, nobody can say which stamped page a given figure came from.

Producing bank statements as numbered exhibits is really two jobs: fixing and stamping the source pages, and then converting from that fixed set in a way that carries the page reference into every row.

What carries the number

Settle this before anything else, because it decides how every later citation reads. Under Bates-style production numbering, standard in US discovery, each page carries a number of its own so it can be cited without reference to the document around it, and a multi-page statement therefore occupies a range. Under the per-document exhibit numbering common elsewhere, the statement takes one number and pages are cited within it. Transactions are never numbered under either scheme; they are located by the page they appear on.

The rest of this assumes per-page stamping, because that is where the traceability problem bites hardest. A short bundle for one account might run:

Twelve pages in total, numbered continuously from SMITH-000412 to SMITH-000423 with no gaps. A transaction on the second page of the January statement is cited as SMITH-000413. A transaction on the last page of the March statement is cited as SMITH-000423. The continuity does one specific job: an unbroken sequence is evidence that nothing was pulled from the bundle after the stamp went on. It says nothing about what reached the bundle in the first place.

Beyond that, conventions differ. Some matters use production numbering across the whole set and separate exhibit numbers assigned later at deposition or hearing. Some courts have standing orders on format, load files and page limits. Whether your bundle needs one scheme, both, or something else entirely is a question for counsel and for the court's own rules, and it should be settled before a single page is stamped.

Fix the set before you stamp it

Stamping a bundle that is still changing is the most common way this goes wrong. Every later insertion either forces a renumber or creates suffixed numbers that nobody trusts.

1. 1

   Assemble the complete set

   Gather every statement for every account and period covered by the request, including months with no activity and accounts with a nil balance.
2. 2

   Check the set before numbering

   Confirm each statement's closing balance equals the next statement's opening balance for the same account, and separately that the printed statement periods run end to end with no gap. A break with a date gap points at a period nobody obtained; a break with contiguous dates points at a misread figure in one of the two files. Finding either now is far cheaper than renumbering later.
3. 3

   Fix the page order

   Settle the sequence: by account, then chronologically, is the convention most bundles use. Record the ordering rule you applied.
4. 4

   Stamp every page

   Apply the number to each page in an area that does not obscure figures. Bank statements print dense tables close to the margin, so check the stamp position on the densest page rather than the cover page.
5. 5

   Convert from the stamped set

   Run the numbered documents through conversion, not the originals you started with, so the rows come from exactly the pages that were produced.
6. 6

   Record the range against each statement

   Keep an index mapping each statement, account and period to its number range, and store it with the bundle.

Carrying the page reference into the converted rows

The converted spreadsheet is where the analysis happens: totals, date ranges, transfers traced between accounts, summaries prepared for a hearing. Every one of those outputs is challengeable, and the answer to a challenge is to show the row on the page it came from.

That is only fast if the row already carries the reference. Alongside date, description, debit, credit and running balance, add two columns: the account identifier and the source page number. A row then reads as a complete assertion. On 14 March, account 4471, a debit of 3,412.08, running balance 9,806.51, from page SMITH-000413. Anyone can check it against the stamped page without searching.

Two habits keep that column honest.

• Populate it at conversion time. Reconstructing page references after the fact means guessing where page breaks fell, and page breaks are exactly where rows get split or duplicated in the first place.
• Avoid renumbering a produced set. Where pages have to be added, the usual practice is to produce them as a supplemental range continuing the sequence rather than reopening the original one, though some matters and some courts have their own rule on this, so ask before you assume.

Splitting, combining and the traps in both

A bundle rarely stays as tidy as the first stamp suggests.

Statements that cover more than one account. Some banks print a checking and a savings summary in one document. The page range belongs to the document, but the rows belong to two accounts, so the account identifier column has to be populated correctly even though both accounts share pages.

Excerpting. Producing four pages out of a twelve-page statement leaves a discontinuous range, and a discontinuous range invites an argument about what was withheld. If pages are held back, that decision belongs to counsel and should be recorded, not made silently by whoever assembled the bundle.

Check images and inserts. Some banks interleave scanned cheque images between transaction pages. Those pages are part of the document and get numbers like any other, but they contain no transaction rows, so a converted file should not produce rows for them. A converted set that suddenly has rows attributed to an image page is a signal that the extraction picked up something it should not have.

Re-exported statements. A statement downloaded again from the bank months later may paginate differently from the copy you stamped. Convert from the stamped copy, always, and keep it. This is the same discipline that governs any financial record converted for discovery review: the produced file is the artefact, and the derived spreadsheet points back at it.

What the numbering does and does not establish

A continuous number range shows that the bundle you produced is the bundle you assembled, in the order you assembled it, with nothing removed after the stamp went on. It says nothing about whether the underlying statements are complete, whether the figures in the converted workbook were read correctly, or whether a page was left out before the bundle was assembled at all.

Continuity across periods comes from the balance chain: each statement's closing balance should equal the next statement's opening balance for the same account. Read a break in it carefully, because it is not one thing. A break where the period dates leave a gap points at a statement nobody obtained, which is a collection problem. A break where the periods are contiguous points at a misread figure in one of the two files, which is an extraction problem. The two get resolved in completely different places, and calling every break a missing month sends people to the bank when the fault is in the conversion.

Be equally exact about what a joining chain shows, because it is narrower than it looks. It shows that the statements you hold join up. It cannot show that a statement was never issued for a period nobody asked the bank for, and a dormant month that closes on the balance it opened with will chain cleanly onto a statement that is not really its neighbour, leaving no arithmetic trace at all. So read the period printed on the front of each statement as well, and confirm the periods form an unbroken calendar per account, with no gap between one period's end and the next period's start, across the whole span the request covers. The chain and the calendar answer different questions, and a production is only as complete as the two of them together.

Accuracy of the converted figures is a separate matter again, and it is worth saying which check you mean. Totalling a statement, opening balance plus credits minus debits against the closing figure printed on its own page, is defeated by any two errors that cancel. A row lost at a page break and another row of the same value read twice on the next page are exactly such a pair, and page breaks are where both happen. The version to rely on rebuilds the running balance from the opening figure one row at a time and compares each rebuilt figure against the balance printed on the page. That pair no longer survives: the rebuilt column goes out at the row that vanished and stays out until the duplicate cancels it, so every row in between disagrees with the stamped page it came from.

Even the rebuilt version speaks only for the amount column. Dates, descriptions, counterparties and any categorisation resting on them rebuild perfectly whatever they say, as does a row recorded with an amount of zero, and so does a balance misread in a way that agrees with the amount misread beside it. Where a statement prints no running balance the check is not available at all. A transaction attributed to the correct page with the correct amount and the wrong date rebuilds perfectly and will still misplace a payment in any chronology built from the workbook. Those caveats belong in whatever witness statement or certificate accompanies the workbook, alongside the practices covered in keeping converted records defensible. Numbering performs none of these checks. It makes all of them repeatable by someone on the other side, working from the same pages you worked from.