The Multi-Grant Dilemma: Why Adding More Dimensions Won't Fix a Broken Ledger

If you've spent any time around finance in an Australian not-for-profit, you'll know the exact moment a Chart of Accounts starts to break.

It usually starts innocently enough. The organisation has a tidy set of nominal codes to begin with. Then a multi-year Commonwealth grant turns up with its own acquittal rules. Not long after, a philanthropic gift arrives with strict conditions on how the capital can be used. Then an NDIS program rolls out, and suddenly everything needs tracking by site and by delivery stream too.

Under a traditional, segmented general ledger, the instinct is always the same: add more sub-accounts. It feels like the safe option at the time.

Give it three years and a clean two hundred line Chart of Accounts has turned into something closer to three thousand lines. Month end rolls around, and the finance team is back in Excel, sorting transactions by hand, reconciling split codes, and working out AASB 15 and AASB 1058 revenue deferrals on a spreadsheet because the ledger itself can't do it for them.

Modern cloud platforms solve this properly, through what's called dimensional accounting. But there's a trap waiting on the other side of that shift too: piling on too many dimensions instead of thinking properly about the workflow underneath them.

What dimensional accounting is actually for

In a dimensional ledger, the core Chart of Accounts holds only the natural financial code. Cash, accounts payable, salary, rent, travel. That's it.

Everything else, all the operational context, sits in independent tags instead:

• Natural Account: 5100, Travel Expense
• Dimension 1, Funder: Department of Social Services
• Dimension 2, Grant ID: Community Grant 2026
• Dimension 3, Program: Youth Services
• Dimension 4, Status: Restricted Funds

Rather than creating a brand new nominal account every time a grant starts, the general ledger stays compact, somewhere around 150 to 200 codes. When a grant wraps up, that dimension simply gets marked inactive. The core ledger stays clean, stable, and ready to report from whenever it's needed.

Where it goes wrong

Once finance leaders discover multi-dimensional systems, the temptation is almost always to track everything. Every possible data point feels worth capturing.

It's easy enough to dream up ten or twelve dimensions in an implementation workshop. It's a different matter entirely to keep data entry accurate across twelve mandatory dropdowns, every single day, for years.

Push the dimensional structure too far and a few things tend to happen. Data entry slows right down, with accounts payable staff working through endless validation prompts for what should be routine invoices. Accuracy quietly slips, because operational staff get worn down by too many dropdown choices and start picking whatever's generic, or whatever sits at the top of the list, just to get the entry through. And teams end up duplicating information that already lives properly somewhere else, building dimensions for details already captured in an NDIS CRM or a rostering system.

Structure before software

Technology on its own can't fix an accounting structure nobody's really thought through. Migrate an uncleaned legacy structure into a shiny new dimensional platform and all you've really done is automate the errors that used to be manual.

At Corellr, this is where we start with NFP, education and for-purpose leaders: designing lean, compliant financial data structures before anything gets deployed.

• Rationalise the Chart of Accounts, stripping out legacy code bloat and building a minimal natural ledger
• Define dimensions with a clear purpose, mapping exactly what's needed for AASB 15 and 1058 revenue recognition and multi-grant reporting, without loading up the operational team
• Protect data quality from the start, building ledger hygiene and privacy guardrails in before any workflow or AI reporting tool gets switched on

Where does your ledger stand?

If your finance team is spending days each month cross-tabulating grant acquittals in a spreadsheet, that's usually a sign the ledger structure is working against them, not for them.