Pay stub fraud sits at the front of the income file
Telling real vs fake pay stubs apart is now a core underwriting skill, not a fraud-team specialty. The pay stub is the most commonly doctored document in consumer and small-ticket lending for a simple reason: it is the document that most directly moves the decision. Inflate the income, and the debt-to-income ratio passes, the affordability test clears, and the loan funds. Unlike a bank statement, a pay stub is short, structurally simple, and issued by tens of thousands of different employers in thousands of formats, which gives a fraudster cover. A reviewer who would notice an off-template Chase statement has no mental template for the payroll format of a 40-person logistics company.
The good news: pay stubs are also one of the most checkable documents in the file. They carry internal math that has to reconcile, statutory deductions that have to be plausible, and a paper trail that has to agree with the bank statement sitting next to them in the same application. Most fakes fail at least one of those tests. This guide covers the red flags that separate real pay stubs from doctored ones, a manual reviewer checklist, the verification methods that bypass the document entirely, and how to automate the whole stack so the checks run on every file instead of the files someone had time for.
It pairs with our guide on detecting fake bank statements: in practice the two documents are checked together, and the strongest signal is usually the disagreement between them.
Why faking a pay stub got easy
Search "pay stub generator" and you will find dozens of sites that produce a clean, professional stub in under five minutes for a few dollars. Many exist for legitimate reasons: small employers and self-employed people genuinely use them to document pay. That legitimate use is exactly what makes them dangerous, because a generator-produced stub is not a forgery in the classic sense. The fonts are consistent, the layout is professional, and the math often reconciles, because the generator computes it.
The second route is direct editing. A borrower takes a genuine stub, opens it in a PDF editor, and changes one number: the gross pay. This is the cheaper, lazier route, and it leaves more evidence, because the edited number now disagrees with everything the fraudster did not think to change: the year-to-date column, the tax withholdings, the net pay, and the deposit that lands in the bank statement.
The third route is fabrication with generative tools, the same trend we see across document fraud. These fakes are the hardest to catch visually and the easiest to catch structurally, because the model invents details (tax rates, deduction codes, pay calendars) that a real payroll system would never produce.
Nine red flags that separate real pay stubs from fake ones
Each of these is checkable today with a PDF reader and a calculator. Automation makes them faster and consistent; the logic is the same either way.
1. Gross-to-net math that does not reconcile
A real pay stub is the output of a payroll engine, and payroll engines do not make arithmetic errors. Gross pay minus taxes minus deductions must equal net pay, to the cent. Recompute it on every stub. A surprising share of edited stubs fail this single check, because the fraudster changed gross pay and net pay but not the withholdings in between. If hours and an hourly rate are shown, multiply them: rate times hours must equal the period gross.
2. Year-to-date figures that do not add up
The YTD column is the fraudster's nightmare. YTD gross divided by the number of completed pay periods should approximate the per-period gross. Across two consecutive stubs, YTD must increase by exactly the period amount. A stub dated in October showing YTD income equal to three pay periods, or a YTD figure smaller than the current period's gross, is fabricated. Always request two or three consecutive stubs rather than one: consistency across stubs is far harder to fake than a single document.
3. Missing or implausible statutory deductions
Every jurisdiction imposes mandatory payroll deductions: income tax withholding, social security or pension contributions, health or employment insurance. A stub with no statutory deductions at all is a red flag almost everywhere. So is a withholding rate that is implausible for the stated income, in either direction. Generators often default to generic rates that fit no real jurisdiction, and editors who inflate gross pay rarely recompute the withholdings to match the new bracket.
4. Round numbers everywhere
Real payroll output is messy. Tax withholdings come out to odd cents. Net pay is almost never a round figure. A stub showing gross of 5,000.00, taxes of 1,000.00, and net of 4,000.00 is telling you it was typed by a human. One round number can be a coincidence. A column of them is a pattern.
5. Font, alignment, and template tells
Zoom to 400% on the figures. An edited stub often renders the altered number in a near-but-not-identical font, because the editing tool substituted a system font for the embedded one. Check that columns align on the decimal point, that spacing between rows is uniform, and that the altered field does not sit a pixel higher than its neighbors. Generator stubs have their own tell: a generic, vendor-less template. Real stubs from major payroll providers (ADP, Paychex, Gusto, SAP, local equivalents) follow recognizable layouts with provider branding, document codes, and consistent field placement.
6. Employer details that do not check out
Verify the employer exists: registry lookup, website, a phone number sourced independently rather than taken from the stub. Check the employer's address is real and matches the registry. Check the employer identification or tax number follows the correct format for the jurisdiction. Misspelled company names, residential addresses for a claimed 200-person employer, and tax IDs with the wrong digit count are all common in fabricated stubs.
7. Pay dates that do not follow a real payroll calendar
Payroll runs on a calendar: weekly, biweekly, semi-monthly, or monthly. Map the pay dates across the stubs provided. Dates that drift between cadences, periods that overlap, or a pay date falling on a Sunday or public holiday when the employer's payroll would shift it, all suggest the dates were invented rather than generated.
8. PDF metadata anomalies
Open the document properties. A stub produced by a payroll platform carries that platform's producer signature, not "Microsoft Word" or a consumer PDF editor. A modification date after the creation date, or a creation date that postdates the claimed pay date by months, deserves an explanation. Metadata can be scrubbed, so treat clean-but-empty metadata as a yellow flag to pair with other signals, not proof either way.
9. The bank statement does not agree
The highest-yield check in the file. Net pay on the stub should appear as a deposit in the borrower's bank statement, on or near the pay date, with an employer descriptor that matches the claimed employer. No matching deposit, a deposit that differs from net pay, or salary arriving as a cash deposit from an employer that claims direct deposit: each is a stronger signal than anything inside the stub itself. This is why income documents should never be reviewed in isolation; see our guide to bank statement analysis software for the other half of the cross-check.
The manual reviewer checklist
For teams running this by hand, the sequence that catches the most fraud per minute of review:
| Step | Check | Fail looks like |
|---|---|---|
| 1 | Recompute gross minus deductions equals net | Any mismatch, even cents |
| 2 | YTD divided by completed periods vs period gross | Ratio far from 1, or YTD below current period |
| 3 | Consecutive stubs: YTD increments exactly | Gaps, jumps, or identical YTD across periods |
| 4 | Statutory deductions present and plausible | No withholdings, or rates fitting no bracket |
| 5 | 400% zoom on fonts and decimal alignment | One row rendered differently from its neighbors |
| 6 | Employer registry, address, tax ID format | Unregistered employer or malformed ID |
| 7 | PDF metadata: producer, dates | Consumer editor, modification after pay date |
| 8 | Net pay matches a bank statement deposit | Missing, mismatched, or cash-deposit salary |
Budget five to eight minutes per file done properly. That is the real constraint: not skill, but time at volume. Which is why most lenders only run the full sequence on files that already look suspicious, and why fraud that looks clean sails through.
Beyond the document: verification that bypasses the stub
When the stakes justify it, verify income without trusting the document at all. Employer verification by phone, using a number sourced from the registry or the employer's website, remains effective and cheap. Payroll-linked verification providers (The Work Number, Argyle, Pinwheel, and regional equivalents) pull employment and income data directly from payroll systems with borrower consent. Tax transcripts and filed returns provide a slower but authoritative cross-check for larger tickets, and they matter doubly in property lending, where doctored income documents are a recurring theme; see our guide to mortgage fraud red flags.
Coverage is the catch. Payroll-linked verification covers salaried employees of larger employers well, and covers gig workers, informal-sector earners, and employees of small businesses poorly, which in many markets is most of the applicant pool. Document-based verification is not going away. It has to get better.
Automating pay stub fraud detection
Every check above is mechanical, which means every check above is automatable. Modern document intelligence reads the stub regardless of quality (a photographed printout, a scan, a screenshot), extracts the structured fields, and runs the full battery on every file: gross-to-net reconciliation, YTD consistency across stubs, deduction plausibility, font and tampering forensics, metadata analysis, and the cross-document match against the bank statement deposits in the same application. The difference from manual review is not intelligence, it is coverage: 100% of files get the eight-step treatment, not the suspicious-looking minority. For the underlying technology distinction, see document intelligence vs OCR.
This is where we should say plainly what Floowed does, because income-document fraud is squarely inside our lane. Floowed's Document Intelligence reads pay stubs and the rest of the loan file at any quality, including handwritten, scanned, and photographed documents, and produces fraud signals: tampering forensics, internal-math failures, cross-document inconsistencies, and evidence cross-checks between what a document claims and what the image actually shows. Those signals then feed the Decisioning Engine, where credit and risk teams write the response into policy: decline on reconciliation failure, refer on metadata anomaly, require payroll-linked verification when the deposit match fails. Same policy. Every application. Every time. No exceptions.
Make the signal change the decision
A fraud signal that lands in a queue is a cost. A fraud signal that changes the decision is a control. The failure mode we see most often is a lender with decent detection and no enforcement: the flag fires, the file waits, a busy reviewer overrides it under volume pressure, and the loss arrives anyway. The fix is to treat fraud signals as decision variables inside the credit policy, with the same versioning and audit trail as a score cutoff. Verified income, not stated income, should be the number your affordability rules consume, which is also the foundation of cash flow underwriting. For how signals, scores, and rules fit together in one flow, start with what loan decisioning is.
FAQ
What is the fastest single check for a fake pay stub? Recompute gross minus deductions equals net, then check the net against the bank statement deposit. Together they take two minutes and catch the majority of low-effort fakes.
Are pay stubs from online generators always fraudulent? No. Small employers and self-employed borrowers use them legitimately. A generator-format stub means the document carries little evidentiary weight on its own, so verify the income through deposits, tax records, or payroll-linked verification instead.
How many pay stubs should we request? At least two consecutive, ideally three. Cross-stub consistency (YTD increments, stable employer details, regular pay calendar) is much harder to fake than any single document.
Can AI-generated pay stubs pass these checks? They pass the visual ones and increasingly get the internal math right. They still fail the external checks at high rates: registry lookups, deposit matching, payroll-calendar plausibility, and jurisdiction-correct withholding rates. Structure beats appearance.
What should we do when a stub fails a check? Follow policy, not instinct. Decline or condition per your written rules, document which signals fired, and route to your fraud team for any reporting obligations in your jurisdiction. Never tip off the applicant about the specific tell.
Does automated pay stub checking replace the underwriter? No. It replaces the mechanical fifteen minutes so credit and risk teams spend their judgment on the files that earn it: the genuine edge cases, not the arithmetic.
The document is evidence, not truth
The mindset shift that matters: a pay stub is a claim about income, not proof of it. Real vs fake is established by reconciliation, by cross-document agreement, and by external verification, never by how clean the PDF looks. Lenders that run those checks on every file, automatically, with the response written into enforced policy, take the doctored-income loss line down without slowing the honest majority of applicants.
That is the stack Floowed runs: Document Intelligence that reads any-quality income documents and flags what does not reconcile, feeding a Decisioning Engine that applies your policy identically on every application, with full audit trail. Start free or book a demo and bring your worst pay stub.