> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ebrc.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Verification

> Every extraction is checked against the arithmetic the shipping bill performs on itself, so you can tell which of your documents are internally inconsistent before you file against them.

A shipping bill states its own totals twice. Every extraction checks them against each other and returns the result on `data.verification`.

This is the part a document-reading model cannot offer. It does not tell you whether *we* read the bill correctly. It tells you whether **the bill agrees with itself**, which is a fact about your document and worth knowing before you file against it.

## The response

```json theme={"dark"}
{
  "verification": {
    "passed": true,
    "score": 1,
    "errors": 0,
    "warnings": 0,
    "failedChecks": []
  }
}
```

<ResponseField name="passed" type="boolean">
  True when no **error**-level check failed. Warnings do not affect it.
</ResponseField>

<ResponseField name="score" type="number">
  Share of applicable checks that passed, 0 to 1. Checks that do not apply to a document are not counted, so a bill with no container table is not penalised for it.
</ResponseField>

<ResponseField name="errors" type="number">Error-level failures.</ResponseField>
<ResponseField name="warnings" type="number">Warning-level failures.</ResponseField>

<ResponseField name="failedChecks" type="array">
  One entry per failure, with `id`, `severity` and a `detail` naming the figures that disagreed.
</ResponseField>

A failure looks like this:

```json theme={"dark"}
{
  "verification": {
    "passed": false,
    "errors": 1,
    "warnings": 0,
    "failedChecks": [
      {
        "id": "value.fob-equals-item-sum",
        "severity": "error",
        "detail": "PART I 104381.85 vs items 1043881.85 (delta -939500.00)"
      }
    ]
  }
}
```

## The checks

| id                                    | Severity | What it asserts                                                                                                       |
| ------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------- |
| `header.invoice-count`                | error    | Header `INV Nos` matches the number of PART II invoice records                                                        |
| `header.item-count`                   | error    | Header `ITEM Nos` matches the PART III item rows                                                                      |
| `header.container-count`              | warning  | Header `CONT Nos` matches the equipment table. A warning because air consignments legitimately omit it                |
| `value.fob-equals-item-sum`           | error    | PART I FOB equals the sum of PART III `FOB (INR)`                                                                     |
| `invoice.*.item.*.qty-rate`           | warning  | Quantity × rate equals the line value, per PART II line                                                               |
| `summary.invoice-table-within-header` | warning  | The PART I summary lists no more invoices than the header declares. The form truncates this table, so fewer is normal |
| `document.single-bill`                | error    | The file contains exactly one shipping bill                                                                           |
| `format.iec`                          | warning  | IEC is a 10-character code                                                                                            |
| `format.gstin`                        | warning  | GSTIN is 15 characters                                                                                                |
| `format.sb-date`                      | error    | The SB date parsed to ISO `YYYY-MM-DD`                                                                                |
| `presence.sb-no`                      | error    | An SB number was found                                                                                                |

## What a failure usually means

**`document.single-bill`**: several bills concatenated into one PDF. Their sections have been merged into a single incoherent document: the header is the first bill's, the item rows are all of them. Split the file and extract each bill separately.

**`value.fob-equals-item-sum`**: the summary FOB and the item lines disagree. A delta that is an exact factor of ten is a decimal-place error somewhere in the document.

**`header.item-count` or `header.invoice-count`**: the file is truncated, or a part is missing. A bill whose header declares four items but carries three rows is missing a row, not mis-read.

## Extraction still succeeds

A document that fails verification is still returned with a `200` and full `fields`. The checks describe the document; they do not gate the response.

What you do with that is yours to decide. Routing failures to human review before filing is the obvious use. A bill that does not reconcile with itself will not reconcile with DGFT either.