How would you test page breaks and debit signs in statement PDF exports?

I would appreciate software-testing perspectives on a fairly specific document-conversion problem: how do you distinguish a spreadsheet that merely looks plausible from one that actually preserves the transactions in a bank statement? A PDF can look tidy while its underlying text positions, scanned pages, line breaks and number formats are awkward. A successful download is therefore only the beginning of a useful test, not the acceptance criterion.

For disclosure, I am sharing this discussion in connection with Bank Statement Converter, not presenting an independent customer review. It is a web tool for converting bank statement PDFs and images into Excel, CSV or JSON, with individual and batch workflows. The concrete project reference is below. I am not claiming that it passes every test described here, and I would not treat an export as accounting advice or a replacement for checking the source.

https://bank-statement-converter.online/

The interesting part, to me, is designing a small reproducible test collection that exposes mistakes before anyone relies on the output. I would use invented transactions and fictional account details throughout. Please do not post real statements, account numbers, balances, customer information or screenshots containing personal data in this thread. The suggestions below concern testing software with synthetic documents, not sharing financial records with strangers.

1. Make the source of truth independent of the converter

Start with a short transaction table written manually as test data. Give every entry a unique reference, a date, a description, an amount and a direction. Keep a separate expected-results file that is not produced by the converter being tested. Otherwise it is too easy to compare one generated result with another result derived from the same mistake. A fictional statement can then be rendered from this table in several layouts without changing the expected transaction set.

I would include ordinary purchases, a refund, a transfer, a fee and one transaction with a longer description. The purpose is not to represent every bank. It is to make omissions, duplicate rows and sign reversals detectable using a fixture small enough for a person to inspect. An unusually complicated sample is less helpful initially than a clear sample with explicit expected answers.

2. Treat page boundaries as a separate feature

Put the same synthetic transactions into one-page and two-page documents. In the second version, split a long description close to the page boundary. Repeat a column header at the top of the second page and include a page number in the footer. A robust test should identify whether these layout elements become spurious transactions or whether a legitimate continuation line disappears.

Then move the page boundary without changing any transaction values. The exported transaction set should remain equivalent after the agreed normalization rules. I would specifically count how often the last row of page one appears and whether the first real row of page two retains its date. These checks are easy to overlook when the reviewer sees a neat spreadsheet and assumes that neatness implies completeness.

3. Make debit and credit meaning explicit

Some statement layouts separate debit and credit columns; others use signed amounts, parentheses, or an indicator beside a value. I would create separate fixtures for these conventions instead of mixing all of them into one supposedly realistic sample. Each fixture needs a documented expected interpretation. The important question is whether the amount and transaction direction remain correct together, not whether the exported number happens to have a familiar appearance.

A refund is a useful example because a description may resemble a previous purchase while its direction differs. I would also include an opening balance and closing balance clearly marked as summaries. They should not silently become extra transactions. This is a data-preservation check, not a recommendation about how a person should categorize the entries in their accounts.

4. Test dates and decimal separators without guessing

Ambiguous dates deserve their own cases. A document containing 03/04 is not enough to establish the intended day and month unless the fixture also supplies that convention. Make one sample explicitly day-first and another month-first. Include an unambiguous date in each sample and record the expected output representation. An unresolved ambiguous value should be visible to the reviewer rather than concealed behind a confident-looking conversion.

Likewise, use separate examples for decimal commas and decimal points. Large amounts with grouping separators are more revealing than a collection of small whole numbers. Check that a value such as a fictional one thousand two hundred thirty-four and fifty-six hundredths does not become a different amount because punctuation was removed incorrectly. Compare numeric meaning and preserve the source text where a workflow needs it.

5. Verify row identity before checking totals

A total is a useful diagnostic, but matching totals alone cannot prove that an export is correct. Two errors can cancel each other, and duplicated positive and negative entries can leave a misleadingly reassuring sum. First compare the expected number of transactions, then match entries using the synthetic reference and other relevant fields. Only after that would I compare totals or balance movement within the assumptions documented for the fixture.

There should be a visible distinction between an exact match, an allowed formatting change and an unresolved mismatch. Trimming harmless whitespace may be acceptable. Dropping a negative sign is not. A comparison script that normalizes too aggressively can hide the very failure that the test is supposed to reveal. I would keep its normalization rules short enough to review alongside the fixtures.

6. Compare export formats as different interfaces

Excel, CSV and JSON are not interchangeable containers merely because all three can represent a table. CSV needs correct quoting when descriptions contain commas, quotation marks or line breaks. A spreadsheet may display a long reference in scientific notation, while a JSON consumer may care whether a field is represented as a string or a number. These are practical integration questions, not cosmetic issues.

I would export the same small synthetic fixture into each available format and compare the underlying records after documented parsing. Identifiers should not lose meaningful leading zeros. Text should remain text when that is the agreed schema. If a spreadsheet application interprets a fictional description as a formula, that is also worth recording as a handling issue rather than treating every unexpected display as an extraction error.

7. Keep batch behavior observable

A batch test should initially contain just a few differently named fictional files. Include overlapping dates and deliberately similar transaction descriptions, but use distinct synthetic references so that the expected provenance stays clear. Compare individual downloads with any available archive or merged export. A merged table is convenient only if a reviewer can still tell which source contributed a questionable row.

I would then add one unsupported or deliberately damaged test file to see how a partial failure is communicated. The useful outcome is a clear distinction between completed files and files needing attention, without claiming that the whole batch succeeded simply because one downloadable result exists. This is also a place to check that accidentally processing the same fixture twice does not quietly masquerade as two different sources.

8. Report uncertainty instead of manufacturing confidence

My preferred review output would be a compact table showing fixture name, expected rows, observed rows, mismatched fields and a link to the synthetic source. A reviewer should be able to reproduce a failure without access to someone's real banking history. I would keep examples of clean digital PDFs separate from scanned images, because they exercise different parts of a conversion pipeline and should not be presented as equivalent evidence.

Which of these checks would you put into the smallest useful regression suite? I am particularly interested in whether people prioritize page-boundary fixtures, number-format fixtures or cross-format comparisons first, and in what makes a mismatch report easy to act on. Concrete suggestions using invented data would be welcome. I would rather have a short, inspectable suite with honest limitations than a large collection of screenshots and a vague claim of perfect accuracy.