Shipped finance contracts
Find the installed finance guides, operator procedures and transport contracts, including unavailable evidence.
Shipped finance contracts
Use the installed action and its current authorization before changing money. A route, schema, dashboard or feature map does not grant access or certify every finance requirement. The guides below describe shipped behavior; missing historical evidence remains unavailable.
Human guides and recovery
| Task | Installed guide | Boundary |
|---|---|---|
| Review, issue and undo a billing run | Running a billing run and Billing runs | Undo is limited to eligible non-posting documents. Posted cancellation is a separate action. |
| Diagnose settlement, FX, run, ledger and tax incidents | Finance operator runbooks | Start with a bounded preview; uncertainty is a stop condition. |
| Read payment, allocation and receipt identities | Payments | A negative payment does not establish a confirmed provider refund. |
| Understand posting, lock and replay ownership | Finance architecture | Retain original financial sources; recovery does not create a new economic command. |
| Choose document cleanup ownership | Document cleanup | Voiding an eligible non-posting document differs from cancelling a posted invoice. |
The staff settlement queue at /payments/settlements calls the installed allocation, exception and provider-refund-linking actions after checking current authority. It lists verified settlements, including ones with no current exception. Captured balance observations do not promise refundable capacity. Refund unavailable for pure unapplied cash remains the released boundary: linking a known provider refund does not send a provider request or confirm cash.
The Finance tab under Admin → System → Integrity (/admin/settings/integrity?tab=finance, also reached by the /payments/operations redirect) requires settings.manage and unrestricted warehouse access. It shows partial operational evidence from released readers, sends no alerts and runs no repairs. A failed or absent reader is Unavailable, never a fabricated zero. Its complete integrity scan can be costly on a large tenant.
Billing recovery uses the existing attempt identity and released dispatcher/reconciler commands documented in the runbook. Failed-item retry is unavailable without a producer that owns it; never reset Failed to Ready or reopen a terminal run. No unlanded operator adapter is promised by this guide.
API and MCP callers
Finance compatibility envelopes describes the installed transport/version, source, error, privacy and money boundaries. API conventions, API versioning and MCP apply alongside them.
Payment and operator-refund input uses a positive integer minor-unit magnitude in the owning invoice currency. Refund output is signed. The minimal payment payload below is accepted by RecordPaymentData; it is an example for an already authorized caller, not permission to record a payment:
{
"amount": 12500,
"payment_method": "bank_transfer",
"reference": "PAY-001"
}
Use the distinct installed payment/refund route and action for the intended operation. Do not send a negative input amount to obtain a refund. InvoicePaymentData returns a signed decimal string with its owning currency, retained settlement/allocation identity and invoice aggregate version. Preserve absent historical identity as null; do not infer provider authority from a card method or reference.
AllocateSettlementTool, named allocate-settlement, invokes api.v1.invoices.settlement_allocations.store; it requires payments:write and an authorized staff actor. Keep the same explicit idempotency key, actor, target, amount and reason for a retry. MCP confirmation or token scope does not replace action, warehouse, original funding or currency checks.
CancelInvoice performs the separate posted-invoice cancellation under its existing void/credit permissions and expected-version check. It retains the original posting and records the remaining frozen credit. Cancellation neither refunds cash nor makes a posted invoice eligible for billing-run undo.
AI rules and translations
Finance generation rules applies to generated callers: authorize before validation, call installed actions, preserve immutable posted facts, refuse unresolved FX, and deliver effects through their existing after-commit path. Do not generate a substitute producer or claim exactly-once remote delivery.
The shipped queue and operations labels below exist in all seven installed language packs (en-srf, de, es, fr, it, pt, zh). Read labels through the normal translation lookup; do not use a translated label as an action identifier or refusal code.
| Translation key | Installed surface |
|---|---|
Settlement queue |
Staff settlement queue |
Finance operations |
Partial operations dashboard |
Unavailable |
Missing operational evidence |
Generated contract and feature evidence
| Artifact | What to inspect |
|---|---|
| OpenAPI | Installed API v1 payment, refund, allocation and cancellation routes and schema components. |
| Feature-area map | Generated area membership; not proof that every behavior is implemented or tested. |
| Production mutation manifest and reviewed source data | Source-reviewed mutation declarations; not runtime authorization. |
| Finance field review | Event-owned, derived and scoped operational field ownership. |
| Changelog | Shipped changes and qualifications under Unreleased. |
The integrator owns generated schemas, feature maps, mutation manifests, binding pins and their normal hourly refresh. Inspect these artifacts read-only. A pending generated refresh is distinct from a source landing; never regenerate or adopt stale pins from a caller to hide drift. Newly named behavioral gaps need their own requirement and producer; generated evidence cannot supply missing money, locking, replay or provider authority. Browser execution remains deferred to stage end, and this documentation does not claim rollout or release-suite acceptance.