AI Adoption GuideNonprofitReport
Performance vs. Target Variance Report
LLM compares actuals to grant targets and generates a plain-language explanation of gaps and contributing factors.
Nonprofit processPlanFundOutreachDeliverMeasureReportStewardRenew
By Don, DoneThat’s AI coach · updated
What this use case covers
A performance vs. target variance report turns raw grant metrics into a readable account of where results land relative to commitments. For a grants or program manager, the hard part is rarely pulling the numbers. It is explaining, in plain language, which targets were met, which were missed or exceeded, and what likely drove the difference, without inventing a narrative the data cannot support.
In this workflow, an LLM receives structured actuals and the corresponding grant targets, then drafts a variance explanation: gap magnitudes, direction (over or under), and contributing factors drawn from the evidence you supply. Staff still own the numbers and the story. The model drafts; you approve, correct, or reject before anything reaches a funder or board packet.
When it helps (and when it does not)
This use case fits mid-cycle check-ins, quarterly progress narratives, and pre-submission packages where you must reconcile outcomes, outputs, or spend against the proposal or award agreement. It is especially useful when multiple indicators sit in one grant, or when several programs share similar target structures and you need consistent wording across reports.
It does not replace finance systems, impact databases, or your judgment about sensitivity. If actuals or grant targets are missing, incomplete, or not aligned to the same period and indicator definitions, the workflow should return empty output rather than a speculative write-up. A drafted explanation with no verified baseline is worse than no draft: it looks finished while the underlying comparison is invalid.
Use this after data quality checks, not instead of them. Unit mismatches, fiscal-year vs. calendar-year cuts, and double-counted participants are human and systems problems. The model can only reason over what you feed it.
Inputs the model needs
Feed the model a clear pair for each indicator: the target as stated in the grant (or approved modification) and the actual for the same reporting period, with units and definitions attached. Include indicator labels that match funder language where possible, so the draft does not invent alternate names.
Supporting context improves the quality of “contributing factors” without turning the draft into fiction. Useful additions include known operational notes (staffing gaps, delayed start dates, referral volume changes), prior-period actuals for trend context, and explicit constraints (what must not be claimed). Do not pass unverified anecdotes as facts; mark uncertain notes as provisional so the draft can hedge or omit them.
When any required field for a given indicator is absent (no target, no actual, or no period alignment), skip that indicator and emit no variance text for it. Prefer empty output over filler phrases that imply a comparison was made.
How the variance explanation should read
The draft should open with the gap itself: what was targeted, what was achieved, and the variance in absolute and relative terms when both are meaningful. Lead with the material gaps. Secondary indicators can follow in shorter form so a busy reviewer sees the risk first.
Contributing factors should be tied to evidence in the input. Distinguish correlation from confirmed cause. “Lower enrollment coincided with a two-month vacancy in the outreach role” is appropriate when that vacancy is documented. “Community interest declined” is not, unless your inputs substantiate it. Where factors are plausible but unconfirmed, the draft should say so and leave space for staff to confirm or cut.
Tone matters for funder-facing reuse. Neutral, specific language travels better than apology or spin. Overperformance needs the same discipline as underperformance: state the surplus, note drivers you can support, and avoid implying that excess automatically means the target was poorly set unless that analysis is in scope and evidenced.
Human review before anything ships
Treat every draft as a first pass for internal review. Confirm that figures match the source system and the award language. Correct any misstated units, periods, or indicator names. Rewrite or delete contributing-factor sentences that overreach. Decide what stays internal versus what goes into the funder narrative; a candid internal variance note is often longer and more operational than the external section.
Program and grants staff remain accountable for the story. The model does not approve numbers, certify compliance, or decide whether a variance requires a formal modification request. Those are organizational decisions. Pair this draft with your usual accuracy review so polished prose never outruns verified data.
If the package is assembled with other report sections, keep variance claims consistent with tables and dashboards elsewhere in the same submission. Contradictions between a narrative gap explanation and a summary table are a common rejection risk and a trust problem with funders.
Practical workflow tips
Standardize indicator IDs and period labels before prompting so the same grant can be re-run each cycle with minimal rework. Version the target set when modifications are approved, and point the run at the active version so the draft does not compare actuals to an obsolete baseline.
Run one grant or one reporting period at a time when stakes are high. Batch only when indicator schemas are identical and reviewers still check each grant. Log which inputs produced which draft so you can audit later if a funder questions a sentence.
Empty output is a feature, not a failure. If the run returns nothing, fix data completeness or alignment first. Forcing a narrative on missing targets or actuals creates false confidence and wastes review time on text that should never have been generated.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first