Nonprofit accounting software: fund accounting is the whole difference

Most advice about nonprofit accounting software is a list of products with donation features attached. That framing misses what actually makes this category different, and it is the reason so many organisations end up with a system their auditor is unhappy with.

Ordinary business accounting answers: how much money do we have, and did we make a profit?

A nonprofit — or a charity, which is the same problem under a different word — has to answer something harder: how much money do we have that we are actually allowed to spend on this?

Money arrives with conditions attached. A grant for a youth programme cannot pay the heating bill of the office it runs from unless the grant agreement says it can. A general donation can. A legacy might be restricted in perpetuity. Your bank balance is one number and it is composed of pots that are not interchangeable, and the accounting system either understands that or it does not.

That is fund accounting, and it is the whole difference.

Start with the floor: what every accounting tool has

We maintain a hand-counted inventory of what accounting software ships, tallied across 37 real accounting tools:

Capability	Tools	Share
Income and expense ledger	31	84%
Organisation setup and fiscal settings	30	81%
Financial reports — P&L, cash flow, aged debtors	30	81%
Invoice builder	29	78%
Customers and clients	28	76%
Payments received and allocation	28	76%
Document numbering and PDF templates	27	73%
Bank and cash accounts	26	70%
Dashboard that drills to source records	25	68%

Those 37 are general accounting tools, and that is the point. This core is the floor, it is consistent across the market, and a nonprofit gets all of it from any mainstream product. What is missing is everything below, and it is missing because in ordinary trading it does not exist.

What fund accounting actually requires

The requirements below are domain analysis rather than counted research — our inventory covers general accounting tools. But they are what separates a system your auditor accepts from one that generates a month of reconciliation every year.

Every transaction carries a fund

Not a category, not a tag on some transactions — a required dimension on all of them, in the same way an account code is required. Income arrives into a fund. Expenditure is charged to a fund. A transfer between funds is a deliberate, recorded act with a reason, not a rounding adjustment.

The test of whether a system really does this: can it produce a balance sheet per fund that adds up to the organisation's balance sheet? If the answer is "we can filter the P&L by class", it does not do fund accounting. A filter tells you what was spent; fund accounting tells you what remains available, which is the number that governs whether you can commit to something next month.

Three kinds of fund, and the middle one causes the arguments

Unrestricted. Yours to allocate. The organisation decides.
Restricted. The donor or funder attached conditions. You are legally obliged to honour them, and spending outside them is a serious matter rather than an accounting error.
Designated. Unrestricted money the board has chosen to earmark. Legally unrestricted; practically spoken for.

Designated funds are where systems fall over, because they behave like restricted funds in the management accounts and like unrestricted funds in the statutory ones. A system that has only two categories forces you to misclassify, and you will be asked about it.

Grants have their own shape

A grant is not just restricted income. It typically carries:

A reporting period that does not match your financial year.
Eligible cost rules — what may be charged, and often a cap on overhead or administration.
A claim or drawdown schedule, so income is recognised on a timetable rather than on receipt.
A reporting obligation in the funder's format, not yours.
Clawback risk if you underspend or spend outside the rules.

The practical consequence: you need spend-against-grant per grant, live, with committed spend included — not at year end, when the position is fixed and any problem is now historical.

Allocating shared costs

Your finance officer's salary, the rent, the insurance. These serve several funds and have to be apportioned by a method you can defend — headcount, floor space, direct-cost proportion — applied consistently and documented.

Doing this by hand each month is where most of the pain lives, and it is one of the strongest arguments for a system built for the sector. A tool that can hold the allocation basis and apply it automatically saves a real day every month.

Donors, receipting and the other database

Donation records are usually not the accounting system's job — they belong in a CRM or fundraising database — but the two must reconcile, and reconciling them is a recurring task nobody enjoys. Ask early which system is the source of truth for a donation, because if both think they are, you will spend a week a year on it.

Tax receipting requirements vary sharply by jurisdiction, and this is one of the few areas where a local product genuinely knows something a comparison site does not. Gift Aid, 501(c)(3) acknowledgement rules and their equivalents are not features you should expect a generic international tool to handle.

Statutory reporting

Whatever your regulator requires, in the format they require. This is the least glamorous item and the one that most often decides the purchase, because a system that cannot produce it means somebody rebuilds the accounts in a spreadsheet annually — which is exactly the outcome buying software was meant to avoid.

Budget against actual, per fund and per programme

Nonprofits budget differently: not one company budget but a set of them, one per programme or grant, each with its own period. A system that supports a single annual budget at account level cannot express this, and budget-versus-actual is the report trustees actually read.

Five people use it, and they want different things

Nonprofit finance is unusually multi-stakeholder, and most dissatisfaction with a system traces back to it being chosen for one of these people and used by all five.

The finance officer or bookkeeper is in it daily and wants speed: fast coding, bank feeds that match, allocations that run themselves. They are usually the person choosing, which is right, and they are also the person least affected by the reporting failures below.

The treasurer, who is very often a volunteer with a day job, appears quarterly and wants a position they can understand and present in twenty minutes. If getting that requires knowing which four reports to run and how to combine them, it will not happen reliably, and the board will govern on stale figures.

Programme managers want to know what is left in their budget. Not the accounts — their budget. Almost nothing in a general ledger presents this well, and when it does not, they keep their own spreadsheet, and now there are two versions of the truth and yours is the slower one.

The auditor or independent examiner appears annually, and their questions shape more of this than anyone admits: can you show the fund balances, can you evidence that restricted money was spent within its restriction, can you explain the allocation basis. A system that answers those three quickly turns a fortnight into two days.

Funders want their report in their format, on their timetable, covering a period that is not your financial year. This is the requirement that most often forces a spreadsheet back into the process.

Naming which of the five the system must serve first is worth doing explicitly, because they pull in different directions and a product that delights the bookkeeper can leave the treasurer governing blind.

The turnover problem, which is specific to this sector

One more consideration that rarely appears in a software comparison and matters more here than almost anywhere.

Nonprofits have high turnover in exactly the roles that hold financial knowledge — volunteer treasurers rotate on a term, finance officers are often part-time and frequently the only person who understands the setup, and trustees change. Whatever is not written down leaves with the person who knew it.

That has a direct bearing on the choice:

A heavily customised generic system is a liability, because the customisation is undocumented knowledge. The classes, the allocation spreadsheet, the month-end sequence — all of it lives in one head.
Conventional beats clever. A system that works the way sector-standard systems work is one a new treasurer may already know, and one a locum bookkeeper can pick up.
Ask for the month-end and year-end procedure in writing as part of any implementation, and keep it current. This is worth more than any feature on the list.
If you build, this argues strongly for documenting the fund model and the allocation rules alongside the code, and for making the rules visible in the interface rather than encoded in a script somebody has to find.

The failure mode is not dramatic. It is a treasurer resigning in March and nobody being able to produce the year-end because the person who knew the sequence has gone.

Why the class-and-tag workaround fails

Nearly every nonprofit on generic software has been advised to use classes, tags or tracking categories as funds. It is reasonable advice and it takes you further than you would expect.

It fails in four specific places:

No fund balance sheet. You get income and expenditure by class. You do not get what is left in each fund, which is the number that governs decisions.
Nothing enforces the rule. A transaction can be posted with no class, or the wrong class, and nothing objects. Over a year, a small percentage of mis-coded transactions is enough to make every fund balance approximate.
Inter-fund transfers are invisible. Moving money between funds should be an explicit, reasoned, auditable act. As a re-class it is a silent edit.
Allocations are manual. Every month, someone splits the rent across five classes by hand, and their working lives in a spreadsheet nobody else can follow.

None of those is fatal on its own. Together they mean the year-end position has to be rebuilt rather than reported, and the person who understands the rebuild becomes a single point of failure.

The four routes

Generic accounting plus disciplined tracking. Correct for a small organisation with one or two funds and no complex grants. Genuinely fine, cheap, and widely used. Set a rule that no transaction posts without a class, and review it monthly.

Generic accounting plus a fund-accounting layer. An add-on that adds fund balances and allocations on top of a mainstream ledger. Good value; interrogate the integration in both directions before committing.

Dedicated nonprofit software. Right once you have multiple restricted grants with their own reporting periods, or a regulator with a prescribed format. It costs more and it is built by people who have met your auditor's questions before, which is worth a lot.

Build it. Realistic now, with a specific catch covered below.

If you build it

A coding agent will produce a working double-entry bookkeeping application in a couple of days — we have seven, built from a single specification by three different models, each with a chart of accounts, journal entries, trial balance, balance sheet, P&L and bank reconciliation.

What the audits found is the instructive part, because none of it was a missing feature. One would not finish building for production and, once hosted, sent people to the wrong addresses — both appearing only when it left the machine it was written on. One arrived entirely empty, with no transactions at all, which makes an accounting application impossible to judge. One shipped report tabs as "coming soon" placeholders. One was deliberately narrow and said so, with no chart of accounts and no reconciliation at all.

For a nonprofit build specifically, four things must be in the specification before any code, because none will be inferred from "build me an accounting system":

Fund is a required dimension on every posting, enforced at the data layer rather than by habit. This is the equivalent of the rule that stock levels are derived rather than typed: the system has to make the wrong thing impossible, not merely discouraged.
Fund balances are derived from postings, and a per-fund balance sheet must reconcile to the organisation's. Build the reconciliation report early; it is the thing that proves the rest.
Inter-fund transfers are a distinct transaction type with a reason and an approver, never a re-class.
Allocation rules are stored and applied, with the basis recorded on each resulting posting so it can be explained a year later.

Everything else — donor records, grant claim schedules, statutory report formats — is genuine scope and genuinely optional for a first version. The four above are not, because none of them can be added afterwards without restating history.

The evaluation checklist

Produce a balance sheet for one restricted fund. Confirm the funds sum to the organisation's balance sheet.
Try to post a transaction with no fund. It should refuse.
Move £5,000 from unrestricted to a designated fund. Find the audit record and the reason.
Show spend against one grant, including committed spend, mid-year.
Allocate one month's rent across three funds. Ask whether the basis is stored or retyped.
Show budget against actual for one programme whose period is not your financial year.
Produce the statutory return your regulator requires, in their format.
Export everything, and confirm the export carries fund coding.

Check one is the whole thing. A product that cannot produce a fund balance sheet is a general ledger with labels on it, whatever the marketing says — and you will find that out at your first audit rather than at the demo.

If your question is the bookkeeping rather than the fund structure, accounting software in Excel covers the spreadsheet stage and where it ends. The equivalent gap for contractors is job costing — construction accounting software covers that one.

And if you are building, the Accounting & Invoicing planner is the specification we hand our own agents — the counted core written so an agent has to produce real double-entry books rather than an invoice screen with a total on it.