Before any clause can be checked, the invoice has to become data. In many ports the carrier's local agent sends D&D as a monthly statement — a scanned PDF, sixty to two hundred lines, each a container with discharge date, gate-out date, days, rate and amount, in a layout that drifts slightly from month to month.
What goes wrong
OCR misreads a 1 as an I in a container number. A date column shifts. Amounts lose a decimal. A line wraps. Any of these turns a correct dispute into a wrong one, and a desk that sends a dispute citing the wrong container number does not get a second hearing.
Guardrails
Container numbers carry a check digit (ISO 6346): the eleventh character is computed from the first ten. A misread fails the check and is flagged; a transposition that happens to pass is caught by searching the shipment list for the number — if it is not one of yours, that is a finding in itself. Dates are validated against the shipment's known events where they exist. Amounts are checked as days × rate per tier. Low-confidence OCR regions are highlighted rather than passed through.
Layout drift
The first statement from an agent is mapped with a person confirming the columns; subsequent statements apply the mapping and flag when the layout no longer fits, rather than guessing. This is the same approach as any export mapping: learn once, re-ask on change.
Why it matters
The pre-screen — rating every line against the contract — is only as good as the extraction. Most of the engineering in D&D Pilot's ingestion is not the AI; it is the validation that lets a desk trust two hundred extracted lines enough to act on them.