The job: two stories that reconcile
Every funder report is two stories told from the same records. The financial story — what was spent, against which budget lines, with what remaining — follows 2 CFR 200.328 on federal awards and the agreement's terms on private ones. The performance story — what was accomplished against the award's objectives, and why any goal was missed — is 2 CFR 200.329's explicit requirement and every program officer's implicit one. The report succeeds when the two reconcile: the spending explains the accomplishments, and the evidence supports both.
Grant reporting software exists because those records accumulate in different places all year — the ledger, the program team's files, a photos folder, an inbox — and converge only in the two panicked weeks before the deadline. The fix is structural, not motivational: keep the evidence attached to the obligation it proves from the day it is produced.
Evidence tied to the deliverable
In GrantConsole, each deliverable on a grant lists the evidence it requires, and documents attach to that deliverable — an attendance sheet to the workshop milestone, the reconciled ledger export to the quarterly financial report, sign-offs to the deliverable they approve. Every deliverable then carries a live attached-versus-required count.
That one structure changes the pre-report period. Two weeks out, the question is not "where is everything?" but "which counts are short?" — and the software is already asking it: a report due within 30 days with evidence incomplete raises a warning, and inside the final 14 days a gap becomes an urgent one that names the report, the days remaining and the exact number of items missing. Readiness for upcoming reports is scored from what is actually attached, weighted toward evidence over drafting progress, because evidence is the half that cannot be produced at the last minute. A grant with no reports due soon simply reads as ready — a report due in ten months should not drag today's number down.
The deadlines themselves come from the same record: due dates live on the deliverables, in your workspace's timezone, on the schedule your award actually sets — the cadence rules and lead-time habits are covered in the reporting calendar template, which is the spreadsheet version of this page.
The reporting packet
When it is time to prepare — or when a board member, auditor or program officer asks a question — the packet assembles a grant's complete record in one document:
- The grant itself: funder, status, internal owner, period of performance, awarded amount.
- The budget: every line with planned and spent amounts, and totals — planned, spent, remaining — computed from the same integer-cent records the warnings use.
- The evidence checklist: every deliverable with its type, due date, status and attached-versus-required count, followed by each attached document with its name, type and who uploaded it.
- Open work: tasks with status and priority.
- Open risks: each active warning with its reason — the rule, the record and the date that triggered it.
- The full activity history, deliberately unabridged, because a compliance document should carry the whole trail rather than the recent window.
The packet and the portfolio views export to CSV, so the numbers flow into whatever your finance team does next. What the packet is not is the report: it is everything the preparer needs, ordered the way a reviewer thinks — Grants.gov's advice to clarify expectations with your grant and program officers is easier to follow when the record you are discussing is one document instead of five systems.
Report-day workflow
A reporting cycle in practice: the deliverable exists from award setup with its due date and evidence list. Work happens; evidence attaches as it does. Thirty days out the deliverable appears in the readiness horizon and any gap starts surfacing. Two weeks out, the internal reviewer walks the packet — numbers against narrative, evidence against claims. The preparer drafts in the funder's format, the report is submitted through the funder's channel, the deliverable is marked submitted with proof filed, and the activity history records who did each step. At period end, the same packet is most of closeout.
What stays with your team
GrantConsole does not write the narrative, decide what a shortfall explanation should say, file with agency systems or foundation portals, or replace the accounting system the financial figures reconcile to. It also does not interpret the award — which reports are required, on what dates, with what evidence, is a reading of the award document your team does once at setup. The software's job is narrower and relentless: hold that reading, keep the evidence with the obligation, warn with reasons while there is time, and produce the record on demand.
Role-based access — owner, manager, member, viewer, enforced by the server — keeps report preparation appropriately scoped, and the activity history answers the reviewer's standing question, "who changed this and when?" The broader tracking side of the product — deadlines, renewals, restricted-budget burn, the full set of explainable risk rules — is described on the grant tracking page.
See a report take shape
The public demo is a seeded workspace with reports at every stage — evidence complete, evidence short with the deadline near, submitted with history behind it — so you can walk the exact flow above on example data. It opens at /signin, no sign-up, no sales call.