What might a JSONL schema for payments, open items and allocations look like?

A release can be delivered as one JSONL file per record type, with identifiers that stay stable across files. Parquet versions of the same tables can be requested where columnar loading suits you better.

**Files and key fields**

- `accounts.jsonl`: `account_id`, `payer_type`, `terms_days`, `status`. - `open_items.jsonl`: `item_id`, `account_id`, `item_type` (invoice, credit_note, instalment), `amount_due`, `outstanding`, `due_date`, `linked_item_id`, `dispute_case_id`. - `payments.jsonl`: `payment_id`, `amount`, `currency`, `value_date`, `channel`, `remittance_text`, `payer_ref`. - `policies.jsonl`: `policy_id`, `text`, `thresholds`, `applies_to_role`. - `tasks.jsonl`: `task_id`, `payment_id`, `prompt`, `allowed_tools`, `reference_id`. - `reference_outcomes.jsonl`: `reference_id`, `allocations`, `accepted_alternatives`, `expected_flags`.

A payment line might read:

``` {"payment_id":"PAY-7714","amount":12300.00,"currency":"AUD","value_date":"2026-03-04","remittance_text":"Settling Oct shipments less CN credit","payer_ref":null} ```

Links run through `account_id`, `linked_item_id` and `payment_id`, so integrity can be checked with joins before any episode runs. Field names are a starting proposal and can be adapted in a pilot. The records are generated, so run your usual checks for grounding and disclosure risk on load.