Quick summary
When the sum of your transactions disagrees with the movement between the opening and closing balances by a cent or a penny, work through these checks in order:
1. One row's amount disagrees with its own running balance. Subtract each row's balance from the previous row's balance and compare it with that row's amount. In the worked example below, the fee row is where the extra penny hides: the amount column and the balance column tell slightly different stories, and the balance column is the one that agrees with the closing balance.
2. A row is missing from, or appears twice in, the export. A dropped or duplicated small row (a fee, an interest credit) shifts the sum without touching any individual amount. Count the rows and compare them with the statement.
3. The period boundary cut differently than you expected. A transaction dated on the first or last day may sit inside the balances but outside your exported date range, or the other way round. Re-export the exact statement period before editing anything.
Instead of manually editing source records or forcing numbers to balance, follow this structured reconciliation workflow to locate the gap and produce an auditable working paper.
What this problem looks like
When comparing your statement header to the exported lines:
- Opening balance: £1,000.00
- Closing balance: £2,125.50
- Expected net movement:
£2,125.50 - £1,000.00 = +£1,125.50 - Sum of CSV transaction amounts:
+£1,125.51 - Reconciliation difference:
+£0.01(Off by 1 penny)
Opening balance: £1,000.00
Closing balance: £2,125.50
Calculated move: +£1,125.50
Transaction sum: +£1,125.51
---------------------------------------------
Discrepancy: +£0.01 (Requires manual review)Silently altering a transaction amount to force zero difference destroys your source record audit trail. If tax authorities or auditors inspect the original bank statement, modified amounts will trigger compliance flags.
Synthetic CSV example (TS-REC-001)
You can test this exact scenario using our synthetic fixture dataset. Notice row 3 where an invoice fee difference creates the one-penny delta:
Date,Description,Amount,Balance
2026-04-01,Opening balance transfer,500.00,1500.00
2026-04-05,Client retainer invoice,750.00,2250.00
2026-04-12,Merchant transaction fee,-24.49,2225.51
2026-04-20,Office supplies purchase,-100.00,2125.51*(Note: Target closing balance was £2,125.50, but calculated running balance ended at £2,125.51).*
Step-by-step verification in TaxStatement
1. Import the statement: Select your CSV file or the synthetic sample in the workspace.
2. Map the columns: Map Date, Description, and Signed Amount (or separate Debit/Credit columns).
3. Enter boundary balances: Enter 1000.00 in the Opening Balance field and 2125.50 in the Closing Balance field.
4. Inspect the discrepancy indicator: TaxStatement computes integer-cents arithmetic in memory and highlights:
Opening/closing difference: +£0.015. Mark for review: Keep the source transaction row unchanged. Use the category dropdown to label the row (e.g., Review required or Operating expense) and leave an explanatory note in your bookkeeping working paper.
6. Export working paper: Download the clean CSV or Excel working paper. Excluded or flagged items remain visible with full audit markers.
What TaxStatement does NOT do
- No automatic guessing or rounding: TaxStatement never rounds or quietly edits amounts to make statements balance.
- No silent deletion: Potential duplicate transactions or outlier amounts are flagged with a review marker (⚑) for human verification.
- No tax determinations: Labeling an entry as an expense does not constitute formal tax advice or HMRC digital submission.
Troubleshooting & Best Practices
- Always check boundary dates: Ensure your export range does not cut off transactions executed at 23:59:59 on the closing date.
- Retain source traceability: When submitting your working paper to your accountant, always include the unedited bank PDF or original CSV hash alongside the reconciled spreadsheet.