Which linked records and fields does a receipt-matching task depend on?

A payment workflow becomes testable when the records link by stable identifiers. A task pack for this workflow could use the following structure.

- **bank_line**: line_id, value_date, amount, currency, payer_text, reference_text, source_account. - **customer**: customer_id, legal_name, related_customer_ids, terms_code. - **invoice**: invoice_id, customer_id, issue_date, due_date, amount_open, status. - **credit_note**: credit_id, invoice_id, amount, approval_state. - **allocation**: allocation_id, line_id, invoice_id, amount_applied, posted_by, posted_at. - **case**: case_id, line_id, reason_code, owner_role, status. - **policy**: policy_id, rule_text, applies_to.

The links that matter are line_id to allocation, invoice_id to allocation and credit_note, and case.line_id back to the originating bank line. If these joins are broken, scoring becomes ambiguous.

Files can be delivered as JSONL, one record type per file, or as Parquet tables for larger sets. Each task can carry a task_id, an initial-state snapshot reference and an expected-final-state reference.

For an evaluation harness, the useful hooks are a reset that restores the initial snapshot, a log of every tool call, and a diff of ledger state before and after. Agree the exact fields with MirrorFirm in a pilot, since the schema can be adapted to your harness.