How NGOs Can Track Donor Funds Properly
A practical system for tracking restricted funds from grant agreement to donor report — fund segregation, budget lines, burn rates, and the audit trail that keeps donors funding you.
Donor confidence is an NGO's real currency. Programs get refunded when reports are accurate, on time, and boring — no surprises, no unexplained variances, no co-mingled funds. Yet most fund-tracking problems are not caused by dishonesty; they are caused by structure. Money arrives into one bank account, gets spent from one cashbook, and someone reconstructs "which donor paid for this" at report time.
This guide lays out the structure that makes donor fund tracking routine instead of forensic. Not automatic — no system removes the judgement — but routine, which is the realistic and sufficient goal.
The core principle: tag money at entry, not at reporting
Every fund-tracking failure traces back to the same root: transactions recorded without their grant identity, then classified weeks later from memory, receipts, and WhatsApp threads. The fix is procedural — every transaction (expense, advance, purchase order, payroll allocation) must carry three tags the moment it is created:
- The donor/grant it is funded by (e.g. "EU Resilience Grant 2026").
- The budget line within that grant (e.g. "2.3 Community trainings — venue costs").
- The restriction status — restricted program funds vs unrestricted core funds.
When tagging happens at entry, a donor report is a filter, not a project. When it happens at reporting time, every report is an archaeology dig.
Restricted vs unrestricted: keep the wall visible
Restricted funds may only be spent on what the grant agreement specifies. Unrestricted funds (membership fees, local fundraising, some core grants) keep the lights on. The two must never blur, because "we borrowed program money for rent and returned it" is a finding, even with good intentions.
The overspend trap
The most common co-mingling isn't theft — it's a budget line that ran out. Fuel under Grant A is exhausted, the vehicle still needs to move, so fuel quietly books to Grant B. Three months later neither grant's report reconciles. A system that shows line-level burn rates before spending prevents this; a cashbook only reveals it after.
What to track per grant
| What | Why donors ask for it | Where it usually breaks |
|---|---|---|
| Budget vs actual per line | Proves spending followed the approved budget | Actuals classified at report time, not entry time |
| Burn rate vs time elapsed | Flags under/over-spending while it is still fixable | Nobody sees it until the mid-term report |
| Procurement trail per purchase | Proves value for money on program purchases | Quotes and approvals live in email, not with the transaction |
| Advances and liquidations | Field advances are the #1 audit finding | Advances issued via mobile money with no liquidation deadline |
| Asset register per grant | Donor-funded equipment must be handed over or accounted for | Assets recorded in a separate file that never meets the ledger |
| Exchange gains/losses | Grants in USD/EUR spent in KES create differences | Rates applied inconsistently across the grant period |
Field advances: where fund tracking goes to die
Program officers receive advances — often via M-Pesa — spend them across activities, and liquidate with a mix of receipts and explanations. Uncontrolled, this creates a growing pool of "money in the field" that belongs to no budget line. The discipline that works:
Advance rules that survive audits
- Every advance is tagged to a grant and activity before it is paid.
- No second advance while one is unliquidated.
- A liquidation deadline (e.g. 7 days after the activity) that is written down and reviewed on a schedule — and be clear-eyed about what your system actually does here. In ours it is a report you build over outstanding items and a person who reads it, not a lock that refuses the next payment. Ask any vendor to demonstrate the enforcement rather than describe it.
- Receipts are captured at the point of spending rather than reconstructed later — and stored somewhere retrievable by grant and activity. Check how literally your system does this: ours holds evidence in a document vault with an access log, but does not bolt a receipt onto the expense line, so the cross-reference is a convention you enforce.
- Unspent balances are returned and receipted, not rolled into the next activity.
The monthly rhythm that keeps you audit-ready
- Weekly: review new transactions with missing grant/line tags — the number should be zero.
- Monthly: produce budget-vs-actual per active grant; investigate any line above 90% with time remaining.
- Monthly: age all open advances; anything past its liquidation deadline goes to management.
- Quarterly: reconcile the donor-funded asset register against physical checks.
- Per report: the donor report should come from the system's numbers directly — if you are adjusting figures in Excel afterwards, the system is not the source of truth yet.
What AWRA OpsHub does today
- A grant modelled as a project, with its own budget, dates and owner.
- Native grant tagging on purchases, expenses, invoices and costed time, so the classification happens at entry as this post argues.
- Donor, budget line and fund class as custom fields that can be made required — the mechanism that turns "zero untagged transactions" from a wish into a rule.
- Approval chains that read the amount on a document, so the donor's threshold is a gate.
- Spend against grant budget, live, with approved orders already counted as commitment.
- A donor-funded asset register with custodian assignment, movement history and verification dates.
- An audit log of who changed what, which is what a donor auditor actually opens.
- A document vault for supporting evidence — classified, checksummed, access-logged, and archivable.
- Documents attach to the transaction itself — shipped 2026-08-01. Expenses, purchase orders, requisitions, quotations and assets all take Document Vault files directly: checksummed on upload, classified, every download logged, and archived rather than deleted when removed. The receipt now lives on the record it evidences instead of in a naming convention.
More we can add to your workspace
- Attachment is possible, not compulsory. The hard link now exists; nothing refuses an expense or an order that has no evidence behind it, so a donor-grade "no payment without a receipt" rule is still enforced by your process rather than by the system.
- An advances module: an advance issue, a liquidation workflow, and a "one advance at a time" rule. Today an advance is modelled as a payment and reconciled by discipline and a report — which makes this the single largest build in this post, given that field advances are the sector's most common audit finding.
- Restriction-status enforcement, refusing an ineligible charge against a restricted grant. Fund class is a tag today.
- A payroll allocation to grants. Payslips carry no grant, so staff-cost splits are posted separately.
- Exchange-difference reporting per grant. Rates and currencies are held; the gain/loss presentation for a donor report is your accountant's working, not a system output.
- Donor report templates. Reports are built against your own tags and exported; an arbitrary donor workbook layout is finished outside the builder.
- Automatic reconciliation of a mobile-money statement. M-Pesa collection and payout are integrated, but matching a bulk field-disbursement statement line by line is manual.
Advances are the one to weigh hardest, because this post correctly identifies them as the highest-risk area in NGO fund tracking and the module is a build rather than a setting. What ships today makes advances visible — tagged, evidenced and reportable — and controlled is what the build adds. If enforced liquidation matters to your donors, treat it as scope to be priced, and hold every other vendor to demonstrating it live rather than describing it on a slide.
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 needsFor the procurement side of donor compliance — committees, quotations, and documentation — see our companion guide on procurement challenges in NGOs. If you are still choosing a system, start with what to look for in an NGO ERP, or see how this structure works in practice in AWRA's donor fund tracking software. Two adjacent disciplines are worth reading alongside this one: expense claims and approvals for the mechanics of coding and approving field spend, and who changed what for the trail an auditor follows.
Track every grant to the shilling
Grants as projects, required donor and budget-line tags on every purchase and expense, commitments counted, assets under custody, and a full change log — with the advance-liquidation control named honestly as work rather than sold as a feature.
Talk to us about donor fund trackingFrequently asked questions
Can we track donor funds properly in QuickBooks or Excel?
Up to a point — classes in QuickBooks or disciplined spreadsheet structures can represent grants. The gaps appear where accounting tools stop: procurement approvals, quotation trails, field advances, and asset custody are not ledger entries, and that is where audit findings come from.
What is a burn rate and why do donors care?
Burn rate compares money spent against time elapsed in the grant period. If 70% of the timeline has passed but only 30% of funds are spent, the program is behind and the donor may claw back funds; the reverse means you will run out early. Tracking it monthly per budget line lets you request realignments while there is still time.
How should we handle a grant received in USD but spent in KES?
Record the grant at the receipt-date rate, book expenses in KES as incurred, and let the system report the exchange difference explicitly. The mistake to avoid is re-translating expenses at different rates per report — pick a policy the donor accepts and apply it consistently.
What if a donor requires a separate bank account per grant?
Comply — but a separate account alone does not give line-level tracking. You still need every payment out of that account tagged to a budget line, or you will have clean banking and unreconcilable reports.
