PDF metadata: what the creator and producer fields tell you about a pay stub

A forged pay stub is designed to survive a human reading it. Fonts line up, the math is plausible, the employer logo is right.

None of that effort touches the metadata, because the person making it does not know the metadata exists.

Two fields do most of the work

Every PDF carries a document information dictionary, and two entries in it matter for this.

Creator names the application that authored the original content. A payroll system writing a stub puts its own generator there, and it is the same string on every stub that system has ever produced.

Producer names the library or engine that wrote the actual PDF bytes. This is the more reliable of the two, because it is set by the PDF-writing layer rather than by whatever assembled the content.

The signal is not that a particular producer string is bad. It is that a real payroll provider's output is boringly consistent, and a document claiming to come from that provider while carrying a different producer string has a story that does not hold together.

The check is a whitelist, not a blacklist

This is the distinction that decides whether metadata checking works at scale.

A blacklist approach collects known-bad producer strings, which means keeping up with every document generator that exists and losing every time a new one appears.

A whitelist approach records what each real payroll provider and each real bank actually emits, then flags anything claiming to be from that source while emitting something else. Curating that list takes ongoing work and it is bounded, because the number of real payroll providers is finite and the number of forgery tools is not.

ProofUp checks producer fingerprints against a curated whitelist of what each real bank and payroll provider actually emits. Building that list is most of the work in this check and it is why the check keeps working as new forgery tools appear.

The pattern that shows up most often

Not a sophisticated forgery tool. A browser.

Somebody opens a real stub or a template, edits it in a word processor or in a web form, and prints to PDF. The producer string then names the browser's print engine or the word processor rather than the payroll system.

That is the single highest-volume signal in this category, and it is invisible to a human reviewer looking at a rendered page, because the rendered page looks fine. A browser-generated file claiming to be a payroll system's output is a mismatch you either check for or do not.

Timestamps that contradict the document

Two dates worth comparing.

CreationDate against the pay period. A stub for a period ending June 15 with a creation date of June 2 was made before the period it reports on ended.

ModDate against CreationDate. A real payroll PDF is written once and not modified. A meaningful gap between creation and modification means the file was opened and saved by something, and the question is what.

Neither is conclusive alone. A stub regenerated from a payroll portal months later will legitimately have a recent creation date, which is why this check informs a verdict rather than producing one.

Incremental updates leave the original behind

Worth knowing because it produces the strongest evidence in the whole category.

The PDF format supports incremental saving, where an edit appends new objects rather than rewriting the file. The original objects stay in the bytes.

A file edited that way can contain both the original number and the replacement, and a parser reading the full object tree rather than only the rendered page can find both. Two conflicting values for the same field, in one file, is not ambiguous.

This is the byte-level part of forensic analysis, and it is the reason reading the file matters more than reading the page.

What metadata cannot tell you

Being straight about the ceiling here, because overselling this specific check is how document forensics gets a reputation for false positives.

Clean metadata does not mean the document is real. A forger who regenerates a file through a tool that produces a plausible producer string passes this check. Metadata is one input among several, and a platform treating it as dispositive will fail honest applicants and clear sophisticated ones.

It also cannot tell you whether the numbers are true. A perfectly authentic pay stub from a real payroll system can report income from a job the applicant started last week and will leave next month. Authenticity and accuracy are different questions, and only one of them is a document problem.

Which is the argument for connecting to the account rather than analyzing the document. When an applicant links their bank or payroll account directly, the income figure comes from the institution instead of from a file the applicant controls, and the entire forensic question stops applying. Document analysis is the path for applicants who cannot or will not link, and it is a fallback rather than the primary answer.

Where our own numbers stand

9,600 fraudulent documents flagged across the platform. Verdicts return in two to three minutes with the specific signal behind every flag, plus a per-attempt audit trail, because a flag with no stated reason is not something a leasing agent can act on or defend.

New forgery patterns get converted into deterministic detection logic, which means a pattern found on one portfolio becomes a permanent rule for every customer rather than staying a one-off catch.

Open one PDF properties dialog

Take a pay stub from your last approved application. In any PDF reader, open document properties.

Look at the producer field. If it names a browser or a word processor rather than a payroll system, you have your answer, and it took eleven seconds.

What did yours say?