How do I convert a statement whose table wraps across pages?

A statement table that wraps across pages converts cleanly when the converter reads the pages as one table: it reuses the column header page 1 printed, joins a transaction the break cut in two, and checks the rows against the closing balance. Evidilo does all three. Excel’s Power Query, by Microsoft’s own reference, combines similar tables on consecutive pages by default.

We printed one two-page statement ten ways and read each through Evidilo’s production reader. Every amount and running balance came back as printed. The description line printed alone at the top of page 2 came back as part of its row, and a “balance carried forward” line at the foot of page 1 did not stand in for the closing balance. One shape still loses its second line: a description set as far below its row as the next row stands, in the middle of a page.

What does a page break do to a statement table?

A page break leaves four shapes behind, and each one is a place where reading a statement page by page goes wrong. A page that does not repeat the column header has no column names of its own. Half a transaction at the foot of a page is a row with no amount, and the other half at the top of the next is a row with no date.

1. No header on the next page. A statement may print Date, Description, Amount and Balance once, on page 1. The rows on page 2 sit in the same columns with nothing above them to say which is which.
2. A transaction cut in two. The date and the first words of the description end page 1; the rest of the description, the amount and the balance open page 2.
3. A description that wraps onto the next page. A check or a transfer with a long payee line prints its second line at the top of the next page, with no date and no figure beside it.
4. Balance carried forward and brought forward. A subtotal at the foot of one page and the same figure at the top of the next. Both sit in the balance column and neither is a transaction.

What happened when one statement was printed ten ways?

Every version gave six rows with the right date, amount and running balance. The column header missing from page 2 and the transaction split by the break made no difference: the 09/14 transfer came back as one row reading ACH TRANSFER TO SAVINGS 7731, its two halves joined. The description printed alone at the top of page 2 came back in full as part of row 3. The one difference left is a description set as far below its row as the next row stands.

The PDFs imitate no bank’s layout, so the table says what this reader does with each shape and nothing about how often a given bank prints one.

Why can a description lose its second line at a page break?

Because a line with no date and no figure only belongs to a row by being close to it. Evidilo joined the second line to the row above in both controls, in the middle of page 1 and at its foot, and it joins the words “PAYEE J SMITH MEMO SEPT RENT” printed alone at the top of page 2 to row 3, the check they belong to.

A line that is lost is flagged by nothing. The amount and the balance of that check were right, so the balance check tied out, because a check that catches a wrong figure cannot see a missing word. For a deposit that matters little. On a check or a transfer the payee line can be the only thing that says what the payment was for, so compare the last row before each page break with the PDF.

Spacing matters too. Set 14 points below its row, as far down as the next row stands, the same kind of second line was kept in no row even in the middle of page 1. A statement that sets its wrapped lines that loosely is one to read row by row after converting.

Why does a balance carried forward line stop a statement tying out?

Because a reader that takes that figure for the statement’s closing balance compares the rows against it. With BALANCE CARRIED FORWARD 2,117.83 at the foot of page 1, the six rows are 73.60 apart from it and the statement is held as not tying out, although every row is right. The figure is the balance the page carries into the next one, and the statement’s own closing balance is the one printed at its end.

Evidilo reads the closing balance from the last page, so the carried-forward figure does not stand in for it. The same figure printed as BALANCE BROUGHT FORWARD at the top of page 2, with nothing at the foot of page 1, caused no trouble either. Neither line became a transaction in any version.

This mistake fails loudly rather than quietly: a statement that ties out to the wrong figure would be worse than one held for a second look. On a paid plan, a statement that does not tie out uses no pages until it is corrected and ties out. When a multi-page statement fails at the closing balance and every day before it ties out, compare the closing figure the converter used with the one on the last page. Why a balance check catches what it catches is covered in what a tied-out statement tells you.

How do I check a converted multi-page statement before importing it?

Check the joins, not every row. A page break damages the rows next to it, so the first and last row of every page and the closing balance carry most of the risk.

1. Count the transactions on the PDF and the rows in the converted file. Where a converter misses a join, a transaction the break cut in two shows up as one row too many or one too few.
2. Read the last row of each page and the first row of the next. A split transaction should appear once, with both halves of its description and its amount.
3. Look for a description at the foot of a page that stops short, its second line printed at the top of the next page, above all on checks and transfers.
4. Compare the closing balance the converter used with the closing balance printed on the last page, not a carried-forward subtotal.
5. Import, and match the rows against anything the bank feed already brought in. A PDF bank statement into QuickBooks without duplicates walks through that step.

A statement that prints the date once for a group of rows adds one more join to look at, because the date has to carry over the break as well; when a bank statement prints the date once a day covers that shape.

What is Evidilo?

Evidilo is a bank statement to accounting import file converter. On a statement that runs over several pages it reads a page with no header under the columns of the last page that printed one, then adds up every row against the opening, closing and daily balances the bank printed and marks the first day that does not tie out. It turns a PDF, a scan, a photo of a paper statement, a CSV, an Excel file, a Word document or an OFX/QFX file into QBO, IIF, OFX, QFX, QIF, CSV or Excel. Three statements a day convert free, up to 10 pages each, without an account.

How was this checked?

On 28 October 2026 we wrote one synthetic two-page statement, six transactions with their running balances, as ten PDFs with pikepdf 10.17.0, each changing only what the page break does to the table. Each went through Evidilo’s production code the way an upload is read: the pages, the statement period, then the rows, with no model involved, which is the route a PDF with a text layer takes. Every row was compared with what that PDF printed. The results are in dataset.csv, and check.py rebuilds the ten files, repeats every reading and re-reads Microsoft’s Pdf.Tables reference.

Questions about statements that run over a page

Can Excel combine a bank statement table that spans several pages?

By Microsoft’s own reference, Microsoft Excel’s PDF import does, by default. Its PDF connector runs Pdf.Tables, whose reference describes MultiPageTables as controlling “whether similar tables on consecutive pages will be automatically combined into a single table”, default true. We did not run Excel on these files, so how it handles a split transaction or a carried-forward line is untested here. Evidilo joined the split transaction in our test and checked the result against the closing balance.

Why is one transaction missing after converting a multi-page statement?

One cause is a page break that cut it in two, its date on one page and its amount on the next. Evidilo read that shape as one row in our test, recorded on the page where its date was printed. A dropped amount also shows up in its balance check as the first day that does not tie out, which tells you where to look.

Does a page break change the amounts on a converted statement?

In our ten files it did not: every amount and running balance read as printed. One description set as far below its row as the next row stands was in no row; every other description came back in full, the one printed alone at the top of page 2 included. DocuClipper or any other converter is worth the same test on a statement of your own that carries these shapes.

Should I delete the balance carried forward lines before converting?

No. Neither the carried-forward nor the brought-forward line became a transaction in our test, and the carried-forward figure did not stand in for the closing balance. Compare the closing figure with the one printed on the last page instead of editing the bank’s PDF, which leaves you with a document the bank did not issue.

Does a scanned multi-page statement convert the same way?

Evidilo reads a scan or a photo of a paper statement through a model rather than the text layer, and this test did not cover that route. The balance check runs on the result either way. What a reader has to prove on a statement photo covers scans, and Adobe Acrobat’s text recognition is another route we have not tested.