In this note
A team wants to draft commentary for its monthly finance review. Someone says the company’s data needs cleaning first. That could mean finding the approved plan for one department. It could also become a project to repair every customer address in the CRM. Those jobs have very different relationships to the requested commentary.
I’d ask the reviewer to show one variance they need explained, the figures they trust, and the evidence they would accept. Then assess those inputs before proposing more data infrastructure.
In this hypothetical example, finance wants a draft explaining September freight costs, with sources it can check. We're designing that draft, not implementing a finance service or giving accounting advice. Sending the report, updating forecasts, posting journal entries, and making payments are separate jobs.
Follow the figures through to the reviewer
First, see what the comparison would require if both approved inputs were available: September costs of CAD 120,000 and a plan of CAD 100,000 for one department's freight account. Check that both refer to the same period, department, account, and currency. Each source should have one row per department, account, and period. This is the data's grain: what one row represents. The worksheet then considers the blocking case where the team cannot establish which plan is approved; these illustrative figures cannot fill that gap.
- Amount variance
- 120,000 − 100,000CAD +20,000
- Percentage variance
- 20,000 ÷ 100,000 × 100+20%
Here, variance means actual minus plan, so a positive number means overspending. Finance must choose the sign convention, when a difference needs attention, and what happens when the plan is zero. Put those rules and calculations in code. Give the model the checked result to explain.
The logistics owner supplies a September carrier-rate amendment as part of the explanation. It doesn't account for the full CAD 20,000 difference yet. The draft can cite that explanation and say the remainder is unexplained. It shouldn't invent higher shipment volumes or blame the whole difference on the amendment. Finance decides whether the evidence is sufficient.
- Approved figuresSeptember actuals and approved plan, with matching keys and revisions
- Deterministic checksReconcile figures; calculate the owner-defined variance and materiality route
- Owner explanationAttributable explanation, source references, and unresolved claims
- Review packetChecked evidence plus an optional proposed draft; finance accepts, rejects, or requests evidence
Decide which gap blocks this packet
If the approved plan is missing, stop the comparison and ask its owner for it. A file called latest-plan could be a forecast, an old budget, or an unapproved edit. Treating the missing plan as zero would invent a variance. Letting the model choose a plausible file would hide the problem.
Check revisions as well as file availability. The controller may have approved act-sep-7 while the integration still returns act-sep-6, from before a close correction. Hold the draft until it uses and reconciles to the approved figures. Fetching an old snapshot today doesn't make its contents current.
| Observed condition | Response for this review |
|---|---|
| Approved plan is unavailable | Hold the actual-versus-plan commentary; request the approved source from its owner |
| Actuals use a superseded close snapshot | Obtain the approved revision, reconcile it, and retain the earlier evidence |
| CRM has duplicate customer mailing addresses | Leave outside this department/account review unless a demonstrated dependency uses those records |
Leave the duplicate CRM addresses out because this report doesn't use them. Record that reason. If someone later asks for customer-level commentary, revisit the customer records and permissions. Checking one department's report doesn't establish that every finance dataset is ready.
For this report, check the period, department, account, currency, amounts, revisions, and explanation sources. Look for missing and duplicate rows, then reconcile the totals to the approved report. If only an explanation is missing, finance might accept a figures-only summary. Ask before changing the promised result.
The same record can have four different uses
Follow that finance total through the proposed service. Finance reads it to calculate the variance. The drafting request may include it so the model can explain the checked result. A test may compare the draft with an independently checked answer. The operating log may need only the run status and source ID, with no amount at all. Permission for the first use doesn't automatically cover the others.
| Use | Evidence and boundary to record |
|---|---|
| Operational records | Approved actuals and plan establish the figures; limit reads by department, period, account, and permitted purpose |
| Interpretive context | The materiality policy and owner explanation help interpret the figures; neither grants distribution authority |
| Evaluation references | Permitted test cases and independently approved expected results assess the packet; keep protected answers out of model-visible runtime context |
| Telemetry and feedback | Run status, source revisions, exceptions, and reviewer corrections support operations; collect only allowed fields and define retention |
The table's evaluation references are the records and expected answers used to test the service. Keep an answer used to judge the model outside the request the model receives; otherwise the test can hand it the answer. Check a reviewer's correction before adopting it as a test answer. Keeping feedback to diagnose a failure doesn't permit using it for model training.
For each use, record who owns it, who can see it, why you need it, how long you keep it, and how to correct or delete it. That lets the team check the actual drafting request and log, rather than treating permission to read finance records as permission for every copy.
Inspect the actual request sent to the model, including fallback services. Remove fields the draft doesn't need or the provider isn't allowed to receive. Enforce that in software. A prompt asking the model to ignore confidential columns still sends those columns. Don't send the request while access or retention questions are unresolved.
Price the repair someone will have to maintain
Suppose department codes differ between plan and actuals. The team could create a checked mapping for this department, fix the source, or use a temporary manual export. Compare what each option costs to set up and maintain, how long it takes, which reports it supports, and what can still go wrong.
Someone will need to notice changed mappings, access, plans, close corrections, and missing explanations. Give that person time and a way to pause the draft or use the manual process. A mapping that depends on its author's memory has a maintenance cost too.
Check whether this report is worth the repair and ongoing work. If it isn't, narrow the draft, keep the manual process, or stop. A shared repair may help other teams later, but that needs a separate business case. Don't charge this project's costs to imagined future users.
Keep each draft with the mapping, actuals, plan, calculation, explanation references, software configuration, and review decision that produced it. When act-sep-8 arrives, prepare a new draft beside the old one. Show finance what changed and ask it to approve the correction. Keep the earlier version so you can see what the reviewer saw.
Leave with a scoped decision
In the worksheet's assessment, latest-plan exists but nobody has established its approval or applicable revision. The comparison therefore stays paused. The team must obtain the approved plan; it cannot use the arithmetic illustration above as a substitute or switch to a figures-only report without finance agreeing.
For your own report, start with the figures the reviewer needs to compare. Ask their owners for the applicable sources, mark the gaps that prevent that comparison, and price those repairs. Leave unrelated cleanup out unless you can show how the report depends on it. In this case, the next request goes to the plan owner for the approved revision.