Docs · Finance
Policy of record
LiveUpdated
Finance. Written for the finance team that signs the policy and the weekly report.
A finance team does not buy an API. It buys five things: a policy of record, a gate that runs before the credential exists, a record of every payment including the ones that did not happen, a weekly report it signs, and an export its auditor can re-run.
| What | Form | Status |
|---|---|---|
| Policy of record | One signed, versioned policy, the same document compiled onto every rail the team pays on | Live on Stripe Issuing; Mercury (December 2026), Ramp (January 2027) and Bill.com (read-only from January 2027) follow with their adapters |
| The gate before the click | Every payment is decided before a credential is issued; above the threshold a named person signs with a passkey | Live |
| One record per payment | An Evidence Record, denials included, verifiable offline | Live |
| Weekly report | The reconciliation report, exceptions coded, signed by the controller | Live |
| Audit export | A zip with the verifier; the compliance export by person, period and kind | Live |
The policy, in your terms
The controller writes the policy in the console editor in the words of the approval matrix: which payees, which categories, how much per payment, how much per month, above what a person signs, which agents. Signing produces version n; every mandate and every record names the version it was decided under. The editor shows the autonomy level at the top (“This policy is L3: autonomous inside the boundary, a person approves beyond it”), and the fields that set it: mode, refill_policy, deviation, shadow, require_consent, reversal.window_days.
The same policy runs twice: Enruta decides, then compiles the decision into the rail’s own control (a single-use card with the exact amount and merchant lock on Stripe Issuing). The rail is the fuse; the mandate account is the truth about the limit.
Approvals
A step-up reaches the approver by e-mail and in the console inbox, with the payee, the purpose, the policy version that matched and the budget left. The approver signs on their phone with a passkey (the assertion binds the request hash) or, where the organization allows it, through an authenticated link. A refund above reversal.step_up_above is approved the same way. Nothing is minted before the signature; an expired approval seals a record too.
Two phases
- Shadow mode. Turn a policy on with
shadow: trueand let it observe: every request is decided and sealed asobservewith what an enforcing policy would have done. After four weeks the report says what would have been stopped. - Release under policy. Take
shadowoff; the same policy now issues the credentials, and the same records keep flowing.
Replaying payments a team already made on a rail (a month of paid bills read from the rail with read-only credentials) is the same observe decision applied to history; it needs the read-only adapters and is planned with them.
What the controller sees
/policies: every version, its signature and hash, the autonomy label, the rule sheet./approvals: the inbox;/a/{id}: the approval page./payments/{id}: the timeline from request to seal, the mandate account, the settlement, reversals, the reconciliation line, dispute packets./reconciliation: the week’s lines, the exceptions with suggested actions, “Sign with passkey”./agents: consents, attestations, and “Pause” with a reason; the pause is a sealed record./records: the chain, the verify button, the export panel with the compliance options.
Price
| Mandated flow a year | Annual | Mandates included | Above that |
|---|---|---|---|
| Up to $10M | $24,000 | 5,000 | $0.25 a mandate |
| Up to $25M | $40,000 | 15,000 | $0.25 a mandate |
| Up to $100M | $80,000 | 50,000 | $0.25 a mandate |
Approval seats, the policy signature and the auditor readout are on every band; denials and step-ups are free and still sealed. A twelve-week read-only pilot ($10,000, credited against the first year) is the shadow-mode phase with a readout at the end. Full sheet on Pricing.