Choosing a workflow
How to evaluate a bank statement converter without uploading a client's statement
You can test a converter without handing over a client's statement: use invented transactions whose answers you already know. Comparing the unchanged first export with the truth CSV below shows what needs fixing before you put client data into the service.
By AnyStatement
Published , 9 min read
If the bank already supplies a usable transaction export for the dates you need, you may not need PDF conversion at all. For PDF-only work, this page gives you a fictional statement to generate locally, its expected CSV and a scoring sheet. The test covers extraction and review, not bookkeeping reconciliation or document authenticity. Your firm and client decide whether a service is approved for their data.
Disclosure: AnyStatement sells a competing converter. This is a reusable test kit, not an independent product ranking. We have not uploaded this fixture to competitors or assigned them scores.
Start with eight rows you can account for
Everything below is fictional, including the account aliases and merchant names. There are six USD checking transactions and two EUR reserve transactions for September 2026. Both are deposit accounts: money in is positive, money out negative, and each balance is the balance after that row. This is not a credit-card sign test.
Save this block as a plain-text file named fictional-truth.csv, using UTF-8, and leave it unchanged so you have the original to compare against. The reference column is printed in the PDF too; the converter doesn't have to invent it. The two cafe payments are deliberately separate transactions with the same date, description and amount.
Reference,Account,Currency,PostedDate,Description,Amount,Balance
T01,TEST-CHECKING,USD,2026-09-01,FICTIONAL CLIENT PAYMENT,250.00,1250.00
T02,TEST-CHECKING,USD,2026-09-03,FICTIONAL OFFICE SUPPLIES ORDER 0042,-49.50,1200.50
T03,TEST-CHECKING,USD,2026-09-03,FICTIONAL SERVICE FEE,-0.50,1200.00
T04,TEST-CHECKING,USD,2026-09-04,FICTIONAL REFUND,15.00,1215.00
T05,TEST-CHECKING,USD,2026-09-05,FICTIONAL CAFE,-12.00,1203.00
T06,TEST-CHECKING,USD,2026-09-05,FICTIONAL CAFE,-12.00,1191.00
R01,TEST-RESERVE,EUR,2026-09-02,FICTIONAL DEPOSIT,40.00,240.00
R02,TEST-RESERVE,EUR,2026-09-06,FICTIONAL SERVICE FEE,-5.00,235.00| Measure | Checking (USD) | Reserve (EUR) |
|---|---|---|
| Transaction rows | 6 | 2 |
| Opening balance | 1,000.00 | 200.00 |
| Money in | 265.00 | 40.00 |
| Money out | 74.00 | 5.00 |
| Net movement | +191.00 | +35.00 |
| Closing balance | 1,191.00 | 235.00 |
Checking: 1000.00 + 265.00 - 74.00 = 1191.00. Reserve: 200.00 + 40.00 - 5.00 = 235.00. There is no combined money total because USD and EUR are different currencies. Opening balances and summary totals are not extra transaction rows.
Make your own PDF from this printable template
The HTML below is the source for your test PDF. Copy it into a plain-text file named fictional-statement.html, open that local file in a browser, then use Print and its save-to-PDF destination. With A4 portrait selected and browser headers and footers turned off, inspect the preview before saving as fictional-text.pdf. It should have two complete pages, one account per page. If a row is clipped or spills onto another page, adjust the print scale before continuing. Every product you evaluate needs the same saved PDF for a fair comparison.
The template contains no scripts, remote fonts or external resources. It's deliberately labelled as a test, without a bank logo, routing number or real identity. Use the invented data rather than replacing it with a redacted client statement, so your test doesn't depend on whether redaction removed everything.
Copy the complete fictional HTML template
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>FICTIONAL conversion test - not a bank document</title>
<style>
@page { size: A4; margin: 18mm; }
body { font: 12px Arial, sans-serif; color: #000; }
h1 { font-size: 18px; }
table { border-collapse: collapse; width: 100%; }
th, td { border: 1px solid #555; padding: 6px; text-align: left; }
section + section { break-before: page; }
tr { break-inside: avoid; }
</style>
<section>
<h1>FICTIONAL TEST ONLY - NOT BANK-ISSUED</h1>
<p>Account: TEST-CHECKING | Currency: USD | Page 1 of 2</p>
<p>Period: 2026-09-01 through 2026-09-30. Dates: YYYY-MM-DD.</p>
<p>Opening balance: 1000.00. Closing balance: 1191.00.</p>
<table>
<thead><tr><th>Reference</th><th>Posted date</th><th>Description</th><th>Money out</th><th>Money in</th><th>Balance</th></tr></thead>
<tbody>
<tr><td>T01</td><td>2026-09-01</td><td>FICTIONAL CLIENT PAYMENT</td><td></td><td>250.00</td><td>1250.00</td></tr>
<tr><td>T02</td><td>2026-09-03</td><td>FICTIONAL OFFICE SUPPLIES<br>ORDER 0042</td><td>49.50</td><td></td><td>1200.50</td></tr>
<tr><td>T03</td><td>2026-09-03</td><td>FICTIONAL SERVICE FEE</td><td>0.50</td><td></td><td>1200.00</td></tr>
<tr><td>T04</td><td>2026-09-04</td><td>FICTIONAL REFUND</td><td></td><td>15.00</td><td>1215.00</td></tr>
<tr><td>T05</td><td>2026-09-05</td><td>FICTIONAL CAFE</td><td>12.00</td><td></td><td>1203.00</td></tr>
<tr><td>T06</td><td>2026-09-05</td><td>FICTIONAL CAFE</td><td>12.00</td><td></td><td>1191.00</td></tr>
</tbody>
</table>
<p>6 transactions. Money in: 265.00. Money out: 74.00.</p>
<p>Invented data for software evaluation. Not evidence of funds.</p>
</section>
<section>
<h1>FICTIONAL TEST ONLY - NOT BANK-ISSUED</h1>
<p>Account: TEST-RESERVE | Currency: EUR | Page 2 of 2</p>
<p>Period: 2026-09-01 through 2026-09-30. Dates: YYYY-MM-DD.</p>
<p>Opening balance: 200.00. Closing balance: 235.00.</p>
<table>
<thead><tr><th>Reference</th><th>Posted date</th><th>Description</th><th>Money out</th><th>Money in</th><th>Balance</th></tr></thead>
<tbody>
<tr><td>R01</td><td>2026-09-02</td><td>FICTIONAL DEPOSIT</td><td></td><td>40.00</td><td>240.00</td></tr>
<tr><td>R02</td><td>2026-09-06</td><td>FICTIONAL SERVICE FEE</td><td>5.00</td><td></td><td>235.00</td></tr>
</tbody>
</table>
<p>2 transactions. Money in: 40.00. Money out: 5.00.</p>
<p>Invented data for software evaluation. Not evidence of funds.</p>
</section>
</html>The printed layout uses separate money-out and money-in columns, while the truth CSV uses signed amounts. In row T02, ORDER 0042 sits on a second line inside the same description. That line belongs to the transaction: it must not become another row or disappear. Joining the line break with a space is acceptable; losing the order reference is not.
Finding some text doesn't establish that the transaction table is readable or correctly ordered. Use the PDF text-layer checker on the saved file and inspect the transaction text on both pages.
Judge the downloaded file, not only the preview
An untouched export shows what the converter produced; a corrected copy shows the work needed to make it usable. Before uploading the fictional PDF, record the product, date, plan or trial, selected export format and any OCR setting. Save the first downloaded export as it is, then make repairs in a second copy, noting each changed value and the minutes spent reviewing it.
Compare one account and currency at a time, using money in minus money out in a working copy if the export has separate debit and credit columns. Confirm the date order explicitly, but don't strip digits from descriptions or remove repeated payments to make the files agree. Any deliberate whitespace normalization needs to be recorded too.
Use the CSV before-and-after comparison with the truth rows as the before file and the extracted rows as the after file. Once you've chosen comparable columns, inspect unmatched rows and changed occurrence counts. References, descriptions and balances still need your own check if they fall outside that comparison. Matching files establish agreement only on the fields compared; they don't establish that the source document was genuine.
For the arithmetic check, use the statement balance checker separately for each account, taking opening and closing balances from the template rather than a total calculated by the converter. Map the printed after-transaction balances and preserve row order, including the two same-day cafe payments. A zero closing difference isn't enough: money-in and money-out totals need separate checks.
A preview showing eight rows isn't enough if the download contains only six, so record export restrictions and any extra payment required to obtain the complete file. Trace T02, T03, T06 and R02 back to their printed rows as well. Those rows let you check a wrapped description, a small fee, the second legitimate same-value payment and the last account.
A scoring sheet that does not hide a missing account
For each criterion, give 2 when the first export meets it without repair, 1 when an explicit warning or documented manual step is needed and the corrected result meets it, and 0 for a wrong, missing or unavailable result. Use NT for not tested, never a guessed pass. This is our proposed rubric, not an industry certification or an accuracy percentage.
| Check | Full-credit result | Score / evidence |
|---|---|---|
| Row count | 6 checking + 2 reserve; no headers or totals counted | |
| Amounts and signs | Every amount matches, including -0.50 and +15.00 | |
| Dates | Every posted date retains its September 2026 meaning | |
| Descriptions | Full wording and ORDER 0042 survive on the right row | |
| Repeated payments | T05 and T06 both survive as separate rows | |
| Account boundaries | Two identified accounts; USD and EUR stay separate | |
| Balances | Every running balance and both closing balances match | |
| Source review | Exported rows can be located in the source without guesswork | |
| Complete export | All expected rows and required fields download | |
| Repeat run | Same PDF and settings retain the same transaction values |
The ten scores add up to a maximum of 20, but only report a total when every criterion was tested. Otherwise, give the subtotal, number of tested criteria and each NT. Review minutes and export cost belong alongside the score, not inside it: a product that needs less repair may be more useful than one with a faster upload animation.
A missing account, unresolved row loss, wrong sign or mixed currency means stop, whatever the total score. The privacy decision below also needs to be resolved before client use. If your work requires scans, a successful text-PDF result doesn't make a failed scan acceptable; don't average the two results together.
Change one thing at a time
A clean, small text PDF is only a starting point if your work involves other kinds of files. Make separate copies for the variants you need while preserving the truth CSV, and don't quietly change the fixture between vendors. Someone else should be able to repeat the run from the original, altered file and settings you keep.
- A date-order test changes only the displayed transaction dates to DD/MM/YYYY and the date-format label to match. T02 becomes 03/09/2026, meaning September 3, not March 9. The truth dates remain unchanged.
- To test page continuation, move T04 through T06 onto another page under a repeated table header, labelled TEST-CHECKING, USD, and update the page numbers. It's still six checking rows, not another account or a new opening balance.
- An image-only test needs a full-page image of each original PDF page. Place each image on its own page in a local document, then save that as PDF without adding OCR. Before using it, confirm the transaction area is legible and the text-layer checker finds no text, and record the image dimensions. A clean raster copy tests this image workflow, not a damaged paper scan, so test a real print-and-scan copy separately if that's your workload.
- For the password test, create a copy in a local PDF editor that requires a new test-only password to open. Don't reuse a client password. Reopen the copy to confirm the prompt, then record whether the converter requests the password, refuses clearly or requires a locally unlocked copy. A clear refusal is honest unsupported behavior, but it isn't a successful conversion.
Deliberately damaged copies of the truth CSV let you test the checking method itself. These are injected errors, not observed converter failures. Leave the original balances unchanged in each damaged copy so the discrepancy remains visible.
| Injected change | Computed closing | What should catch it |
|---|---|---|
| Remove T03 (-0.50) | 1,191.50 | 5 rows; closing difference +0.50 |
| Make T02 +49.50 | 1,290.00 | Wrong sign; closing difference +99.00 |
| T02 becomes -39.50; T04 becomes +5.00 | 1,191.00 | Wrong row values and interim balances; net still agrees |
In the offsetting-error case, money in becomes 255.00 and money out becomes 64.00. Both are wrong even though net movement stays 191.00. That is why a balanced statement can still be wrong.
Questions to settle before a client file leaves your device
A fictional conversion can't establish how a service handles confidential files. You need written answers and the relevant policy or contract, with the URL, version and date read recorded alongside them. An unanswered question stays unknown; it isn't a reason to assume the answer is favorable.
- Where are the original PDF, extracted text and exports processed and stored? Which service providers receive them, and can support staff or other humans access them?
- What is the retention period for each copy, including failed jobs, OCR intermediates, support attachments, logs and backups? When does that period start?
- What does manual deletion remove, and when? Does account deletion differ from file deletion? What evidence of deletion is available?
- Are documents or extracted values used for model training, evaluation or product improvement? Does opting out cover downstream providers and trial accounts too?
- How are file access, sharing links and passwords protected? Does a PDF password leave the browser, and is it retained? What access controls are available for your team?
- Will the vendor provide the data-processing terms and security evidence your firm requires? Who handles incidents, and what notification commitment applies?
These are procurement questions, not a legal checklist or a security audit. A lock icon, a correct CSV or a deleted item disappearing from a dashboard does not answer them. Approval belongs with whoever is responsible for the client engagement and data policy.
Choose for the job you actually need
If a bank-native export or an import feature already included in your accounting software meets the need, compare that route before buying another service. For PDF-only work, you can apply the same fixture to AnyStatement or a competing converter; that is a separate upload. Use our converter choices by situation and DocuClipper comparison to narrow the shortlist, not to replace your own result sheet.
Even a full score here says only that this tiny fictional fixture met the stated checks. A service may reject an invented layout that resembles none of its supported bank templates, so record that limitation without declaring its real-bank extraction bad. Passing doesn't establish performance on your bank, all scans, other currencies or long statements either. Destination-app acceptance needs a separate, authorized test in the actual app, without polluting a live ledger.
What we checked, and what remains untested
On 18 October 2026, we checked the fictional CSV and HTML row values against each other and recomputed every running balance, total and injected-error result with Python Decimal. We also checked that the ten scoring criteria have a maximum of 20 points. The template and expected answers are published above so you can inspect them.
We generated a PDF from this exact HTML using automated Chromium 150 printing at A4 portrait and 100% scale, with browser headers and footers disabled. It produced two complete pages. We inspected both saved pages and checked all eight rows, including the money-column positions and wrapped description, against the truth CSV. The local PDF text-layer checker found text on both pages. We did not operate the manual Print dialog or test other browsers, OCR variants, the password workflow, any converter outputs or accounting-app imports. No product scores are reported.
For the review method only, we reopened Google's high-quality review guidance (last updated 10 December 2025) and people-first content guidance (last updated 5 October 2026) on 18 October 2026. They support explaining methods and supplying original evidence for review claims. They do not validate this scoring rubric, establish privacy requirements or endorse a converter.