Grant Reporting Cycles: When the Project Is the Unit of Account
Ask a finance manager at a commercial distributor what their reporting period is and you get one answer. Ask the same question at an organization running six donor-funded programmes and you get six answers, none of which is the financial year. One funder reports quarterly from July. Another wants a narrative and a financial report forty-five days after each tranche. A third reports on the life of the award, ignores your year-end entirely, and expects the figures to reconcile to a budget it approved eighteen months ago. Across East and West Africa this is not a niche case — for a large share of the organizations buying operations software, it is the whole of the case.
What that does to an operations system is specific and it is not the thing vendors demo. It moves the unit of account off the cost centre and onto the award. Not the department, not the branch, not the general ledger account — the grant. Everything spent has to be attributable to one, every attribution has to survive a question about it, and the whole thing has to be reportable over a period nobody else in the building uses.
The vocabulary problem, first
Before anything technical: a grant agreement and an operations system are two vocabularies pointed at the same money, and most implementation pain is a word in the first that has no object in the second. Here is the mapping as it actually stands, including the entries where the honest answer is that there is no object.
What the agreement calls it, and what it lands on here
On the grant agreement In the system
Award or grant A project
The natural fit, and a good one. A project has a code, a start and due date, an owner, a description and a budget figure, and it is the thing every cost can point at.
Grant code Project code
A short reference on the project record. Use the funder's own code here rather than an internal one — every downstream report shows it, and the reconciliation goes faster when the two documents share a string.
Donor or funder A customer
The nearest object, and the join is real: a project links to a customer. It is a commercial word doing a non-commercial job, which grates in demos and works in practice.
Commitment An approved or completed purchase order
Attributed to the project and counted at approval, not at payment. Pending and cancelled orders are excluded on purpose — a request is not a commitment.
Burn rate Budget consumed, as a percentage
Actual cost over the project budget. One number against one number. It is correct and it is coarse; it cannot tell you that you have burnt 90% of travel and 20% of equipment.
Budget line **No equivalent on a project**
This is the big one and it is dealt with in full below. A project carries a single budget amount. The tool that holds budget lines is keyed to departments and categories, not to awards.
Reporting period A date range you type
There is no period object with the funder's cycle on it. You enter the dates each time, and the quick-period presets are calendar-anchored, so "this quarter" is January to March whatever your funder thinks.
Eligible expenditure **No flag**
Nothing marks a cost as eligible or ineligible under an award's rules. Eligibility is decided by a person and recorded, if at all, in the description.
Cost share, match funding, in-kind **Not modelled**
A project holds one budget figure from one funder. Contributions valued rather than paid have nowhere to sit.
No-cost extension Change the due date
Works, and nothing recalculates. No period reopens, no report reissues, no alert fires. It is an edit to a date field and the consequences are yours to track.
Four of those ten have no object behind them. That is not a disaster — organizations run grants on systems with worse mappings every day — but it is the list to have in front of you during an implementation, because each one is a place where a process has to carry what the software does not.
What the project genuinely is good at
The critical part is above; this part is the reason the post is worth writing at all. Attributing cost to an award is the hard half of grant accounting, and it is the half that is properly built here. A project's actual cost is not one number somebody types. It is four streams, each pulled from the module where the spend really happened, each filtered so that a request is not counted as a cost.
What a project's actual cost is made of
Two of those filters are worth pausing on because they are the difference between a costing engine and a sum. A rejected expense claim used to count as cost in an earlier version of this code, which inflated burn against every budget on the system; it is now excluded, and the fix is recorded in the source rather than quietly applied. And stock is valued at the cost stamped when it was issued, so a later purchase that moves your weighted average does not silently change the cost of a programme that closed last year. Lines issued before that stamping existed carry no cost and are skipped rather than estimated. One currency throughout — hold on to that assumption, it comes back.
That is a real answer to "where did the money go", assembled from procurement, HR time, expenses and the store rather than re-keyed into a grants spreadsheet. It is the part of donor reporting that usually consumes a finance officer's last week of every quarter, and it is the part this does properly.
And the thing it cannot do: the budget has no lines
Here is the gap, stated as precisely as we can. A project carries one budget figure — an amount, with no period and no breakdown. The system does have a proper budgeting tool, with amounts, categories, periods and start and end dates. That tool is keyed to a department. There is no link from a budget to a project, in the model or in the database.
The budgeting tool is a cost-centre tool. The costing engine is an award tool. They are both good and they do not meet.
Read out of the schema, 2026-08-12
Which matters because a donor budget is almost never one figure. It is personnel, travel, equipment, sub-grants, monitoring and evaluation, and an indirect cost recovery with a percentage attached — and the report the funder wants is that structure with actuals beside it and variances explained. What you can produce here is the total, correctly, and the constituent transactions, correctly. Turning those into the funder's lines is work done outside the system.
That is not fatal and it is not unusual — plenty of well-run programmes do exactly this, with the award structure in a controlled workbook and the transaction detail in the operations system. What is fatal is discovering it in month two of an implementation, after somebody demoed a budget screen and nobody asked which object it hangs off.
How to set it up, given that
If one funder, one budget, one currency
Use the project as the unit of account and let it do the work
Put the funder's grant code in the project code, the award value in the budget amount, and the award dates on start and due. Every purchase order, expense claim and stock issue gets attributed at the point it is raised — not reclassified later — and the profitability report is your quarterly figure. This is the case the product is genuinely good at.
If the funder reports against budget lines
Keep the lines outside and reconcile to one number
The discipline that works is: the project total is the control figure, and the line-level workbook must reconcile to it exactly, every period, before anything goes to the funder. Use expense categories and departments consistently enough that the transaction listing can be pivoted into the funder's lines rather than re-read line by line. Do not maintain two sets of actuals; maintain one set and one mapping.
If two funders share one programme
Split into one project per award
A project holds one budget and one customer link, so co-funding has no representation. One project per award, with a shared naming convention, and shared costs apportioned at the point of entry by a rule you wrote down. Apportioning afterwards is where audits go wrong, because the rule is never recorded next to the split.
If the grant is denominated in a currency you do not spend in
Treat the project total as one currency and hold the funder view separately
Purchase orders carry no currency of their own; expense claims do, and the project cost total sums those amounts without reading that column. So a project mixing currencies produces a total that is arithmetically a sum and economically nothing. Book to the project in one currency, keep the funder-currency position outside, and never present the two as one figure.
That last one deserves its plainest possible statement, because it is the kind of defect that produces a confident wrong number rather than an error message: if you book expenses to a project in more than one currency, the project's cost total adds them together. It is narrow — it is the expense stream, not the purchasing or labour streams, and an organization that books everything in its own currency will never meet it. But grant work is exactly where mixed currencies show up, which is why it is here rather than in a footnote.
Where the system stops and your finance team starts
Draw this line before the implementation, not during the first quarterly report
What the system holds
Transactional truth, attributable and evidenced.
- Every cost attributed to an award, across purchasing, labour, expenses and stock, with the document behind each one.
- Approval trails on the purchase orders and expense claims that make up the spend.
- A total actual against a total budget, and a burn percentage from those two.
- Delivery status — tasks, milestones, logged hours — beside the money, on the same record.
- Supplier records and the procurement evidence a funder audit asks for.
What your finance team still holds
Structure, eligibility and judgement.
- The award budget broken into the funder's own lines, and the mapping from your categories onto them.
- Whether a given cost is eligible under that award's rules.
- Cost share, match funding and anything contributed in kind.
- The funder's reporting calendar, and the discipline of running the same date range every time.
- Indirect cost recovery, and any apportionment rule shared across awards.
- The funder-currency position, whenever it is not the currency you book in.
What has to cross the line every period
- One control figure — the project total — that the line-level workbook must reconcile to exactly before anything is submitted.
- A transaction listing for the period, pivotable onto the funder's lines because the categories were applied consistently at entry.
- The variance explanations, which come back the other way and belong in the project description or its status notes, not in an email thread.
The test of whether this line is drawn in the right place is simple: when the funder queries a figure, how many systems does somebody open? If the answer is one workbook and one project record, it is drawn well. If the answer includes a bank statement and three inboxes, it is not.
What AWRA OpsHub does today
- A project as a first-class unit of account, with a code, dates, an owner, a customer link and a budget, that every operational document can be attributed to.
- Four cost streams accumulating against it — logged labour at a stamped cost rate, approved purchase orders, committed expense claims, and stock issued at the unit cost stamped at issue.
- Status filters that mean a request is not counted as a cost: pending and cancelled orders, and pending or rejected expense claims, contribute nothing.
- A profitability report per project — budget against actual, with the payout position — plus delivery analytics and a timesheet and billable-hours report over any date range.
- Procurement evidence behind the spend: approval trails, supplier records and document expiry, which is the half of a funder audit that is not about arithmetic.
- Milestones, tasks and logged hours on the same record as the money, so a delivery report and a financial report describe the same object.
What it does not do
- Budget lines on a project. One budget figure, no period, no breakdown — and the budgeting tool that does have lines and periods is keyed to departments, with no link to a project anywhere in the schema.
- Any eligibility flag. Nothing marks a cost as eligible or ineligible under an award's rules.
- Co-funding. One project holds one budget and one customer, so two donors on one programme means two projects and a manual apportionment.
- Cost share, match funding or in-kind contribution as anything the system understands.
- A funder reporting cycle as an object. Date ranges are typed each time and the quick-period presets are calendar-anchored, so a July-to-September quarter is never a preset.
- Currency awareness in the project cost total. Expense claims carry a currency column and the total ignores it; purchase orders carry no currency at all.
- Indirect cost recovery, sub-grant tracking, or any donor-specific report format.
Not ours, by choice
- We do not produce funder-format reports and are not trying to. There are hundreds of them, they change, and a system that generates one badly is worse than a clean transaction listing somebody maps deliberately.
- Nothing here is advice on grant compliance or on what any particular agreement requires of you. Eligibility is a judgement your finance lead and your funder make.
Budget lines on a project is the build worth doing and it is the one we would scope first, because everything else on that list gets easier once it exists: lines carry categories, categories carry eligibility, and a period on a line is the funder's cycle finally represented as data rather than as a date somebody retypes. It is a real build — a table, a form, a reallocation rule and a rewritten profitability report — not a configuration change, and we would not pretend otherwise. Currency on the project cost total is much smaller and closer to a defect: the expense stream already carries the column, and the total needs to either scope to one currency or refuse to add. Co-funding and eligibility flags are each a step beyond the budget-lines work and are best specified after it rather than alongside it. The way this goes is that you put your actual funder requirements in front of us — the agreements, not a summary — and we return a written scope, a timeline and a price before anything begins. The precedent that market-specific work gets finished here is Kenya, where a live tax-authority integration and a maintained statutory payroll engine are both ours to run.
The budget-line gap was found by reading our own budgets table against a grant agreement's structure, and it is a clean example of a product built for one shape of buyer meeting another. Nothing about the costing engine is wrong. It was built for a job that has a cost centre behind it, and an award is not a cost centre.
The grants layer is a specification away, not a rewrite
Everything missing above sits on top of a costing engine that already works. That is the expensive part and it is done.
Budget lines on the award
Lines with categories, periods and their own amounts, reallocation with a trail, and a profitability report that reports against them.
The funder's cycle as a period
A reporting cycle held on the award, so a quarter that starts in July is a preset rather than two dates somebody retypes and occasionally mistypes.
Currency-correct project totals
A total that scopes to one currency and says so, instead of adding across the currency column the expense record already carries.
Co-funding and cost share
More than one funder against one programme, with the apportionment rule recorded next to the split rather than in somebody's memory.
We do not promise roadmap dates. You describe the requirement, we return a written scope, timeline and cost, and you decide before anything starts.
Show us the agreements you actually report againstThe short version
If your question is "where did this award's money go, and can I prove it", the answer here is genuinely good — four cost streams, properly filtered, attributable to a single award, with the procurement evidence attached. If your question is "show me actuals against the funder's budget lines for their July quarter", the answer is that the system gives you the total and the transactions and your team does the rest. Know which of those two questions your funders ask before you buy anything, from us or from anyone. The first is an engineering problem and it is solved. The second is a modelling problem and it is not.
Running donor-funded programmes and weighing this up
Send us the reporting requirements from one real agreement and we will tell you which parts this handles today, which are a process alongside it, and which would be a build. If the honest answer is that your funder's structure needs more than we have, we would rather say so now than in your first quarterly report.
See plans & pricingFrequently asked questions
Can I report to a donor by project rather than by department?
Yes for spend, and that is the part most systems get wrong. A project accumulates four cost streams — logged labour, approved purchase orders, committed expense claims and stock issued from your own store — and the profitability report shows actual against budget per project. What it does not give you is a budget broken into the donor's own lines, because budgets in this system are held against a department and a category rather than against a project.
Does the system understand grant budget lines?
No. A project carries one budget figure. The budgeting tool that supports lines is keyed to departments and categories, not to projects, so a budget split across personnel, travel, equipment and overheads has to live alongside the project rather than inside it. This is the single largest gap for donor-funded work and it is a build rather than a setting.
Can two donors fund one project?
Not as one project. A project holds a single budget figure and a single customer link, so co-funding is modelled by splitting the work into one project per funder and reconciling the two outside the system. That is workable and it is not elegant.
What happens if my grant is in one currency and my spending is in another?
Be careful here. Purchase orders carry no currency of their own, expense claims do, and the project cost total adds expense amounts without regard to that column. If everything you book sits in one currency this never bites. If it does not, treat the project total as a figure for one currency only and hold the funder-currency view separately.
Does the project reporting period follow the grant's cycle?
Only in the sense that you type the dates. A project has a start date and a due date; report date ranges are entered by hand, and the quick-period presets are calendar-anchored. Nothing knows that your funder's Q3 runs July to September.
