Docs Controls

Weekly report

LiveUpdated

View as Markdown

Agents. Written for people who build agents, the hosts they run in, and the people and companies the agents pay for.

Every Monday there is a draft for the previous ISO week. The person who approves reads the exceptions, disposes of them, and signs; the signature seals every line and the report itself as records an auditor can verify without Enruta.

What is on it

SectionContents
CountsLines by match_state: matched, partial, unmatched agent (issued, never spent), unmatched rail, unmatched merchant
Coveragematched ÷ (all lines − unmatched agent); the target is 99 % or better
ExceptionsEach with the mandate, the payee, the amount, the code and the suggested action (the nine codes)
Observed decisionsRequests decided observe under a shadow policy, with what the policy would have done
ReversalsRefunds, voids and credits completed in the week, and their effect on budgets
FinalitySettled amounts by finality_class and when they become final
Root hashA Merkle root over the lines, in id order; the passkey signs its 32 bytes

Reading a line

A line is the payment as three parties saw it: what the agent was mandated, what the rail authorized and settled, what the merchant confirmed, plus every adjustment. matched means all three agree; partial means a leg is still missing but nothing contradicts; an exception code means something disagrees and the suggested action says what to do. A SETTLEMENT_OVERDUE is usually the rail; an AMOUNT_CLEARED_NE_AUTH creates a candidate reversal and, if the person who approves wants it, a dispute packet in one click.

Signing

  1. Open /reconciliation, pick the week; the draft shows the counts, the exceptions and the root hash.
  2. Dispose of the exceptions (human_outcome on each line records what was decided and by whom).
  3. “Sign with passkey”: a WebAuthn assertion over the root hash. Over the API, POST /v0/reconciliation/reports/{period}/sign signs with the organization’s link key instead; the record then reads customer_attested rather than third_party_signed.
  4. Every line is sealed as a reconciliation_line record chained to its payment record, then the report as a reconciliation_report record carrying the line record ids and the signature as its approval.
GET /v0/reconciliation/reports/2026-W37
{
  "id": "rcr_01M2GD5R2W8T3Q7K1N9B4D6H2XS", "period": "2026-W37", "state": "signed",
  "counts_by_match_state": { "matched": 41, "partial": 2, "unmatched_agent": 3, "unmatched_rail": 0, "unmatched_merchant": 0 },
  "coverage_pct": "95.3",
  "exceptions": [{ "line_id": "rcl_01M2GD4W…", "mandate_id": "mnd_01M2T1…", "code": "SETTLEMENT_OVERDUE", "suggested_action": "Check the rail: no settled event 24 h after the expected settlement" }],
  "line_ids": ["rcl_01M2GD4T7Q1W9K3N5B8H2D6XRS", …],
  "root_hash": "sha256:2c7f…91ab",
  "signed_by": "usr_01M2A0…", "signed_at": "2026-09-14T15:20:41Z", "signature": { "method": "passkey", "credential_id": "…" },
  "report_record_id": "rec_01M2GE1K9T4W2Q8N6B3D7H5XRC"
}

For the auditor

The export of a period contains the signed report record, every line record and every payment record they chain to, with the verifier. Re-running npx enruta-verify ./export-2026-09/ reproduces the root hash and checks the signature; the test of whether the company’s electronic evidence was modified becomes a mechanical one.

Interfaces

SurfaceCall
Console/reconciliation: period picker, lines, report card, “Build report”, “Sign with passkey”; / shows the coverage of the last signed report
RESTGET /v0/reconciliation/reports/{period}, POST …/build, POST …/sign; GET /v0/reconciliation/lines?period=&state=
CLIenruta reconciliation report 2026-W37 --build --sign
Webhookreconciliation.report_ready when the Monday draft exists