# Finance records: support the review before the conclusion
> Checked · 20 October 2026 · Wiki version 2026.10.20.2
Financial planning and settlement work need identifiable source records, clear commitments, authorised review, and a traceable link to any learning that follows.
## Purpose
Explain how financial records become reviewable decisions without exposing private values or turning a calculated display into an editable fact.
## Diagram text alternative
Operational and provider records support a finance record. An authorised review leads to a settlement or planning decision, which can produce a learning item.
## Current / proposed status
- Current: Checked — the planning and settlement responsibilities are documented; individual financial records are intentionally outside the screenshots.
- Proposed: Use authorised systems and records for current values; preserve the calculation source and reviewer for a conclusion.
## Safe example
### A safe review note
Instead of copying a total into a task, link the approved finance record, state the period it covers, name the reviewer, and note the decision requested. If a value is computed, verify permission before changing any input.
## Responsibilities
- Planning makes commitments, subscriptions, revenue planning, and projects visible.
- Delivering supplies the operational records that may support a charge or settlement.
- An authorised reviewer accepts or questions the financial conclusion.
- Learning captures a repeatable reconciliation issue for later improvement.
## Checklist
- Identify the record, period, source, and reviewer before using a financial conclusion.
- Treat computed values as outputs until their inputs and edit permissions are understood.
- Keep duplicate, missing, and stale source cases visible to a reviewer.
- Avoid putting private values or account data into a general wiki, prompt, or screenshot.
## A record is useful when its source and scope travel with it
**Status:** Checked
A finance record should say what period, property or service scope, source system, and supporting observations it represents. This lets a reviewer determine whether the record is comparable to the decision being made.
The wiki uses no live financial data. The planning-navigation screenshot is deliberately a navigation crop; it points out that finance and related modules exist while leaving individual records and values out of the capture.
**Current / proposed status**
- Current: Checked — documentation describes the record boundary without claiming visibility into private finance data.
- Proposed: Keep current finance detail in the authorised system and provide an approved record link for review.
**Expected outcome**
A reviewer can locate support for a conclusion without copying sensitive values into another channel.
**Meaningful tests**
- Review context exports for absence of live financial values and identifiers.
- Check the source pointer names the dated navigation example rather than calling it a live report.
## Review authorises a conclusion, not just a calculation
**Status:** Checked
A calculated result can be useful, but it is not automatically an approved decision. The reviewer needs the source, scope, relevant exception state, and permission to decide. This matters for commitments, settlements, and any change to a record that affects another person.
When a supporting source is duplicate, incomplete, or stale, the right action is to make that condition visible and obtain a current read or reconciliation—not to choose the most convenient number.
**Current / proposed status**
- Current: Checked — this is a safe interpretation of the documented planning and settlement responsibilities.
- Proposed: Document the authorising reviewer and the evidence window in the current review record.
**Expected outcome**
The difference between a displayed calculation and an authorised conclusion stays clear.
**Meaningful tests**
- Include duplicate and failed-source fixtures in connector regression checks.
- Check the contextual work prompt requires a proposed outcome and meaningful tests.
## A display is a clue; the record is the support
**Status:** Checked
A dashboard or report can help decide where to look, but it may be a projection, cache, or dated observation. A screen repaint is not proof that a provider source was read completely or that a settlement was approved.
Use the display to locate the relevant record and its freshness metadata. Keep the decision language proportional: “needs review”, “source stale”, or “reconciled by authorised reviewer” are materially different statements.
**Current / proposed status**
- Current: Checked — this preserves the infrastructure freshness definition and avoids an unsupported operational claim.
- Proposed: Expose source window and publication result near financial projections where feasible.
**Expected outcome**
Readers know which next question to ask before relying on a displayed value.
**Meaningful tests**
- Check labels distinguish fresh source data from a recently opened screen.
- Check no generated export claims an account, payment, or settlement is complete.
## Related pages
- [Property lifecycle: from enquiry to review](/workflows/property-lifecycle/) — A property service lifecycle connects owner needs, identity, stays, readiness, settlement, and learning. It is a model to validate, not a claim that every handover is automated.
- [SOP learning: turn observations into a better next step](/workflows/sop-learning/) — Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.
- [Service directory: approved destinations, not shared access](/reference/service-directory/) — This directory names the approved service destinations used around Co.Property. Every destination requires an existing authorised account or approved auth; the wiki never stores tokens, credentials, or private logs.
## Source pointers
- Handoff / pages/workflows.html
- Handoff / pages/organisation.html
- Handoff / pages/app-tour.html
## Context export
- Page context: ./exports/workflows--finance-records.context.json