Practical guide

Write a field contract before connecting the output

Last materially reviewed 2026-09-30

Quick answerDefine names, types, missing values and acceptance rules before automating a destination.
What to know

Name the meaning, not just the label

A field contract says what an output means. For each field, write its name, type, source location or interpretation, whether it is required and how absence is represented. Two fields called date can refer to different events. A fictional document_date is not received_at. Avoid vague names such as total unless the document class and meaning are clear enough for another reviewer to reach the same answer.

What to know

Keep a compact example

For an illustrative delivery note, use reference as text, item_code as text, quantity as a decimal and unit as text. Keep leading zeros in codes. Say whether quantity can be negative and what that means for this task. Do not let a spreadsheet silently turn an identifier into a number. These are schema-design recommendations, not proof that any merchant automatically enforces them or that they fit every document type.

What to know

Define the exception outcome

A missing required value should produce a review state, not a guessed default. Decide how to distinguish absent, unreadable and genuinely zero. Record who resolves each exception and what evidence closes it. If the destination cannot accept an unresolved row safely, hold it outside the destination. A technically valid JSON object or CSV row can still be semantically wrong; passing a format check is only one checkpoint.

What to know

Version the agreement

Keep the field contract with the sample set and record changes to names, types or rules. Before changing a live mapping, compare old and new outputs on the same examples. A new field should not silently shift existing spreadsheet columns. The reviewer should know which contract produced each accepted batch. Continue to the acceptance pack to test these rules, then inspect the destination mapping before enabling an operational write.

Continue when useful

Next: Acceptance pack

Use expected answers and awkward cases, not just a successful demonstration document.

Open Acceptance pack →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Parsio: documented parsing options — Merchant documentation · parsio.io · Merchant-controlled · checked 2026-09-30
  2. Docparser: documented feature set — Merchant documentation · docparser.com · Merchant-controlled · checked 2026-09-30