Digital Tampering Detection

When enabled, Digital Tampering Detection analyses submitted files for signals associated with manipulation or AI-generated receipt and invoice images. It returns isTampered, tamperedScore, and optional informational details. Build primary decisions on the flag; internal techniques and detail fields may change.

Availability

📘

Availability

Digital Tampering Detection is part of the fraud detection suite, included on the Advanced plan and above. On verbose extraction endpoints, enable Tamper Detection in your account Feature Settings. On validation endpoints, also set fraudDetection.allowTamperDetection: true for the campaign. See Plans & Feature Access.

How It Works

The check returns a boolean recommendation and a numeric score. Optional details may provide diagnostic context, but they are not a stable contract for customer decision logic. Detection behaviour can vary with the file format and submitted document.

Response

{
  "entities": {
    "tamperDetection": {
      "data": {
        "isTampered": true,
        "tamperedScore": 0.87
      }
    }
  }
}

🚧

Detail fields are informational only

Build primary decisions on isTampered when it is present. Optional detail fields may change and should not be treated as a stable decision contract.

Illustrative Tampering Patterns

The six scenarios below retain the examples from the current live guide. Each pair shows an illustrative input and, where present, a historical diagnostic visualisation. Similar-looking files can produce different results, and a returned flag does not establish who changed a document, how it was changed, or why.

🚧

Examples do not define the detection contract

Red and green boxes, difference images, and other diagnostic overlays shown below are not part of the documented response schema. They illustrate these examples only; they do not specify current internal methods or stable detail fields. Build primary decisions on isTampered when present, and treat tamperedScore and optional details as supporting context.

1. Visible Digital Markers and Overlays

Strokes, shapes, or editing layers can obscure receipt content. This example contains bright turquoise marks across several product lines. The image alone does not identify the editing tool or establish intent.

Illustrative input: visible digital marks obscure part of the receipt.

Historical diagnostic visualisation highlighting candidate regions; box colours and positions are not stable response fields.

2. White Text-Box Overlay

A solid text box can cover or replace printed receipt content. In this example, a white rectangle containing new text sits across the product area. This visual pattern may contribute to the overall recommendation, but it does not promise a particular optional detail field.

Illustrative input: a white text box replaces part of the printed product area.

Historical diagnostic visualisation highlighting the overlaid area; it is not a guaranteed result for similar documents.

3. Copy-Pasted Digits

Copied or replaced digits can change a visible item price, total, date, or other transaction value. Here, the first item amount has been altered to resemble other digits on the receipt. A visually similar repetition can also have an innocent cause, so use the returned recommendation in your wider review workflow.

Illustrative input: repeated digit shapes alter a visible product amount.

Historical diagnostic visualisation of candidate regions; it does not expose a stable copy-paste detector contract.

4. Error-Level Analysis Illustration

The live example pairs a receipt with a replaced merchant-header area and an error-level-analysis-style difference image. It is retained to show how compression differences can be visualised, not to confirm that this exact technique runs for every file. The difference image is not part of the documented API response.

Illustrative input: the merchant-header area differs from the surrounding receipt.

Historical error-level-analysis-style visualisation; it is illustrative diagnostic material, not API output.

5. Synthetic or Template-Generated Receipt

A receipt can be digitally constructed from a template rather than photographed from a physical document. Generated layouts may contain repeated, inconsistent, or unnatural text and formatting, but appearance alone does not establish authenticity. See AI-Generated Receipt and Invoice Detection for how this analysis fits within Tamper Detection.

Illustrative input: a digitally constructed receipt rather than a photograph of a physical document.

Historical diagnostic visualisation of candidate regions; it does not guarantee the same result for another generated receipt.

6. AI-Generated Receipt Examples

These two images were presented in the live guide as AI-generated receipt examples. They show how a generated document may imitate a photographed receipt or produce a cleaner generic layout. The examples do not identify stable visual signatures, attribute output to a guaranteed model, or promise that every generated image will be flagged.

Illustrative AI-generated receipt image with receipt-like product and payment details.

Illustrative AI-generated receipt image with a generic retail layout.

These scenarios provide review context; they do not replace the documented isTampered and tamperedScore response contract above.

Reporting Bypasses

If your team confirms a tampered or fabricated receipt that passed detection, follow Contacting Support. Include the email attached to the account, the affected receipt's trackingId when returned, the sample when safe to share, and a clear description of the issue.

Need something not covered here? Contact [email protected] — see Contacting Support.