How do I prove what was done for a grant report?
Prove it from records made during the funded period: each activity run as a recorded job with its steps, each deliverable carrying its acceptance, and spend logged against the grant's budget lines. Review the receipt and actual deliverable before accepting a handover.
Grant reporting has a structural trap: the report is written months after the work, by whoever is still around, from whatever records happen to exist. Funders know this, which is why reports are read skeptically and spot-checked. The escape is to make the funded work self-documenting while it happens, so the report's evidence exists before the report is contemplated.
The mapping is direct. Funded activities become jobs: the workshop series, the research workstream, the content programme, each run through the recording connection so its steps and outputs are saved as they occur (receipts in the AER-1 format, IETF Internet-draft-zambo-aer1-21). Deliverables become handovers, with the funder-side or partner-side acceptance recorded where a sign-off exists. Spend becomes a log against budget lines, kept monthly, with the agent and tool costs that grant budgets increasingly include named as their own lines rather than buried.
At report time the packet assembles in the funder's order: narrative claims down the left, the record for each claim linked beside it. Claims that the records do not support get rewritten to what the records do support, which is the healthiest editing a grant report can receive. Funders renew organisations whose reports read this way, because the second grant's monitoring becomes easy.
Template: the funder packet
Cover page: grant reference, period, preparer, one-paragraph summary. Section 1, activities: each funded activity with its job links (steps, outputs). Section 2, deliverables: each promised deliverable, its handover link, its acceptance state. Section 3, spend: budget line against actual, with tool and agent costs named; variances explained in one line each. Section 4, deviations: anything promised and not done, or done differently, stated plainly with the reason. Assembly rule: no claim enters the narrative without a record in Sections 1 to 3 behind it.
Worked example
Section 2's object, in public shape: https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 shows a deliverable job with steps and a recorded acceptance. A funder packet whose deliverables open like this can be spot-checked in minutes, which is precisely the experience that renews grants.
Frequently asked questions
Our grant does not require this level of proof. Why build it?
Because the report exists either way, and the choice is between assembling records during the work and reconstructing claims after it. The packet also answers the monitoring questions that arrive mid-grant, unannounced, in most funding relationships.
Can records from before we adopted this system be included?
As documents, yes, labelled as assembled after the fact. Keep the two kinds visibly separate in the packet; funders trust a packet that marks its own seams far more than one that hides them.
What about beneficiary data in the records?
Keep personal data out of job records by design: activities and outputs are recorded, beneficiary details stay in your case systems. The packet proves the work; it is not a data export, and its sharing should be scoped to the funder's reviewers.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai