Contract Fraud: How Altered PDFs Bypass Legal Review

A service agreement arrives by email. Legal reviews it, confirms the terms match the negotiated deal, and routes it for signature. Two weeks later, a dispute reveals that the payment terms in the executed copy differ from the version legal reviewed. The net-30 clause now reads net-60. The liability cap changed from $500,000 to $50,000. The bank account number in the payment instructions section points to a different institution.

The contract was modified between review and execution — or between execution and filing. Nobody noticed because nobody checked the file itself. They checked the words on the page. This is how contract fraud through PDF alteration works: the document looks correct while the file contains a different record.

Why Contracts Are a Prime Target

Contracts are high-value documents processed under time pressure by people who read text, not file structure. This combination makes them one of the most effective targets for PDF-level fraud.

The economics are straightforward. A single altered payment term on a $2 million service agreement can redirect hundreds of thousands of dollars. A changed liability clause can shift millions in exposure during a dispute. Unlike invoice fraud — where amounts are typically in the tens of thousands — contract fraud operates at the scale of the underlying deal.

The detection gap is equally straightforward. Legal teams review contracts by reading them. They compare the current version against the last redline they remember, or against a summary of negotiated terms. What they do not do is inspect the PDF’s binary structure to determine whether the file was modified after the version they approved.

According to the Association of Certified Fraud Examiners’ 2024 Report to the Nations, document alteration and forgery account for a significant share of occupational fraud cases, with a median loss of $150,000 per incident. Contract manipulation specifically — altering terms after agreement — falls into the highest-loss category because the altered document becomes the binding instrument. For a broader view of why PDF authenticity matters across business operations, the problem extends well beyond legal.

Three characteristics make contracts uniquely vulnerable:

• Time pressure. Deal closings have deadlines. Legal teams approve final versions under schedule pressure, reducing the likelihood of catching subtle changes between versions.
• Version proliferation. A typical contract goes through 5–15 drafts. By the final version, reviewers are fatigued and rely on tracked changes — which only reflect changes the editing party chose to track.
• Trust in the signature. Once a contract is signed, the assumption is that the signed version matches the agreed terms. Re-reading a signed contract line by line is rare. Re-verifying its file integrity is rarer still.

Three Contract Fraud Scenarios

Changed payment terms after signing

A vendor and a buyer execute a service agreement with net-30 payment terms. The vendor’s accounts receivable team files the signed PDF. Six months later, in a payment dispute, the vendor produces a copy of the “executed agreement” showing net-60 terms — giving them grounds to claim the buyer is in breach for late payment.

The alteration: after the contract was signed and distributed, someone on the vendor side opened the PDF in an editing tool, changed “30” to “60” in the payment terms clause, and re-saved. The visual output is identical to the original in every other respect. If the buyer did not retain their own copy — or if their copy was also sourced from the vendor — the altered version becomes the only version of record.

Altered liability clauses

During M&A due diligence, a target company provides executed contracts with key customers. One contract contains a limitation of liability clause capping exposure at $5 million. The acquirer relies on this cap in their valuation model. Post-acquisition, a dispute arises, and the customer produces the “original” contract showing a $50 million cap — or no cap at all.

The alteration required changing a single number in one clause. The rest of the 40-page agreement is untouched. No one re-reads a 40-page contract in due diligence to verify that every figure matches what was represented. The file structure, however, recorded the modification.

Modified bank details in service agreements

This pattern mirrors invoice fraud but at contract scale. An attacker intercepts a signed service agreement in transit — via compromised email or a man-in-the-middle attack on a document sharing platform — and changes the bank account number in the payment instructions section. The counterparty receives what appears to be the executed agreement and begins making payments to the altered account.

Because service agreements often govern payment relationships lasting months or years, the fraud may not surface until a significant sum has been redirected. The mechanics of this attack are identical to how criminals modify invoice PDFs — but the dollar amounts are orders of magnitude larger.

How PDF Alteration Works: What Editing Leaves Behind

Every scenario above involves the same technical action: opening an existing PDF, changing content, and saving. The PDF specification makes this action structurally detectable regardless of how the visual output looks.

Cross-reference tables and incremental updates

When a PDF is created, the generating software writes a cross-reference (xref) table that maps every object in the file to its byte offset. When the file is subsequently edited and saved, the editing software appends a new xref section to the end of the file rather than rewriting the original. This is the PDF incremental update mechanism — designed for efficiency, but forensically significant.

A contract generated once by a document management system has one xref section. The same contract opened in an editor and re-saved has at least two. The original content remains in the file; the appended section contains the modified objects and a new xref pointing to them.

For a detailed breakdown of this structure, see The Anatomy of a Modified PDF.

Metadata divergence

The PDF Info dictionary stores a Creator field (the application that originally produced the document) and a Producer field (the software that last processed it). A contract generated by DocuSign’s signing platform shows a Creator and Producer consistent with DocuSign’s internal PDF generation library. If someone opens that file in iLovePDF or Smallpdf and re-saves it, the Producer field changes to reflect the editing tool.

The CreationDate and ModDate fields show a similar divergence. A contract signed on March 1 with a modification date of March 15 was edited two weeks after signing. The 15-second tolerance built into forensic analysis accounts for normal software behavior during generation — a two-week gap does not fall within that tolerance. For a full breakdown of these fields and what they reveal, see the PDF metadata field reference.

Post-signature modifications

This is the highest-confidence signal in contract forensics. When a PDF is digitally signed, the signature cryptographically binds to a specific byte range of the file. Content appended after the signature — via incremental update — exists outside the signed byte range. The file now contains both signed and unsigned content.

HTPBE detects this pattern with certain confidence. A contract that was signed and then modified is reported with the MODIFICATIONS_AFTER_SIGNATURE marker. This is not a probabilistic assessment — it is a binary structural fact. The signed byte range does not extend to the end of the file.

The Two Highest-Confidence Signals

Not all modification markers carry equal weight. For contract verification, two markers produce certain confidence — the highest level in HTPBE’s 5-layer analysis:

Modifications after digital signature

Marker: MODIFICATIONS_AFTER_SIGNATURE Confidence: certain

The digital signature in a PDF covers a defined byte range. When content is appended after the signature, the new xref section and its objects sit outside that range. The signature itself remains cryptographically valid for the bytes it covers, but the document now contains unsigned content that was added after the signing event.

This is the single most reliable signal in contract fraud detection. It is impossible to produce this pattern through normal document generation. It requires an explicit post-signature edit.

Signature removal

Marker: SIGNATURE_REMOVED Confidence: certain

A more aggressive approach: the attacker removes the digital signature entirely before making changes, so the modified document does not show a broken or invalidated signature. The absence of a signature that was previously present is itself detectable — the file structure retains traces of the signature dictionary and its associated objects even after removal.

Both signals are structural facts, not heuristic assessments. When either appears in a contract verification result, the appropriate response is immediate escalation — not additional review.

For a deeper understanding of how digital signatures and metadata analysis complement each other, see Digital Signatures vs. Metadata: What Proves PDF Authenticity.

API Integration in Legal Workflows

The practical integration point for contract verification is between document receipt and human review — or between signing and filing. The pattern works with any contract management platform that supports webhooks or post-processing hooks.

DocuSign / contract management webhook pattern

When a signed contract is returned from an e-signature platform, the webhook payload includes a URL to the executed PDF. Before filing the document in your contract management system, send it through HTPBE:

import requests

def verify_signed_contract(document_url: str, contract_id: str) -> dict:
    """
    Verify a signed contract PDF before filing.
    Called from a DocuSign/PandaDoc/Ironclad webhook handler.
    """
    response = requests.post(
        "https://api.htpbe.tech/v1/analyze",
        headers={
            "Authorization": "Bearer YOUR_API_KEY",
            "Content-Type": "application/json",
        },
        json={"url": document_url},
    )
    result = response.json()

    if result["status"] == "modified":
        markers = result.get("modification_markers", [])
        certain_signals = [
            "MODIFICATIONS_AFTER_SIGNATURE",
            "SIGNATURE_REMOVED",
        ]
        is_critical = any(m in certain_signals for m in markers)

        return {
            "contract_id": contract_id,
            "action": "escalate" if is_critical else "flag_for_review",
            "check_id": result["id"],
            "markers": markers,
            "confidence": result.get("modification_confidence"),
        }

    if result["status"] == "inconclusive":
        return {
            "contract_id": contract_id,
            "action": "flag_for_review",
            "check_id": result["id"],
            "note": f"Consumer software origin: {result.get('producer')}",
        }

    # intact — file for the record
    return {
        "contract_id": contract_id,
        "action": "file",
        "check_id": result["id"],
    }

The check_id is stored alongside the contract record. If a dispute arises months later, the forensic report is retrievable via GET /api/v1/result/{check_id} — providing a timestamped integrity record that was created at the moment of filing.

Decision matrix for legal ops

The inconclusive verdict deserves specific attention in the legal context. Contracts are institutional documents — generated by contract management platforms, e-signature tools, or law firm document systems. A contract PDF whose Producer field shows a consumer PDF editor is not necessarily fraudulent, but it is anomalous. Legitimate contracts do not typically pass through Smallpdf or iLovePDF during their lifecycle.

What This Approach Does Not Catch

Binary forensic analysis is not a complete contract fraud prevention system. The following are its boundaries:

Pre-signing alterations made in the same tool. If an attacker modifies contract terms in Microsoft Word before converting to PDF, the resulting PDF is a clean single-revision file. There are no incremental updates, no metadata divergence, no post-signature modifications. The file is structurally indistinguishable from a legitimate contract. This is why version control and redline comparison remain necessary for pre-execution review.

Contracts fabricated from scratch. If someone creates an entirely fake contract in the same software a legitimate party would use, with plausible metadata and consistent timestamps, structural analysis cannot distinguish it from a genuine document. Forensic analysis verifies file integrity, not content truthfulness.

Password-protected PDFs. When a PDF is encrypted and the analysis tool cannot access its structure, the result is inconclusive. The file cannot be read, so its integrity cannot be assessed.

Edits made with forensically aware tools. An attacker who understands PDF structure could edit a document, reset metadata, and reconstruct the xref table to remove traces. This requires specialized knowledge beyond what standard PDF editors provide. It is theoretically possible but rare in practice.

Who Should Integrate Contract Verification

Contract management platforms — Ironclad, Icertis, Agiloft, ContractPodAi — that store and manage executed contracts. Adding a verification step at filing ensures that the stored version is structurally consistent with the version that was signed.

E-signature workflow providers that process signed documents on behalf of clients. Verifying document integrity between the signing event and delivery to the requesting party closes a gap in the chain of custody. This is especially relevant because forensic analysis works without the original file — the received document carries its own modification history.

Legal ops teams running due diligence on contract portfolios — M&A, audit, or compliance reviews where the integrity of hundreds or thousands of executed contracts needs verification at scale.

In-house counsel receiving executed agreements from counterparties. A single API call before filing provides a permanent forensic record of the document’s state at the time of receipt.

The API documentation covers the full request/response specification. For a direct comparison of how HTPBE fits alongside KYC platforms and manual review for legal document workflows, see HTPBE vs. iDenfy vs. Manual Review. For a broader view of how PDF verification fits into legal workflows, see the legal industry overview.

Test API keys are available on all plans — including free — and return deterministic responses for integration testing without consuming quota.