How to Write Variance Commentary from Your Ledger

Redaction is not about hiding interesting things from the model. It is about not pasting identifiers into a system you have not cleared for them. Keep the shape of the data and drop the identities:

• Customer names become "Customer A (enterprise, top 5 by ARR)" or simply "a customer in segment 2."
• Employee names become "a support hire in month 2" or "role 14, engineering."
• Vendor names become "vendor in category 3" or, if concentration matters, "a vendor that accounts for 22% of this line."
• Contract numbers, bank details, card numbers and personal email addresses are removed entirely.
• Anything with a named individual attached, including bonus accruals and severance, is either aggregated or left out.

Investor communication guidance already points the same way for sensitive content, recommending that founders anonymize customer names when discussing sensitive contracts or proprietary matters, as this investor update guide advises. Finance teams follow a similar discipline when they delegate variance work: a platform that runs root-cause analysis on every material variance still ties each explanation back to specific GL transactions with cell-level access control deciding who sees what, per Cube's description of its variance workflow. The lesson for a ledger export is that the mapping from "Customer A" back to the real account can live in your workbook, not in the prompt.

Two rules of thumb. First, if you could not paste the row into a room full of investors, redact it. Second, keep the numeric detail even when you drop the identity, because "the top five enterprise accounts renewed on time" is a fact the model can use, while "Acme and four others renewed" adds only risk.

Without a threshold, controllers either explain every line or only flag the single largest number, and both fail the reader. A blended threshold solves it: flag any variance that is both large in dollars and large in percentage terms, so a $2,000 line that happens to be 50% of a tiny budget stays quiet while a six-figure miss in a large line gets a paragraph, per the same commentary guide. Thresholds should be agreed with the person who reads the output before the first draft lands.

A worked example makes this concrete and shows the rule in action. Take this month's operating lines (illustrative figures, built on the sample layout that Cube uses to demonstrate budget versus actual on live data):

Two rows out of six earn commentary, which is the point: the draft stays short enough that the reader actually reads it. Note the trap in the first row. Revenue beat plan by $170,000, the largest dollar difference on the page, yet it fails the percentage test because 3.7% is inside noise. That is a deliberate exception you should decide on rather than delegate, since a revenue beat usually belongs in the narrative even when it is proportionally small. Tell the model which rows are in scope and why, and it will not argue.

Give the model four blocks in this order: role and reader, the rules, the table, and the output format. Separating them keeps the instructions from bleeding into the narrative.

ROLE: You are writing variance commentary for a founder reviewing
the month with their operating team. The reader knows the business
well and will check every number against the attached table.

RULES:
1. Write only about the rows listed as IN SCOPE. Do not mention
   other rows, totals or ratios.
2. For each in-scope row, write one paragraph of 3 to 5 sentences:
   - sentence 1: the line item, the variance in dollars and percent,
     and whether it is favorable or unfavorable;
   - sentences 2 to 4: the most likely driver, taken only from the
     ledger_note column. If the note is empty or vague, write
     "cause not yet confirmed" and state what would confirm it.
3. Do not infer a cause that is not supported by ledger_note. Do not
   describe the same driver twice.
4. Do not use the words "significantly", "impactful" or "various".
5. Do not calculate new numbers. Use only variance_dollars and
   variance_pct as given.
6. After the paragraphs, list any row where ledger_note was
   insufficient, as a bullet under the heading NEEDS CONTEXT.

TABLE:
account_code | line_item | actual | plan | variance_dollars |
variance_pct | favorable_unfavorable | period_basis | ledger_note

OUTPUT: plain paragraphs, one per in-scope row, then NEEDS CONTEXT.

Rule 5 is the one that saves you time. Subtraction errors and percentage mistakes are the most common failure in AI-drafted finance text, and forcing the model to reuse your pre-computed figures removes the class of error entirely. Rule 2's fallback phrase is the second safeguard: a model with no note to work from will otherwise produce a confident-sounding cause that nobody can source, which is worse than an honest gap.

The shape of these instructions follows published prompt patterns for variance work. An example prompt in this FP&A prompts collection gives the model context (a revenue miss with three named segment drivers), an objective (a three-paragraph board narrative), a reasoning instruction (analyse the interplay between segments) and an evaluation step (review the draft for defensiveness). That last step is worth copying: add a line asking the model to reread its own draft and flag any sentence it cannot support from the table.

The model handles wording. You confirm causes. Work through this checklist in order and the review takes about ten minutes for a typical operating review.

The timing-versus-structural distinction deserves its own pass because it changes what the reader does next. The five-step method is explicit that timing differences, such as a cost that lands a month later, resolve themselves, while structural differences, such as a higher purchase price that sticks, belong in the forecast, per that guide. A model reading a note that says "invoice received in month 3 instead of month 2" will often describe the variance as a trend unless you tell it otherwise, so add the classification to your notes column: timing, structural, one-off or error.

One more check that pays for itself. Reconcile the scope list against your own threshold run, not against the model's selection. If the model produced commentary on a row you excluded, that is a scope breach. If a row you expected is missing, it may have been filtered upstream in the export. Both are one-minute fixes, and both catch problems the narrative itself will hide.

The notes are empty. The draft turns into a restatement of the table, which readers skip. Fix it upstream: require a note on any row above the threshold before the export runs, even if the note is "no explanation yet, investigating with the platform team." An honest gap is usable; an invented cause is not.

A large percentage on a tiny line dominates the draft. This is the materiality problem, and the blended threshold solves it. If your board still wants small-line commentary, put those rows in a second batch and label the section clearly so the reader knows the scale of each item.

Two paragraphs describe the same driver. This happens when, for example, a tooling migration inflates both cloud costs and contractor spend. Merge the rows into one narrative or add an explicit instruction to treat related rows as a group.

The model calls a favorable variance unfavorable. Costs above plan are unfavorable even though the arithmetic difference is positive, which is precisely why the label column exists in the method described above. If your export lacks the label, add it before prompting rather than hoping the model infers the sign convention from context.

Revenue misses are described without splitting price and volume. A single revenue variance only means something once it is split, for example a plan of 10,000 units at $50 actual against a different mix of price and volume, per the worked example in this method. If your ledger notes do not carry that split, the model cannot produce it, and the paragraph should say so.

The draft reads defensively. Variance commentary is read by people scanning for signal, and hedging wastes their attention. Ask for the cause first and the action second, with no adjectives about how the team performed.

The workflow is a loop, not a one-off. Close the month, export the accounts, write the notes, run the threshold, prompt, check, publish. Each pass improves the next because the notes column accumulates the institutional memory the model draws on. After a few cycles most drafts need edits to two or three paragraphs rather than all of them.

If the export itself is the bottleneck, a specialist can build the pipeline once and hand you a workbook that refreshes on open. Describe the site, app, document or plan you need at Quanta and a specialist picks it up and builds it with you. If your team runs several models side by side for drafting, summarizing and checking, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, prepaid and priced in US dollars.