Treasury

Treasury is the bank side of a Railbase finance install: the accounts money sits in, the batches that leave them, the statements that come back. It is a settlement partner of Accounts Payable, not a ledger — it never posts a journal.

Treasury is a data-resident Railbase module: fourteen tenant-stamped collections — bank accounts, statements and lines, reconciliation sessions and matches, payment batches and items, cash forecasts and FX exposures — declared in the signed bundle.

What the bundle does

• The payment-batch state machine. Three verbs drive draft to approved to submitted to executed, and a fourth voids. Approve stamps who and when; submit captures the reference your bank hands back; execute flips every planned item to paid in one transaction and refuses a second call. Voiding demands a written reason; an executed batch cannot be voided.
• Batches materialised from an approved payment run. Treasury subscribes to ap.payment_run.approved and mirrors it into a draft batch with one item per vendor invoice — beneficiary, amount, currency, source invoice id — keyed on the originating run, so a re-delivery creates nothing new.
• A matcher that refuses to guess. Auto-match walks the session statement's unmatched debit lines and pairs one with a paid payment item only when a single candidate agrees on amount and currency; two candidates leaves it unmatched, and an item matched earlier is out of the pool. Commit freezes the session; cancel deletes its matches and resets its lines.
• Money in integer cents. Batch totals, the matcher's amount comparison and every report aggregate run in whole minor units, so no total drifts on float dust.
• Seven JSON reports: cash position per active account by currency; unmatched lines per account with the oldest outstanding; daily inflows, outflows and net over a lookback you pass; active forecasts and projected ending balance; batches by status with throughput; latest FX exposure per currency, hedged against unhedged; and a filterable statement-line read.
• One permission. A treasury_operator role carries treasury.use, mapped onto every verb and report in the manifest. Settings cover the default payment method and the base currency for FX.

Where it fits

The handshake with Accounts Payable runs both ways over the core event bus: AP's approved run becomes Treasury's draft batch, and executing that batch emits treasury.payment.executed once per paid item, which AP consumes to apply Dr AP / Cr Cash and close the invoice. Batch-level approved, submitted, executed and voided events go out.

Where it stands today

• It does not install yet. The core checks a bundle against its own surface before accepting it, and this one is still refused — the screens above call endpoints outside the module's namespace, and some declared events cannot be proven from the code. That gate is the reason the module is listed as coming soon rather than sold.
• No bank connection and no statement parser: nothing reads OFX, MT940 or CAMT, and no payment file is generated — you lodge it through your own channel and record the reference.
• Only three collections have a write path in the shipped code: payment batches, payment items, reconciliation matches. The other eleven — bank accounts, statements, statement lines, reconciliation sessions, forecasts, FX — have no create or edit verb, so the reports over them come back empty and reconciliation needs a session nothing here can open.
• The three screens at /treasury read their tables through the core's collection endpoint. A plugin collection ships with an empty access rule, which the core reads as deny, so those tables render empty. The screens are not wired to live data yet; the verbs and reports behind them are.
• auto_matching_rules is in the schema, but the matcher never reads it: pattern, counterparty, tolerance and date-window matching are not implemented, and manual matching has no verb.
• Reports are JSON only — no CSV, XLSX or PDF, and there is no reversal flow for an executed batch.