VanillaPM
translation in beta
Se connecter Commencer gratuitement Dashboard

Book a grant with deferral & matching

Learn Finance · Fund & Financial Accounting · Task B3. Recognise grant income as the eligible costs it funds are incurred — not when the cash arrives.

What it is

A donor awards your organisation $300,000 for a three-year health project. The money lands in your bank account on day one. How much of it is income this year?

The instinct — "we received $300k, so it's $300k income" — is wrong, and it's the single most common mistake a new NGO finance officer makes. A grant is given for a purpose. Until you've actually delivered that purpose (incurred the eligible cost), the money isn't yours to call income — it's an obligation to spend. So you defer it as a liability and recognise it as income only as you spend on what it was given for. Income is matched to eligible expenditure.

That is the deferred-income approach of IAS 20 (Accounting for Government Grants), and it is how Finance DPro / Humentum describe restricted funds: a grant with donor conditions is restricted until those conditions are met.

Why it matters

  • Overstating income destroys your accountability. Book the full $300k as year-1 income and your accounts show a huge "surplus" you haven't earned — then years 2 and 3 look like losses. Donors and auditors read that as mismanagement.
  • It's the basis of every donor report. "How much of my grant have you used?" is answered by recognised income = eligible spend, not by how much cash you drew down.
  • Unspent restricted money is a liability, not a reserve. If the project ends with money unspent, you may owe it back. The deferred-income balance is that obligation, on the books.

Where you do it in VanillaPM

Everything below is in the organisation ledger (Finance → Accounting). A step-by-step:

  1. Set up the grant. Create a Grant record (donor · award amount · period · currency), attach a GrantBudget of the eligible cost lines, and name its FundingSource.

  2. Receive the award as a liability, not income. Cash in from the donor is booked to deferred income — you owe the donor the delivery; you haven't earned it yet. (This is the IAS 20 deferral-and-matching idea.)

  3. Spend against the grant, fully coded. Post eligible expenditure carrying the donor and grant coding block (mandatory on the grant control accounts) — so every dollar is traceable to the award that funded it.

  4. Income recognises itself by matching. As eligible spend posts, the ledger automatically moves the matched amount from deferred income to grant income — you recognise income as you deliver, never on receipt.

  5. Overspend is caught. Spend beyond the eligible budget falls to core (unrestricted) funds — it is never silently charged to the donor, which is exactly the control a donor audit looks for.

Walked example — Hilsa Health Initiative

An INGO runs a $300,000, three-year maternal-health grant from a donor. (Figures illustrative until the CR-103 running-example seed lands.)

  1. Award received. Cash arrives. It is not income yet: - Dr 1101 Bank 300,000 / Cr 2300 Deferred grant income 300,000 (→ donor, grant)
  2. Year 1 — eligible spend of $90,000 (salaries, supplies, all within the GrantBudget): - Dr 5xxx Programme expense 90,000 (→ grant) / Cr 1101 Bank 90,000 - and the ledger recognises the matched income: Dr 2300 Deferred grant income 90,000 / Cr 4xxx Grant income 90,000 (→ donor, grant)
  3. End of year 1, the books show:
Account Balance Meaning
Grant income (4xxx) 90,000 earned — matched to eligible spend
Deferred grant income (2300) 210,000 still owed to the purpose (a liability)
Programme expense (5xxx) 90,000 what was delivered

Net effect on the surplus: zero. Income $90k exactly offsets eligible cost $90k — which is the whole point. The project neither invents a surplus nor shows a loss; it shows work done, funded.

The numbers

The identity to hold in your head: recognised grant income = eligible expenditure incurred (capped at the award). The deferred balance is always award − recognised-to-date:

Deferred income = 300,000 − 90,000 = 210,000

If year-1 spend had been $95,000 but only $90,000 was within the eligible budget, the ledger recognises $90,000 of grant income and the extra $5,000 hits core funds — the donor funds only what they agreed to.

Controls & evidence

What an auditor or donor expects to see behind this: - The signed grant agreement defining the amount, period, and eligible costs / conditions. - The GrantBudget matching those eligible lines, and spend coded to the grant. - A deferred-income (2300) balance that reconciles to award − recognised income, per grant. - An audit trail on every posting (who, when) — VanillaPM's ledger is append-only with the donor/grant dimensions enforced, so a grant can always be reconstructed end to end.

Best practices & pitfalls

  • Do recognise income by spend, not by drawdown. Cash received ≠ income.
  • Do keep the donor and grant dimensions on every grant-funded line — it's what makes the donor report a query, not a spreadsheet reconstruction.
  • Pitfall: booking the whole award as income on receipt. It inflates this year and starves the next, and it hides the repayment obligation.
  • Pitfall: letting over-spend quietly draw on the grant. Eligible cost is capped at the budget; the rest is core money, and the ledger should (and does) show that.

Practise question

Q1. A donor gives $120,000 for a one-year project. By year-end you have drawn down the full $120,000 into your bank account but incurred only $80,000 of eligible expenditure. How much grant income do you recognise, and what is the deferred income balance?

Answer: Recognise $80,000 of grant income (matched to eligible spend). Deferred income = 120,000 − 80,000 = $40,000 — a liability, because that money is still owed to the project's purpose (and may be returnable). Drawing the cash down changed nothing about income.

Terms used here

  • Deferred income — grant money received (or receivable) but not yet earned; a liability until the eligible cost is incurred.
  • Restricted funds — money a donor has tied to a specific purpose; unrestricted ("core") funds are yours to allocate.
  • Matching — recognising income in the same period as the cost it funds.
  • Coding block — the dimensions (fund · donor · grant · cost-centre) carried on every posting.
  • Related: Recover indirect costs / NICRA overhead — how the donor also funds a share of your overhead, next.

How an auditor / donor expects this

They test two things: that income was recognised as spend occurred (not on receipt), and that every grant-funded cost was eligible and coded to the grant. A clean deferred-income schedule per grant — award, recognised, deferred, reconciling to the ledger — is the artefact that answers both. VanillaPM runs a management ledger (decision-useful, IAS-20-style), not an audited statutory book — so it gives you the defensible numbers and trail, and your statutory auditor signs the statutory accounts.