modules/treasury-forecast/references/input-contract.md

# Treasury input contract v1

Provide six comma-delimited UTF-8 CSV files, or XLSX sheets with these exact
headers and order. Dates are ISO YYYY-MM-DD or native Excel dates. Money uses one explicit reporting currency, EUR or CHF,
decimal text with a point and at most two decimal places; native Excel numeric
money is accepted when exactly representable at cent precision. IDs are text
cells; formulas, ambiguous separators, duplicate keys and ragged rows are rejected.
All tables concern the company and cutoff in the manifest. Data sources are
required; missing facts are not replaced by model guesses.

| Table | Headers |
|---|---|
| accounts | account_id,balance |
| bank_movements | movement_id,account_id,date,amount,description |
| open_items | item_id,party_id,party_name,side,document_type,document_number,document_date,installment,due_date,amount,replaces_flow_id |
| planned_flows | flow_id,side,amount,expected_date,description,basis |
| allocations | allocation_id,movement_id,target_type,target_id,amount |
| adjustments | adjustment_id,item_id,date,amount,kind,evidence_ref |

Accounts are the actual balances at the cutoff. Use a fixed declared population
of accounts whose funds are available to the included payments. A bank movement's
amount is signed: receipt positive, payment negative. Its date must be after the
previous cutoff and on or before the current cutoff. Starting actual balances
plus these movements must equal the new actual balances account by account.

Open-item amount is the reported remaining cash amount, never the original invoice
total or an automatically inferred amount. Side is `receivable` or `payable`;
amount is nonnegative. IDs remain stable across runs. Party, side, document
type/number/date and installment must identify the same obligation. A due date may
be blank only when the review supplies a supported future expected date.

Additional flows cover the supplied future activity, payroll, reviewed tax
commitments, debt service, investment and other cash events absent from open
items. Side and amount use the same convention. Expected dates and basis are
supplied assumptions. Reforecasting an existing plan's amount requires a current
supplied amount and basis; an evidenced cash settlement must reduce its remaining
amount exactly. To cancel an unpaid plan, retain its ID with a zero amount and
state the cancellation basis. Dropping a nonzero unpaid plan is rejected.

Set an open item's `replaces_flow_id` only for a reviewed full replacement of
one planned cash event by that invoice. Retain that relationship in subsequent
open-item snapshots. A plan may remain in the table for reference; it is suppressed
from forecast cash. The recorded relationship survives later disappearance of the
settled invoice. Partial/multiple replacements need a separately reviewed split
into individually identifiable full replacements; this version does not infer it.

Allocation amount is positive. `target_type` is `item` or `plan`; target ID
identifies the corresponding obligation. Multiple allocations can share one bank
movement, provided allocated amounts do not exceed its absolute cash value.
Receivable allocations require positive bank cash and payable allocations require
negative cash. Unallocated cash still affects the actual bank balance, but does
not settle an invoice. A missing open item requires its full prior balance to be
explained by allocations and non-cash adjustments.

Adjustment amount is signed against the outstanding amount: a credit note
reducing a receivable by 3,000 is `-3000.00`. Its kind and evidence reference
must come from the supplied accounting evidence. An adjustment has no bank cash
effect. For retained items:

```text
new outstanding = previous outstanding - cash allocated + non-cash adjustments
```

The first run supplies header-only bank movements, allocations and adjustments.
The optional XML files are evidence for review. Payment terms do not establish
actual settlement or unpaid balance; the structured open-item and settlement data
remain required. Byte-identical XML duplicates are recognized; conflicting bytes
for the same invoice identity require source review. XML payment terms, credit
notes, withholding and VAT details are exposed without automatically classifying
their treasury treatment.

## Manifest generated by Codex

```json
{
  "schema_version": "vera.treasury_manifest.v1",
  "company_id": "the-reviewed-company-id",
  "company_name": "Company name",
  "currency": "EUR",
  "as_of": "2026-09-10",
  "horizon_end": "2026-10-02",
  "coverage": "The professionally agreed population of cash events and assumptions.",
  "tables": {
    "accounts": {"path": "accounts.csv"},
    "bank_movements": {"path": "bank_movements.csv"},
    "open_items": {"path": "open_items.csv"},
    "planned_flows": {"path": "planned_flows.csv"},
    "allocations": {"path": "allocations.csv"},
    "adjustments": {"path": "adjustments.csv"}
  },
  "invoice_files": [],
  "previous": null
}
```

For XLSX, each table uses `{"path":"input.xlsx","sheet":"accounts"}` with the
exact sheet name. For an update, `previous` is
`{"path":"previous-forecast.json","record_sha256":"the-exact-record-digest"}`.
All paths are relative to the immutable run inputs, without symlinks or traversal.
Client and engagement IDs come from Studio Archive, not the manifest.

The imported predecessor must be an accepted treasury record for the same client,
engagement, company and currency. The new cutoff must be later. The forecast
horizon is 1–366 days; dates beyond its end remain recorded and explicitly outside
that horizon. Repeating the same input package resumes the existing session.

Hashes establish exact bytes and recorded decisions, not authenticated identity,
evidence truth, completeness of company data or certainty of expected receipts.