Re: finance-mart v1.0.0, Revenue confirms the reconciliation boundary and names the transaction-grain targets

Position

Revenue confirms the boundary in finance-mart v1.0.0. Finance-mart is a business-reporting-grain read surface, not a commercial source of truth, and the contract reads correctly when it says Finance reconciles against Revenue rather than restating Revenue.

The load-bearing distinction is grain. Revenue remains authoritative for transaction-grain commercial state: orders, payments, credit accounts, credit reservations, credit ledger entries, refunds, funding sub-state changes, recognition facts, forfeits, and release or consumption outcomes. Finance is authoritative for the derived finance reporting section it serves, including period rollups, margin, cash-position views, and reconciliation variance at the business reporting grain.

Nothing in the contract reads as Finance becoming a second writer of commercial truth. The contract's "no transaction-grain records" rule and "operational domains SHALL NOT consume this contract as an input to operational behavior" rule are the two guardrails Revenue cares about most, and both are present.

Named reconciliation targets

When Finance drafts per-figure reconciliation tolerances, Revenue recommends naming targets by Revenue concept rather than by current physical table shape. The first-pass target set should be:

• Revenue credit ledger entries, including entry type, signed credit amount, created-via source, linked credit account, linked credit reservation, linked order, and created timestamp.
• Orders and order items, including order status, person_id, organization_id, committed amount, package or lesson context, and cancellation state.
• Payments, including provider reference, payment_path (invoice_paid versus active_charge), provider status, internal writeback status, amount, and received timestamp.
• Refunds, including refund lifecycle state, provider refund reference, refund reason, linked payment or order, linked reservation where present, and completed timestamp.
• Credit reservations, including lifecycle state, funding sub-state, reserved credits, lesson_id, person_id through the credit account, organization_id, state_at, and terminal outcome.
• Revenue recognition facts, including recognized amount or credits, recognition period, source ledger entry or reservation, and reversal relationship where present.

The writeback-separation fields are not optional for reconciliation. Provider success and internal writeback success are different facts, so any finance-mart reconciliation manifest that touches payments or refunds should keep provider status, provider reference, and internal writeback status visible enough to explain variance.

Platform note

Revenue has no objection to Finance composing through the warehouse silver surface and the conformed spine per ADR-0016. Platform still owns the exact silver column manifests and the consumer-firewall mechanism, so Revenue's confirmation here is limited to the commercial authority boundary and the transaction-grain targets Finance should reconcile against.

References

• Parent memo: 2026-05-14-finance-mart-contract
• Contract: contracts/finance-mart/README.md
• Revenue domain scope: domains/revenue.md
• Warehouse silver contract: contracts/warehouse-silver/README.md
• ADR-0015 and ADR-0016