An edited PDF usually still contains the number it used to say

A PDF is not a picture. It is a container of objects, and what you see on screen is one rendering of those objects rather than the whole file.

That gap is where document editing gets caught, because the easy ways to change a number on a PDF leave the original number inside the container.

Annotations sit on top rather than replacing anything

The most common way somebody changes a number on a pay stub is a free-text annotation. Most PDF readers offer it, it takes ten seconds, and it looks identical to real content once flattened visually.

What it actually does is add an annotation object positioned over the existing text. The original text object is still there, underneath, unchanged.

So a stub showing gross pay of $6,400 can contain both a $6,400 annotation and a $4,200 text object at the same coordinates. Reading the page shows one number. Reading the object tree shows two, at the same position, which is not something a legitimate document does.

A white rectangle drawn over the old number and new text placed on top produces the same result. The rectangle is an object, the covered text is still an object, and both are readable.

Hidden text layers come from scanning and from tampering

Text can exist in a PDF without being visible, and there are two very different reasons for it.

The innocent one: a scanned document run through optical character recognition gets an invisible text layer behind the image so the file is searchable. That is normal, and the text layer should match the image.

The other one: text set to invisible, or positioned outside the page boundary, or rendered in a color matching the background. Each of those is a way to have content in the file that a reader does not see.

The check that separates them is agreement. On a legitimate scanned document, the hidden text layer says the same thing the visible image says. When the invisible text says $4,200 and the image says $6,400, the document was assembled from two sources.

Incremental updates keep the whole history

The PDF specification allows a file to be saved incrementally: new objects appended to the end, a new cross-reference table pointing at them, and the old objects left in place untouched.

Every editor that saves this way leaves a recoverable earlier version of the document inside the same file.

Practically, that means a file can be walked backward through its revisions. Each generation of a modified object is still present, and the sequence shows what changed and in what order.

A pay stub with three revisions in it is a pay stub somebody worked on.

Two fonts inside one line means somebody typed into it

Real documents are generated by one system with one font set. Edited documents frequently mix.

The signals worth checking:

A single line where some characters use one embedded font and others use a different one. Numbers replaced by typing usually come out in whatever font the editor defaulted to.

A font embedded in the file but used for only two or three glyphs, which is what happens when a small edit pulls in a new typeface.

Character spacing that is metrically inconsistent within a number, because a hand-placed digit rarely lands on the original kerning grid.

Each of these is weak on its own and they cluster. A document with a font mismatch, an annotation over a value, and a producer string naming a browser is not three coincidences.

What this cannot catch

The honest limit, and it is the same one every document-analysis approach has.

A document generated from scratch, cleanly, by a tool that produces a single-pass PDF with consistent fonts and no annotations, contains no internal contradiction to find. There is no earlier version, because there was never an earlier version. Forgery services that generate rather than edit are the harder case, and they get caught by metadata fingerprints, YTD reconciliation, and cross-document consistency rather than by object parsing.

Which is why none of this is the primary path. Connecting to the applicant's bank or payroll account directly means the income figure comes from the institution rather than from any file, and the whole question of what a document contains stops mattering. Forensic analysis exists for applicants who cannot or will not link an account, and it should be understood as the fallback it is.

A flag has to name its signal or nobody can act on it

A verdict has to say which signal fired, or a leasing agent cannot use it.

"This document was flagged" produces either a blanket denial or a shrug. "This document contains a text annotation over the gross pay field, and the text underneath says $4,200" produces a specific conversation with the applicant, which is also the version that survives a fair housing review because it is a documented, consistent, non-discretionary reason.

Verdicts return in two to three minutes with the specific signal behind each flag and a per-attempt audit trail. When a new pattern is found, it gets converted into deterministic detection logic so it becomes a permanent rule for every customer rather than one analyst's catch.

Try it on a document you already approved

Open a pay stub from an approved file in any PDF reader and use the text selection tool. Drag across the gross pay figure.

If the selection highlights something other than what you see, or selects nothing at all where text should be, the file has more in it than the page shows.

What got selected?