Workers Comp Fraud: Altered Medical and Wage PDFs

The National Insurance Crime Bureau puts US workers’ compensation fraud near $34 billion a year. Claimant-side fraud is a substantial share, and one of the recurring vectors inside it is not the staged injury but the altered document submitted alongside a real one. A wage statement with a higher gross. A treatment note dated a week earlier than it was actually written. A functional capacity evaluation with two restrictions changed from “occasional” to “never”.

These documents reach the claims desk inside large batches. Adjudicators triage hundreds of claims per week and cannot structurally inspect every PDF. SIU sees only the files that are already flagged. Between intake and SIU there is a gap, and the documents that pass through it look right because the fraud is one field deep.

The Three Documents Most Often Altered

1. Inflated Wage Statements

Indemnity benefits in nearly every US state are calculated as roughly two-thirds of the claimant’s average weekly wage in the weeks before the injury. The exact period and cap vary by jurisdiction — 52 weeks in California, 26 in New York, a four-quarter average in Florida — but the lever is the same. Push the stated pre-injury wage up by $200 a week and the indemnity check rises by about $133 a week, every week, for as long as the claim stays open. A two-year temporary total disability claim turns a one-time PDF edit into roughly $13,800 of recoverable fraud per claimant.

The source documents are state-mandated payroll filings: California’s DE 9 quarterly wage report, New York’s NYS-45, Florida’s RT-6, Texas’s C-3, and the certified payroll PDFs employers produce from ADP, Paychex, Gusto, Paylocity, or in-house systems. These platforms typically emit PDFs through stable server-side generators whose producer strings identify them. When a claimant or a complicit employee opens such a PDF in Adobe Acrobat or an online editor, edits the gross-wage column, and re-saves, the file structure usually records the operation: the producer field is overwritten to the editing tool, the creator may still show ADP or Paychex, and the xref table picks up an additional revision layer. Legitimate exceptions exist — a DMS that re-emits the PDF after metadata cleanup, an e-signature platform that appends signature objects — so interpretation depends on the claimed delivery path, not the marker alone.

The structural anomaly is the producer-creator mismatch alongside an extra revision layer on a document that should have left payroll as a single-pass export. Public markers HTPBE_RESIDUAL_PRIOR_GENERATOR and HTPBE_MULTIPLE_REVISION_LAYERS are the typical pair.

2. Backdated Medical Documentation

The causation question in workers’ comp turns on whether the injury arose out of and in the course of employment. Treatment notes generated months after an alleged injury date but timestamped near it are a recurring AOE/COE fraud pattern, sometimes with a compliant provider, sometimes by the claimant editing a real report’s visible date while the file’s internal timestamps tell the truth.

The signal is timestamp disagreement. EHR systems — Epic, Cerner, Athena, eClinicalWorks, NextGen — set CreationDate and ModDate to the same instant on initial export, then leave them frozen unless the document is re-saved through an external editor. A report whose visible body says “date of service: March 14” but whose ModDate reads April 22 was opened and re-saved on April 22. If the producer field has also shifted away from the EHR’s native export string, the document is no longer the bytes the clinical system emitted.

Public marker HTPBE_DATES_DISAGREE fires on the timestamp gap. HTPBE_TOOL_VS_STRUCTURE_MISMATCH fires when the declared producer does not match how the file is actually constructed.

3. Altered DWC-1, PR-2, and FCE Reports

The first-report-of-injury and progress-report PDFs are the AOE/COE evidence trail. California’s DWC-1 (employee claim form), DWC’s PR-2 (primary treating physician’s progress report), and equivalent state forms get altered to shift the reported injury date inside a coverage window, change the body part disputed, or rewrite the mechanism of injury.

Functional capacity evaluations are the other high-leverage document. An FCE is a structured PT assessment, usually exported as a PDF from Casamba, WebPT, Net Health, or Raintree. The report drives the return-to-work decision. A claimant who edits two lift-frequency restrictions from “occasional” to “never” can keep themselves out of modified-duty programs and on full indemnity for months. The edit is one field deep; the structural footprint is a revision layer added on top of the PT software’s original export, with the producer string rewriting to whatever tool the claimant used.

What Visual Review Misses

Adjudicators are trained on plausibility. Does the diagnosis match the mechanism? Does the wage band match the job class? Does the restriction profile fit the injury? These are content judgements and they catch the egregious cases — wages that triple, restrictions inconsistent with the diagnosis, mechanisms that contradict the witness statement.

What visual review does not catch is the single-field edit by someone who understands the form. The wage column that goes from $1,180 to $1,380. The restriction that goes from 25 lb occasional to 10 lb never. The injury date that moves three days inside the coverage window. The content stays internally consistent because the fraudster is careful; the file structure does not, because every save by an external editor leaves a trail. Structural forensics reads that trail — revision history, producer chain, timestamps — rather than the visible content, which is what makes it orthogonal to adjudicator review.

Check It Yourself

If you have a payroll PDF, an FCE report, or a treatment note in front of you and want to see what the structural layer looks like before integrating anything, run it through the free check and look at the producer, creator, xref count, and verdict the report returns. The same analysis runs behind every API call below.

API Response — Altered Wage Statement

{
  "id": "ck_8d4f2c7a-1e9b-4f3c-a6d1-2c8e5b9f0a3d",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": ["HTPBE_MULTIPLE_REVISION_LAYERS", "HTPBE_RESIDUAL_PRIOR_GENERATOR"],
  "creator": "ADP Workforce Now",
  "producer": "Adobe Acrobat Pro 24.1",
  "xref_count": 3,
  "creation_date": 1749081600,
  "modification_date": 1749427200
}

Three xref entries mean three save sessions after the initial generation. ADP Workforce Now exports payroll PDFs in a single pass — the Acrobat producer line and the extra revision layers are inconsistent with that workflow. Route the claim to the SIU queue for confirmation; do not deny it on the structural signal alone.

Backdated PR-2 — modified Verdict

{
  "id": "ck_3b1e7d9c-4a2f-4e8b-b3d0-9f5c2a1e7b4d",
  "status": "modified",
  "modification_confidence": "certain",
  "modification_markers": ["HTPBE_DATES_DISAGREE", "HTPBE_TOOL_VS_STRUCTURE_MISMATCH"],
  "creator": "Epic Systems",
  "producer": "Microsoft Word",
  "xref_count": 2,
  "creation_date": 1741996800,
  "modification_date": 1745539200
}

creation_date corresponds to March 14, modification_date to April 24 — more than five weeks later. Epic exports are not routinely routed through Word in normal clinical workflows. The combination is a strong basis for SIU referral; the referral decision itself still belongs to the desk.

Integration in Java and .NET Claims Stacks

Most legacy workers’ comp claims platforms — Origami Risk, Mitchell Decision Point, Ventiv Claims, Riskonnect, in-house systems at Sedgwick, Gallagher Bassett, and Broadspire — run on the JVM or .NET. The integration point is a pre-processing hook on document ingestion, before the document is attached to the claim record and before reserve is set.

Java (HttpClient):

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://api.htpbe.tech/v1/analyze"))
    .header("Authorization", "Bearer " + System.getenv("HTPBE_API_KEY"))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(
        "{\"url\":\"https://claims.example.com/WC-2026-04921/wage-statement.pdf\"}"
    ))
    .build();

HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

.NET (HttpClient):

using var client = new HttpClient();
client.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", Environment.GetEnvironmentVariable("HTPBE_API_KEY"));

var payload = new StringContent(
    "{\"url\":\"https://claims.example.com/WC-2026-04921/wage-statement.pdf\"}",
    Encoding.UTF8, "application/json");

var response = await client.PostAsync("https://api.htpbe.tech/v1/analyze", payload);
var body = await response.Content.ReadAsStringAsync();

The response includes id, status, modification_markers, producer, creator, xref_count, creation_date, and modification_date. Persist the check id against the claim record. If a payment is later disputed or a fraud investigation opens, GET /api/v1/result/{id} returns the full forensic report as an audit-grade record. The API reference covers the full contract; pricing starts at $15/month for 30 claims, with volume tiers for carriers and TPAs running large books.

Calibration: Trigger SIU Review, Not Automatic Denial

Workers’ comp is a heavily regulated line. California’s Labor Code 5814 imposes 25% penalties on unreasonably delayed indemnity; New York’s WCL 25 enforces similar timing. A direct deny on a structural signal exposes the carrier to bad-faith and unfair-claims-handling claims if the underlying document turns out to be legitimate after all.

The right operational shape is a triage layer:

• modified on a wage statement or medical report — route to SIU review queue. Document the check ID in the claim file. Continue to pay benefits at the unaltered baseline while the investigation runs.
• inconclusive on a document claiming institutional origin (EHR-generated report, payroll software export) — escalate. A treatment note that came out of Epic should not have producer: "Microsoft Word" and a single xref.
• inconclusive on a scanned report or a paper FCE that the clinic faxed and rescanned — expected. Do not flag.
• intact — file structure matches stated origin. Proceed to the adjudicator.

Start every modified and every institutional inconclusive in human review for the first several months. Log the SIU outcome against the structural verdict. Precision and recall numbers become meaningful only when they come out of your own labelled queue, not from a vendor brochure.

For queue-volume planning, a reasonable starting band is that 3–8% of intake documents return modified and another 6–12% return inconclusive on an institutional-claimed source. These are planning assumptions for capacity sizing, not industry benchmarks — the actual distribution is book-specific and shifts with claimant demographics, intake channel mix (portal vs. mailroom vs. fax-rescan), and the share of medical documents from EHR-native exporters vs. clinic-side rescans. Run the check against a recent intake sample before turning it on to size the SIU desk impact accurately.

What Structural Forensics Does Not Catch

Two patterns fall outside this approach, and being clear about them protects against over-trusting the signal.

Print-to-PDF and rescanned documents. A claimant who prints the altered wage statement, files it, and rescans it through the clinic’s MFP ends up with a PDF whose structure no longer reflects the editing operation. The visible content is the altered version; the structural layer is a clean raster scan with no producer chain to analyse. HTPBE? returns inconclusive, which is the correct verdict — out-of-band verification with the issuing employer or provider is the right control. For analogous patterns in lending intake, see PDF fraud detection in loan origination.

Documents fabricated inside the legitimate generating software. A complicit employer who edits the wage report inside ADP itself before exporting produces a PDF that is structurally identical to a clean one. This requires platform-level access most claimant-side fraud does not have, but it exists. The control here is direct wage verification with the carrier’s pre-loss premium audit data, not structural forensics.

The insurance claims PDF fraud breakdown covers the parallel patterns in P&C lines; the payslip fraud HR detection guide goes deeper on the wage-document side specifically.

Where This Fits in a WC Claims Operation

Structural PDF forensics is a pre-triage filter, not a replacement for SIU investigation or adjudicator judgement. Run at the document-ingestion hook, it surfaces structurally anomalous documents on day one rather than after weeks of payments, and lets the SIU desk allocate its time to the claims most worth opening.

The API reference covers integration. The pricing page covers volume. The insurance claims fraud altered PDFs post covers the carrier-platform integration patterns shared across WC and P&C books.

Frequently Asked Questions

Does this replace the SIU desk?

No. It is a pre-triage layer that runs at intake — before the adjudicator picks up the file. The SIU desk still owns the investigation and the fraud-referral decision. What changes is which claims arrive at SIU. Instead of waiting for an adjudicator’s gut feeling or a red-flag rule to surface a claim weeks in, the structurally anomalous documents are flagged on day one.

How does HTPBE? handle a PR-2 progress report that a clinic faxed and the carrier scanned in?

The verdict will be inconclusive because the producer chain is a generic MFP scanner, not the EHR. That is the correct outcome. A scanned PR-2 does not give structural forensics anything to work with — the right control there is out-of-band verification with the treating physician’s office, not a structural signal. The system does not pretend to have certainty it cannot have.

What about fair-claims-handling exposure if we’re wrong?

Use the verdict as a trigger for SIU review, not as a basis for denial or delay. California Labor Code 5814 and equivalent statutes elsewhere penalise unreasonable indemnity delays — the safe operating model is to keep paying baseline benefits while SIU investigates a flagged document. Structural anomaly is a reason to look harder, not a reason to deny.

Can claimants defeat this by being careful?

Some can. A claimant who knows to print the altered document and rescan it produces a PDF that returns inconclusive rather than modified — the structural trail of the edit is gone. This is the correct verdict, not a miss; it tells the SIU desk that out-of-band verification with the issuing provider or payroll department is the next step. Structural forensics catches the editor-altered subset, which is the majority of claimant document fraud but not all of it.