Grant Budget Tracking: From Proposal to Burn Rate
How a grant budget should live through its life — from proposal figures to approved lines, monthly burn rates, realignments, and the closeout report that matches to the shilling.
A grant budget is written twice: once in the proposal, optimistically, and once in reality, monthly, as money actually moves. Organizations that keep those two versions connected sail through reporting. Organizations that don't meet their budget again at closeout — as a stranger.
Stage 1: From proposal to approved budget
The moment a grant is signed, load the approved budget — not the proposal draft — into your system as budget lines with the donor's own numbering (1.1 Personnel, 2.3 Trainings…). Keep the donor's structure even if it differs from your chart of accounts; you will report in their structure, so track in it.
- Record the grant period, currency, and exchange-rate policy on day one.
- Map each donor budget line to your internal accounts once, in writing — not per transaction.
- Enter any co-funding or match commitments as their own lines; they get audited too.
Stage 2: Commitments, not just actuals
The classic overspend happens between the purchase order and the invoice. A line shows KES 400,000 available; three POs worth KES 350,000 are already out; someone approves another KES 200,000. Track committed spend (approved POs and contracts) against lines alongside actuals — available budget is what remains after both.
Stage 3: The monthly burn-rate review
Burn rate is the single most useful grant health number: percentage of budget spent versus percentage of time elapsed. Review it per line, monthly, with the program lead present:
| Signal | Reading | Action |
|---|---|---|
| Spend % ≪ time % (e.g. 25% spent, 60% elapsed) | Implementation is behind | Accelerate activities or request a no-cost extension early |
| Spend % ≫ time % | Line will exhaust before period ends | Slow down, or request realignment before overspending |
| One line over, another under | Budget shape was wrong | Formal realignment request — most donors allow ~10% flexibility between lines |
| Spend spike in final month | Panic spending | Expect audit scrutiny; document unusually well |
Realignments have deadlines
Most donors accept budget realignment requests until 1–3 months before the grant ends — after that, overspends are yours to absorb. A monthly burn review surfaces the need while the request is still possible.
Stage 4: Closeout
- Final report figures come from the ledger, not from a parallel spreadsheet — if you must adjust in Excel, the system was not the source of truth.
- Unspent balances: get written donor instruction (return, reallocate, roll over) — see restricted vs unrestricted funds.
- Donor-funded assets: produce the disposition report from your asset register — which means the grant tag has to have been put on the asset when it was recorded, since no system infers it from the purchase for you.
- Keep the complete grant file — budget versions, realignment approvals, reports — for the donor's retention period.
All four stages assume one thing: every transaction carried its grant and line from the moment it was entered. That tagging discipline is covered in depth in how NGOs can track donor funds properly, and it is what donor fund tracking software is for. Worth being precise about the word "structurally", though — here is what that means in our system and what it doesn't.
What AWRA OpsHub does today
- A grant as a project, holding its approved budget amount, period, currency and owner.
- Commitments already inside the spend figure — an approved purchase order counts against the grant before its invoice arrives, which is exactly the double-commit trap Stage 2 warns about.
- Spend assembled from real transactions: logged time at a cost rate, purchase orders, and coded expenses.
- Budget amounts at task level too, which is how you model the donor's individual budget lines.
- Consumed-percentage and over / at-risk / on-track status, per grant and across the portfolio.
- Required grant and budget-line tags via custom fields, so an untagged transaction can be made impossible to save.
- A grant-taggable asset register with custodian, movement history and verification dates for the closeout disposition report.
More we can add to your workspace
- Donor budget lines as a native structure. A project holds one budget amount today, so the donor's 1.1 / 2.3 numbering is modelled as tasks or as separate projects — workable, and a decision you make deliberately at grant setup. A budget-line table is the build.
- Committed and actual as distinct columns. Both land in one cost figure today, so you get "available after commitments" and separating the two is the build.
- A hard budget-line control, refusing a purchase that would exceed a line. Approval thresholds gate by amount today rather than by remaining budget.
- Budget versioning or realignment workflow. Realignments are edits to the budget figure; the trail is the audit log, not a version history you can diff.
- A time-elapsed or burn-rate comparison. Percentage consumed is reported; reading it against percentage of period elapsed is your arithmetic.
- Exchange-difference tracking per grant. Currencies and rates are held, but the accumulated difference Stage 1 asks you to record is your accountant's working.
- Assets auto-tagged from the purchase, inheriting the donor tag from the order that bought them rather than needing a field populated.
The pattern across that list is consistent and worth naming: we are strong on carrying the grant identity through real transactions and weak on grant-specific structures — budget lines, versions, realignments, exchange differences. Most NGOs get further than they expect on the first, and should plan the second as convention plus a monthly review. If donor budget lines as a first-class structure are non-negotiable for you, say so early and we will tell you plainly whether that is configuration or a build.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsWatch a grant budget live
Grant budgets with commitments already counted, spend built from real purchases, time and expenses, and required grant tags — from signature to closeout. Bring a real budget and we will model its lines with you before you buy.
See grant budget trackingFrequently asked questions
What is a healthy burn rate?
Roughly tracking time elapsed, line by line — 50% spent at 50% elapsed. Uniform perfection is suspicious too; seasonal programs legitimately spend unevenly. The point is that deviations are explained and acted on, not discovered at report time.
How much can we move between budget lines without asking the donor?
Read the agreement — commonly up to 10% of a line (or of total budget) may move between existing lines without prior approval, but new lines and personnel changes almost always need written consent. When unsure, ask; a realignment email costs nothing.
Should commitments really count against budget?
Yes. An approved PO is money you have promised. Budget available = approved budget − actuals − open commitments. Systems that show only actuals invite the double-commit overspend.
How do we track a grant budgeted in USD but spent in KES?
Hold the budget in the donor currency, book spending in KES at transaction-date rates, and report using the method the agreement specifies. Track the accumulated exchange difference explicitly rather than letting it hide inside line variances.
