Multi-Donor Fund Accounting Without Spreadsheets
Three donors, five grants, one organization — how to run multi-donor accounting from a single ledger: dimensions instead of spreadsheets, shared-cost allocation, and donor reports built from one set of tags rather than five workbooks.
One grant is manageable in a spreadsheet. Three grants from three donors — each with its own budget structure, currency, reporting calendar, and rules — is where spreadsheet accounting quietly collapses. The symptoms are familiar: a master workbook only one person understands, month-ends that take ten days, and donor reports that almost reconcile.
Why the spreadsheet fails at three grants
- Double capture — every transaction is entered in the cashbook and again in the grant tracker, and the two drift.
- Structure collision — Donor A budgets by activity, Donor B by cost category; the workbook contorts to serve both.
- Shared costs by vibes — rent split "roughly a third each" changes with cash flow, which auditors read as manipulation.
- One-person risk — the finance officer who built the workbook leaves, and institutional memory leaves with them.
The fix is dimensional, not more tabs
Multi-donor accounting works when your ledger carries dimensions: every transaction is posted once, tagged with grant, budget line, and cost center. Reports are then filters — the same data answers KRA (by account), Donor A (by activity), and Donor B (by category) without re-entry. This is the entry-time tagging principle from donor fund tracking, applied organization-wide.
| Question | Spreadsheet answer | Dimensional answer |
|---|---|---|
| What did Grant A spend on trainings in Q2? | Open tracker, hope it matches the cashbook | Filter: Grant A + training lines + Q2 |
| How is our core funding holding up? | Reconstruct from what is not in any tracker | Filter: unrestricted fund, budget vs actual |
| Which grants fund the finance officer? | Check the allocation memo… if updated | Allocation postings against each grant, month by month |
| Total organizational spend by month? | Consolidate five tabs and pray | One report, no consolidation step |
Shared costs across donors
Rent, utilities, audit fees, the ED's salary — every multi-donor NGO must split them. The defensible pattern: a written allocation basis (headcount, effort, or direct-cost ratio), applied identically every month, visible in the ledger as allocation postings. Two donors must never be charged for the same shilling — the allocation percentages across funders always total 100%, with the unfunded remainder hitting core funds explicitly.
Watch the NICRA/overhead terms
Some donors pay a negotiated indirect cost rate instead of line-item shared costs; others cap overheads at 7–10%. Where a grant pays indirects, its share of shared costs comes from that pool — charging line-item rent on top is double recovery, a serious finding.
Calendars, currencies, and closeouts
- Maintain one reporting calendar for all grants — deadlines, formats, and responsible staff — reviewed monthly; late reports damage relationships faster than small variances.
- Hold each grant in its agreement currency with a consistent rate policy; report exchange differences explicitly (see grant budget tracking).
- Stagger closeout workloads: each ending grant needs its final report, asset disposition, and unspent-balance instruction — pipeline them rather than colliding in one month.
What AWRA OpsHub does today
- A grant maps to a project, carrying its own budget amount, dates and owner.
- The project tag is native on purchase orders, expenses, customer invoices, and the tasks and time records that generate labour cost.
- Donor, grant reference, budget line and fund class as custom fields on projects, expenses, purchase orders and requisitions — settable as required, so a transaction cannot be saved unclassified, and carried through to reports and exports.
- Approval rules that read the amount on a document, so a donor threshold becomes a gate rather than a memo.
- Budget vs actual per project, with over / at-risk / on-track status.
- Multi-currency: a base currency for the organisation, exchange rates held in the system, and a currency on each expense.
- An audit log of who changed what, which is what a donor auditor actually asks to see.
More we can add to your workspace
- A fund-accounting module: a built-in restricted and unrestricted fund type, and an automatic release-from-restriction entry. Fund class is a field you define today, so reporting on it is reporting on your own tag.
- A block on an ineligible charge. Tagging a cost to a restricted grant records it today; testing it against that grant's rules is the build. Until then the control is your approval chain.
- A payroll allocation across grants. Payslips carry no project or grant, so splitting a shared salary happens as postings outside the payroll run — yours to make and defend.
- A shared-cost allocation engine, apportioning rent by a driver and posting the split for you.
- Stock issues costed to a grant, with a native project link on materials leaving the store.
- Donor report templates. You can build, save, share and schedule a report per donor against your own tags; you cannot reproduce an arbitrary donor workbook layout inside the builder — expect to export and finish the formatting. The builder's limits are set out in the report builder guide.
Read that second list as the shape of the work, not a reason to stay in the workbook. The dimensional discipline this post describes is genuinely achievable here — but it is a structure you configure and a set of postings you own, not a fund-accounting engine you switch on. If you need one of those items as a hard control rather than a convention, raise it before you buy and we will tell you plainly whether it 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 needsThe payoff of dimensional accounting is compounding: the fifth grant costs almost nothing to add, because the structure already exists. That scalability is the core of what an NGO-governed ERP provides over accounting software plus heroics. The mechanics of splitting one cost across several funders are the same ones any project business uses — project cost allocation covers them without the donor vocabulary.
Post once, report from one set of tags
Grants as projects, donor and budget-line tags carried on every purchase, expense and [invoice](/glossary/invoice), and reports as filters — with the allocation postings and fund policy staying yours. Bring two real grant agreements and we will map them live.
See multi-donor trackingFrequently asked questions
Do we need fund accounting software, or will QuickBooks classes work?
Classes can represent grants adequately at small scale. The breakpoints are procurement trails, advance liquidation, budget-line commitments, and asset custody — controls that live outside any ledger. When findings start appearing in those areas, the gap is the system around the ledger, not the ledger itself.
How do we allocate the Executive Director's salary?
Same as any shared cost: a written basis (typically level-of-effort), donor-permitted percentages, applied consistently. Note some donors cap or exclude senior management costs — read each agreement before building the allocation. One mechanical caveat about our own system, because it cuts against us: payroll does not allocate across grants. A payslip carries no project or grant tag, so the split is posted separately against each project rather than produced by the payroll run. That works and it is auditable, but it is a monthly posting somebody owns, not an automatic output.
One donor's report format is completely different from our books. What now?
Map their structure to your dimensions once, at grant setup, and generate their report through that mapping. The mistake is keeping a parallel spreadsheet in their format all year — that recreates the double-capture problem the ledger was meant to solve.
How do we show donors our co-funding commitments?
Track match contributions as their own budget lines with the same evidence discipline as donor funds — in-kind contributions valued per a written policy. Unmet match commitments are findings too, so burn-rate reviews should cover them.
