If you assess tenants, lend money, or prepare accounts from documents clients hand you, you will eventually be given a statement that has been edited. Usually it's modest — a balance nudged upward, an awkward transaction removed. And it will almost certainly look fine, because modern PDF editors are good and the person editing only has to fool a human skim.

The good news is that a bank statement is unusually hard to fake convincingly, for a reason that has nothing to do with how it looks: it's an arithmetic system, and every number in it constrains the others. That's what you check.

Why looking at it doesn't work

The visual tells people are taught — wrong fonts, misaligned columns, a fuzzy logo, inconsistent spacing — do catch careless work. But they fail in both directions. A competent edit in a proper PDF editor reuses the document's own embedded font and leaves no visual trace at all. Meanwhile plenty of *genuine* statements look odd: scanned, re-saved, printed and re-scanned, or reformatted by the applicant's own printing setup.

So treat appearance as weak evidence in either direction, and put your weight on checks that don't depend on it.

Check 1 — The balance chain (the strongest test you have)

Every statement carries its own answer key. Two constraints must hold:

opening balance + all credits − all debits = closing balance

and, row by row:
previous running balance + this row's amount = this row's balance

This is what makes editing hard. Change one amount and you must recalculate every running balance below it and the closing balance — and if you change the closing balance you break the relationship to the next statement in the sequence. Most alterations fail here, because the person editing changed the number they cared about and left the arithmetic alone.

Doing this by hand across 200 rows is unrealistic, which is exactly why it goes unchecked. Doing it mechanically takes under a minute: convert the statement and the reconciliation runs automatically, per section and per currency, flagging any section where the arithmetic doesn't hold. That's the same check described in bank reconciliation in Excel, applied to a document you have reason to doubt.

Important caveat: a failed check is not proof of fraud. Scans and OCR introduce genuine misreads, and some statement layouts legitimately confuse extraction. Treat a failure as a question to ask, not a verdict. Conversely, arithmetic that holds perfectly doesn't prove authenticity either — a careful forger recalculates. It shifts the odds substantially, which is what a screening check is for.

Check 2 — Statement-to-statement continuity

When you've been given several months, chain them: each statement's closing balance must equal the next one's opening balance. A break in that chain means either a missing statement or an edited one, and it catches a whole class of alteration that per-document checks can't — because a forger fixing one month's internal arithmetic often forgets that it also has to agree with the neighbouring months.

This is also why asking for a longer period is a genuinely useful screening tool. Three months gives two junctions to check; six months gives five, and each one is another constraint the numbers have to satisfy.

Check 3 — PDF metadata

Open the file's document properties (in most viewers: File → Properties). You're looking at Producer, Creator, and the creation and modification dates. A statement generated by a bank's reporting system will typically name that system or a server-side PDF library. A statement naming a consumer image or PDF editor as its producer, or carrying a modification date later than its creation date, deserves a question.

Two honest limits. Absent or generic metadata proves nothing — plenty of legitimate paths strip it, including printing to PDF or passing the file through a bank's own portal. And metadata is trivially editable by anyone who knows it exists. Use it as a signal, never as your only one.

Check 4 — Internal consistency

Things that should agree and often don't in edited documents:

Check 5 — Change how you receive the document

The most effective control isn't a check at all — it's not relying on a file the applicant can edit before sending:

If your process depends on emailed PDFs, accept that you're screening rather than verifying, and screen well.

A practical screening order

  1. Convert the statements and check the internal arithmetic on each. Under a minute.
  2. Chain the balances across months. Seconds, once converted.
  3. Glance at PDF metadata. Seconds.
  4. Spot-check dates, sequence, and agreement with payslips or invoices. A few minutes.
  5. Anything unexplained → request verification through a channel the applicant doesn't control.

Note where the effort sits. The two checks that catch the most are the two nobody does by hand, because arithmetic across hundreds of rows is tedious — and tedium is precisely what forgers rely on. Automate those two and your screening is better than most.

One more thing, for the honest applicant

If you're the one submitting statements: don't edit them, not even to remove something embarrassing. Altering a financial document for credit, tenancy or a visa application is fraud, it's checkable by the methods above, and the consequences are far worse than whatever you were hiding. Explain it in a covering letter instead — see what lenders actually check and what consulates check. Context is normal; alteration is disqualifying.

Run the arithmetic check on a statement free — 3 pages with no signup, 20 with an account, no credit card and no trial timer.