Fake Salary Slip Detection: Catching the Edited Payslip BGV Misses

A candidate clears your interview, accepts the offer, and uploads three months of salary slips to support a higher band. The employer name is right. The CTC divides down to a believable monthly net. The PF deduction is the right percentage, the UAN is present, the company logo is crisp. Your background-verification team reviews the file, finds nothing out of place, and clears the candidate at the band they claimed.

Every step of that review was done correctly. And the salary slip could still be forged.

The salary slip — alongside Form 16 and the offer letter — is the single most commonly faked document in Indian hiring, tenant screening, and lending. It is faked so often because it is both high-leverage and easy to fake: a single edited number moves a candidate’s salary band, a tenant’s eligibility, or a borrower’s approved amount, and the tools to edit it are free and take minutes. This article walks through how salary slips are used, how they get faked, exactly where manual background verification breaks on a well-edited PDF, and the structural forensic layer that catches the edit no matter how plausible the numbers look. It is written for HR operations, background-verification companies, and lenders — in India and anywhere else the salary slip is treated as proof of income.

What a Salary Slip Is Actually Proving

A salary slip is a monthly statement an employer issues showing gross pay, deductions, and net pay for one pay period. On its own it is a payroll record. In practice, three different industries lean on it as a proof-of-income document, and each is making a financial decision off the numbers printed on it.

Hiring and background verification. In Indian recruitment, candidates routinely submit recent salary slips to substantiate their current CTC. The new employer’s offer is anchored to that figure — a candidate who inflates their last-drawn salary by twenty percent can negotiate a materially higher band. Background-verification (BGV) firms are hired specifically to confirm that the claimed employment and salary are real.

Tenant screening. Landlords and property managers ask prospective tenants for salary slips to confirm they earn enough to cover rent. The common rule of thumb — rent should be a fixed fraction of monthly income — means a slightly inflated net salary turns a borderline applicant into an approved one.

Lending. Personal-loan, credit-card, and consumer-finance underwriters use salary slips to size the loan and price the risk. The approved amount is often a multiple of monthly net income, so the document directly drives how much money is lent.

In all three, the decision is keyed to a number on a page. That is exactly what makes the salary slip worth forging — and worth checking properly.

How Salary Slips Get Faked

There are two distinct fraud patterns, and they fail very differently under review.

Pattern one: the editable template. A fraudster downloads a “salary slip format” — a Word or Excel template, or one of the many online “fake salary slip generator” sites — fills in an employer name, an invented salary, a plausible PF deduction, and exports a PDF. The document never corresponded to any real payroll run. It was fabricated from a blank.

Pattern two: the edited real slip. This is the harder one. The fraudster starts with a genuine salary slip — their own, issued by their actual employer — opens it in a desktop or online PDF editor, and changes one or two numbers. They raise the net pay, adjust the gross to match, recompute the deductions by hand so the arithmetic still reconciles, re-save, and submit. The layout is the employer’s real template. The logo is real. The fonts are right. Every visible field except the edited ones is genuine.

Pattern two is the one that defeats careful reviewers, because the fraudster had the original document in front of them and every opportunity to make the edit internally consistent. They can match the PF percentage. They can keep the net-from-gross math correct. They can avoid the suspiciously round numbers reviewers are trained to notice. A patient forger produces a file that passes every content check on the BGV checklist — because the content was tuned specifically to pass those checks.

Why Manual BGV Review and PF/UAN Checks Don’t Catch a Well-Edited PDF

Background verification is a layered process, and a competent team runs real, valuable controls. It is worth being precise about what those controls do — and where they stop.

Employer callback and employment confirmation. The BGV team contacts the employer’s HR to confirm the candidate worked there, in the stated role, over the stated period. This is one of the strongest checks available and it should continue.

PF and UAN cross-checks. In India, the Universal Account Number (UAN) and the EPFO passbook let a verifier confirm that provident-fund contributions were actually made against the candidate’s name. A salary slip that claims a PF deduction the passbook doesn’t reflect is a genuine red flag. Again — valuable, and worth keeping.

Bank-credit cross-check. Some lenders and BGV firms cross-reference the net salary on the slip against the salary credit visible on the candidate’s bank statement. If the slip says one number and the bank credit shows another, the story falls apart.

Manual review of the document itself. A reviewer scans the slip for arithmetic that doesn’t reconcile, mismatched fonts, suspiciously clean figures, or formatting that looks wrong.

Read that list and notice the common thread: every one of these controls verifies whether the information is plausible or corroborated. Does the employer confirm the role? Does PF reconcile? Does the bank credit match? Does the math add up? These are content questions. They ask, “Could a real payroll run have produced these figures?”

None of them ask the other question: “Was this file edited after the employer generated it?”

That gap is where the edited-real-slip forger lives. Consider how the manual checks fare against pattern two:

• Employer callback is powerful — but it is slow, it isn’t run on every applicant, and in high-volume tenant screening or instant-lending flows it often isn’t run at all. Many fraud cases clear precisely because the callback was skipped for speed.
• PF/UAN checks confirm that employment and contributions exist. They do not confirm the salary number printed on this particular PDF. A fraudster who genuinely works at the company — and has a real UAN — can edit the net-pay figure on a real slip, and the UAN check still passes, because the underlying employment is real. The forgery is in the number, not in the existence of the job.
• Bank-credit cross-check only works when you actually have the bank statement, and when the fraudster hasn’t also edited that. Bank statements are themselves the most-forged document in lending, so a coordinated forger edits both to agree with each other.
• Manual review is defeated by design. On screen, an edited number is indistinguishable from an original one — the PDF editor renders it in the same font, at the same position. The human eye has nothing to catch. And awareness of “fake salary slip generator” sites doesn’t help: that awareness trains reviewers to spot fabricated-from-scratch templates (pattern one), while pattern two starts from a genuine employer document and never touches a generator site.

So the honest picture is this: manual BGV and PF/UAN verification are good controls that catch fabricated templates, inconsistent stories, and salaries that don’t corroborate against other sources. What they were never built to see is a single number typed over a genuine slip in a PDF editor. That edit is invisible to a process designed to verify content rather than file integrity.

The Missing Layer: Structural PDF Tamper Detection

A PDF is not a flat picture. It is a structured file that carries an internal record of how it was built and saved — when it was created, what software produced it, whether it was written to disk once or many times, and whether anything was changed after a digital signature was applied. When someone opens a genuine salary slip and saves an edit, that act leaves traces in the file’s structure — regardless of how plausible the visible net-pay figure is.

Structural tamper detection reads that internal record and returns a verdict. It never asks whether ₹85,000 is a believable salary — that is the BGV team’s job and the content layer’s job. It asks whether the file’s own construction is consistent with a clean, single-pass export from a payroll system, or whether it bears the marks of having been opened and re-saved in an editing tool after the fact.

HTPBE? is a self-serve API that performs exactly this analysis. You send it a PDF; it returns one of three verdicts plus a list of named markers describing what it found. It is not a KYC or identity-verification vendor and was never meant to be one. It answers a single, narrow question: was this file altered after it was created? That makes it additive — it sits alongside your employer callbacks, your UAN checks, and your bank cross-checks, covering the one case they cannot see.

The three verdicts

• intact — no evidence of post-creation modification, and the file looks like a genuine institutional export from a payroll or HR system. The structural layer found nothing to flag.
• modified — the file carries forensic evidence that it was changed after it was first generated. This is the case that matters most: a slip that should be a clean payroll export but instead shows the fingerprints of an editing session.
• inconclusive — the file was produced by consumer software, an online editor, or a scanner, so there is no institutional baseline to check integrity against. This is not a pass and not an automatic reject. It is a routing signal — and for salary slips specifically it needs careful handling, because a great many genuine Indian salary slips are produced by consumer tools. More on that below.

What it actually catches — in plain terms

Without writing a how-to for forgers, here is the kind of structural evidence the analysis surfaces, described as outcomes rather than recipes:

• Editing-tool fingerprints. A payroll system produces its slips through a server-side institutional pipeline. When a file instead carries the signature of a consumer PDF editor or an online conversion service, that origin is inconsistent with how a payroll system emits documents. The marker HTPBE_EDITING_TOOL_FINGERPRINT flags this.
• Disagreeing internal timestamps. A clean export’s internal creation and modification timestamps line up. When they contradict each other — the file claims one creation date but was last written days later — that gap is recorded structurally even though it is invisible on the page. HTPBE_DATES_DISAGREE covers this.
• Multiple revision layers. Each time a PDF is edited and saved, the change is appended as a new layer on top of the original. A slip that should have been generated in a single pass but instead shows several stacked write sessions reveals that it was modified after creation. The marker is HTPBE_MULTIPLE_REVISION_LAYERS.
• Targeted character-level edits. When specific characters — the digits of a salary figure — were overlaid or replaced after the document was authored, the analysis can surface that pattern. The markers here include HTPBE_CHARACTER_OVERLAY_EDIT and HTPBE_GLYPH_LEVEL_EDIT.
• Producer identity that has been overwritten or spoofed. Some tools try to disguise their involvement by rewriting the file’s stated generator. When that identity has been overwritten or forged to imitate an institutional origin, the analysis flags it (HTPBE_IDENTITY_OVERWRITTEN, HTPBE_PRODUCER_IDENTITY_FORGED).
• Tampering around a digital signature. Where a slip is digitally signed — some corporate payroll systems sign theirs — the analysis detects content changed after signing (HTPBE_POST_SIGNATURE_EDIT) or a signature stripped off entirely (HTPBE_SIGNATURE_REMOVED). These are among the most conclusive signals there are.

None of these depend on the visible net-pay figure being implausible. A perfectly reconciled, perfectly tidy forged salary still sits inside a file that was edited — and the edit is what gets caught.

Want to see it on a real document? You can drop a salary slip into the free check on this site and get a verdict in a few seconds — no account needed. It’s the same engine the API runs, and it’s a fast way to check a single suspicious slip before you decide whether to add it to your screening pipeline.

What inconclusive Means for Salary Slips — Read This Carefully

The inconclusive verdict confuses people everywhere, and with salary slips it is especially important to get right. Reading it as guilt will generate false positives at scale, because of how Indian payroll actually works.

inconclusive means the file was created in software that anyone can use to build a document from scratch — Word, Excel, an online editor, a print driver, a scanner. Because there is no institutional baseline, the structural layer cannot say whether the content was tampered with. It is telling you, honestly, “I can’t verify integrity here.”

Here is the part that matters: a large share of genuine Indian salary slips are produced by consumer tools. Smaller companies, startups, and many mid-sized firms run payroll on spreadsheets or in-house HR macros and export the slip via Excel-to-PDF or a print-to-PDF driver. There is nothing fraudulent about that — it is simply how a lot of legitimate payroll is done. For those issuers, inconclusive is the correct and expected verdict, and auto-rejecting on it would punish honest candidates and tenants.

So the verdict must be routed on the claimed issuer, not auto-rejected:

• A salary slip claiming to be from a large enterprise with a known institutional payroll system (a major IT services firm, a bank, a multinational) that comes back inconclusive is worth escalating. A real slip from that issuer would carry an institutional baseline; a consumer-software origin is a mismatch worth a second look.
• The same inconclusive verdict on a slip from a small company or startup is routine — exactly what you’d expect — and you treat it as such, falling back to your employer callback and PF/UAN checks.

Used this way, inconclusive is not a dead end and not a verdict you reject on. It is a fork in your workflow that depends entirely on whether the named employer is the kind of organization that produces institutional files.

Honest Limits — What This Layer Cannot Catch

Structural tamper detection is a powerful additional control, not a fraud oracle. Two scenarios sit outside its reach, and a serious screening team should know them.

Documents fabricated entirely from scratch (pattern one). If a fraudster doesn’t edit a real slip but builds a fake one from zero in a tool that produces clean output — a template, a generator site, a fresh Excel export — there is no “original” to compare against and no editing event to detect. Structurally, that file may be a clean single-pass document; it just contains invented data. This is exactly why employer callbacks, UAN cross-checks, and bank-credit reconciliation remain essential — they catch the fabricated-template case that file forensics cannot. The structural layer’s strength is the far more common and far harder case: an edited genuine slip.

Legitimately consumer-generated slips. As covered above, many honest employers export through consumer tools, so inconclusive is the right verdict for them. The signal only carries weight when the claimed issuer has an institutional baseline to deviate from.

Being upfront about these limits is the point. The structural layer slots alongside your existing verification process — catching the edited-PDF case that content checks, PF/UAN reconciliation, and employer callbacks cannot — not replacing any of them. Bank statements share the same fraud mechanics, and many lending teams check both together; the fake bank statement detection use case walks through that workflow in full.

Wiring It Into Your Screening Flow

For teams that decide the structural layer belongs in their process, integration is deliberately small. The pattern is three steps, and there is no numeric risk score to interpret — you get a verdict and named markers.

1. Analyze the uploaded slip. When a candidate, tenant, or borrower uploads a salary slip, send its URL to the analyze endpoint.

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/slips/candidate-7821.pdf"}'

The response is just the check ID:

{ "id": "506a6b1b-1360-48a2-b389-abb346f85d04" }

2. Fetch the verdict. Retrieve the result by ID. The response is a flat object — the fields your policy cares about are status, modification_markers, and modification_confidence.

curl https://api.htpbe.tech/v1/result/506a6b1b-1360-48a2-b389-abb346f85d04 \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "status": "modified",
  "modification_markers": ["HTPBE_CHARACTER_OVERLAY_EDIT", "HTPBE_DATES_DISAGREE"],
  "modification_confidence": "certain"
}

3. Route on the verdict. Wire the three outcomes into your existing screening queue rather than auto-deciding on any single signal:

• modified → route to manual review, request a fresh slip pulled directly from the employer or payroll portal, and run your employer callback. For the most conclusive markers — a post-signature edit, a removed signature — treat it as a hard fail.
• inconclusive → branch on the claimed employer. A consumer-software origin on a slip claimed to be from a large institutional payroll is worth escalating; the same verdict from a small company is routine, and you fall back to PF/UAN and callback checks.
• intact → no structural evidence of alteration; proceed with your normal corroboration.

Store the check ID against the candidate or application record. If a hiring or lending decision is ever disputed — or audited — the forensic result is retrievable as a permanent record showing exactly which structural signals fired.

Who Should Add This Layer

If you run HR operations, a background-verification firm, or a lending or tenant-screening team — anywhere a meaningful share of applicants upload salary slips, Form 16, or offer letters as proof of income — this is the gap in your process worth closing. Your team is already verifying content well: confirming employment, reconciling PF and UAN, cross-checking bank credits. What they cannot see, by design, is whether the PDF in front of them was edited after the employer generated it. That blind spot is exactly where careful fraudsters operate, and it is exactly what a structural layer covers. It is built for India’s salary-slip fraud problem and works the same way on payslips anywhere in the world.

When you’re ready to put a verdict behind your intake, the self-serve API is documented end-to-end, with test keys you can wire up before you spend a credit.