How to spot a fake pay stub

A forged pay stub looks exactly like a real one. That is the whole point of it.

AI tools now generate stubs with correct year-to-date math, real employer names, and formatting indistinguishable from an actual ADP printout. Your leasing agent cannot tell. Most screening software cannot either, because it is looking at the same rendered page a human looks at.

The signals that work are in the file, not on the page.

Hidden text layers: the document says two things at once

A PDF can show one number to your eyes and store a different one in its data.

This happens because editing a PDF often layers new content over old rather than replacing it. The renderer draws the top layer. The extracted text still contains both.

Comparing the two is mechanical. Any mismatch on a wage, a date, or a name flags the document. It is also the single most conclusive signal available, because there is no innocent explanation for a stub that reports two different hourly rates.

Annotation artifacts: payroll software does not revise

Real payroll systems generate a document once and never touch it again. There is no business reason for ADP to reopen a stub and modify it.

So post-creation edit markers mean something changed after the fact. PDF annotations, incremental save records, and modification timestamps that postdate creation are all evidence of a document that was worked on by someone other than the payroll provider.

Metadata fingerprinting: every real system leaves the same trace

This is the most useful signal at scale, and it needs explaining because it is easy to get wrong.

Every PDF carries Creator and Producer fields naming the software that made it. Real payroll and banking systems produce consistent values. Consumer PDF editors produce different ones.

We built the reference set from 14,561 production documents, keeping a fingerprint only where there were at least 30 files from that institution and the dominant creator or producer accounted for more than 50% of them. Two real examples:

A statement claiming to be from Bank of America whose producer is a consumer image editor is not what it says it is.

The honest part: metadata alone is noisy. In our own testing, metadata-only findings ran about 32% false positive, and 26 of 38 flagged the library pdf-lib, which turned out to be innocent. Chase, Bank of America, Wells Fargo, and Truist password-protect statements, and Dayforce password-protects paystubs. Removing that password legitimately rewrites the file and changes its producer.

So metadata-only findings require at least 0.90 confidence before they surface, and a producer mismatch paired with a plausible enterprise engine is not flagged at all. Conservative by default, because telling a real applicant their real document is fake is a worse error than missing one forgery.

Generator sites leave a fingerprint on every stub they make

There is a small industry selling pay stub templates. Those services leave identifiable traces.

We keep a running list, and a document that came from one flags on intake. This is the cheapest check available and it catches the least sophisticated attempts, which are also the most common.

Year-to-date math: the number that only goes up

YTD earnings increase across a year. Always.

When they do not, or when gross across pay periods does not reconcile to the YTD figure, or when the pay period dates overlap or leave gaps, something was typed rather than calculated.

This is worth checking by hand if you check nothing else. It requires two stubs and arithmetic, and forgers get it wrong more often than you would expect, because generating internally consistent YTD across multiple periods takes more care than changing one number.

Browser-generated PDFs: print-to-PDF looks nothing like payroll output

Real payroll systems emit structured PDFs with consistent internal signatures: embedded fonts, defined object structures, predictable layout trees.

A "print to PDF" from a browser produces something structurally different. Flattened, differently organized, often with the browser's own rendering engine named in the producer field.

An applicant who logged into a real payroll portal and printed the page is generating a technically suspicious file from a legitimate source, which is exactly why this signal is weighted rather than treated as proof.

Document misclassification: the wrong document, submitted as the right one

Not fraud, exactly, but it defeats verification just as effectively.

An offer letter submitted where a pay stub was required. A year-end summary instead of a current statement. A non-US bank statement. These get caught by classifying what the document actually is rather than trusting the filename or the upload slot.

What none of this replaces

Reading documents is the fallback path, not the primary one.

The stronger answer is not to read a document the applicant controls. Connecting the applicant's bank or payroll account directly through Plaid means the income figure comes from the institution. There is no document to forge.

Document analysis exists for applicants who cannot or will not link an account, which is a real and legitimate population: cash-paid workers, some gig workers, guarantors. For them, forensics is the best available tool, and it is the reason ProofUp flagged 9,600 fraudulent documents across the ResProp portfolio.

What to do on Monday

If you review documents by hand today, add two checks that cost nothing:

Verify YTD across two consecutive stubs. Gross times pay periods should reconcile.

Open the PDF properties and read the Creator and Producer fields. If a stub claiming to be from ADP was produced by an image editor, you have your answer in ten seconds.

Beyond that, the byte-level checks are not something a human can do reliably at 10 applications a day, which is the actual reason this fails at scale rather than any lack of diligence.

How many of your last hundred approvals had income verified from the source rather than from a document?