Read the chart of accounts & coding block
Learn Finance · Fund & Financial Accounting · Task B1. Learn the map before you post a single transaction: the account codes, and the dimensions that make every dollar traceable.
What it is
The chart of accounts (CoA) is the list of "buckets" every amount can land in, each with a code and a type. The convention most ledgers follow:
| Range | Type | Examples |
|---|---|---|
| 1xxx | Assets | 1101 Bank · 1210 Grant receivable · fixed assets |
| 2xxx | Liabilities | 2300 Deferred grant income · payables · tax withheld |
| 3xxx | Funds / equity | unrestricted (core) funds · restricted funds |
| 4xxx | Income | grant income · 4300 FX gains |
| 5xxx | Expense | 5100 salaries · 5900 overhead · 5950 FX losses · 5990 overhead recovered (contra) |
But the code alone isn't enough in an NGO. "$5,000 of salaries" is useless on its own — whose salaries, for which donor's project? That's the coding block: the set of dimensions every posting carries — fund · donor · grant · cost-centre — so one expense line answers all those questions at once.
Why it matters
- The coding block is the difference between a 10-minute donor report and a 2-day one. With dimensions on every line, "show me everything charged to Grant X" is a filter, not an archaeology project.
- It enforces fund accounting. Restricted (donor) money and core money are different funds; the dimensions keep them from silently mixing.
- Get it wrong once and it compounds. A mis-coded expense is wrong in the donor report, the budget-vs-actual, and the audit — all downstream of that one dropdown.
Where you do it in VanillaPM
Everything below is in Finance → Accounting. A step-by-step:
-
Open the Account list — your CoA. Each Account carries an AccountType (asset / liability / income / expense / equity) and an AccountRole (the job it does, e.g. bank, deferred income, FX loss). A standard set is scaffolded by
seed_chart_of_accounts; you tailor it to the organisation. -
Read the coding block. A posting isn't just "which account" — it's which account plus its dimensions: fund, donor, grant, cost-centre. That coding block is what lets one ledger answer "how much has this donor's grant spent?" without a separate system.
-
Set the dimension policy. DimRule says which dimensions are required on which accounts. On the grant control accounts (deferred income, grant receivable), make donor and grant mandatory — so a grant posting can never be booked without saying whose money it is.
-
See it enforced on entry. From now on, every journal line (B2) prompts for exactly the coding block its account requires — the structure you set here is what makes every downstream report trustworthy.
Walked example — Hilsa Health Initiative
The INGO posts a $5,000 supplies cost for its maternal-health grant. The single expense line carries:
| Field | Value |
|---|---|
| Account | 5200 Programme supplies (expense) |
| Fund | Restricted |
| Donor | Nordic Health Foundation |
| Grant | HHI-2026 |
| Cost-centre | Cox's Bazar field office |
From that one coded line, four reports are already answerable: by account (supplies), by donor, by grant, and by office — no re-keying.
The numbers
The accounting equation still holds across the whole CoA: Assets = Liabilities + Funds. In an NGO the "funds" side is split into restricted and unrestricted — and that split is exactly what the fund dimension tracks. A healthy set of books can always answer: for each grant, how much is restricted-and-unspent? (that's the deferred-income balance from B3).
Controls & evidence
- A documented CoA with each account's type and role (so income can't be booked to an expense code by accident).
- A dimension policy that makes donor/grant mandatory where it matters — the control that guarantees traceability, enforced by the system, not by hope.
- Account codes mapped to the donor's budget lines, so budget-vs-actual lines up.
Best practices & pitfalls
- Do learn the five ranges cold — you'll read them all day.
- Do fill the coding block completely; a blank donor/grant on a grant-funded line is a future reconciliation you're creating for yourself.
- Pitfall: inventing new account codes mid-project. The CoA is shared infrastructure; adding codes ad-hoc fragments every comparison. Propose changes, don't freelance them.
- Pitfall: treating cost-centre as optional "nice to have" — it's how multi-office INGOs split shared costs fairly.
Practise question
Q1. You need to post the receipt of a new $200,000 restricted grant into the bank. Which two accounts move, and which dimensions are mandatory on them?
Answer: Dr 1101 Bank and Cr 2300 Deferred grant income. The donor and grant
dimensions are mandatory on the deferred-income line (2300) — it's a grant control account, so the
ledger enforces them. (Bank is an asset; the restriction lives on the liability side until spent.)
Terms used here
- Chart of accounts (CoA) — the coded list of accounts, grouped by type.
- Coding block — the dimensions (fund · donor · grant · cost-centre) on every posting.
- Account role — what an account is (e.g. deferred income, FX gain) beyond its type, so the ledger can treat it correctly.
- Restricted vs unrestricted (core) funds — donor-tied money vs money you allocate freely.
- Related: Record a balanced journal entry — how a posting is actually made, next.
How an auditor / donor expects this
They expect every grant-funded cost to be coded to the grant and eligible. The test is simple: filter the ledger by a grant and confirm the total reconciles to the donor report. A clean coding block makes that a one-click answer; a messy one makes it the reason an audit runs long.