If you ask nonprofit finance managers how they track grant expenses, most will say QuickBooks classes, a separate spreadsheet tracker, or some combination of both. Very few have strong opinions about which is better. The honest answer is that both approaches have real limitations, and those limitations become more painful as the number of concurrent grants grows.
We are not saying QuickBooks class tracking is bad. We are saying it solves a bookkeeping problem, not a compliance problem, and understanding that distinction matters when you are evaluating your workflow before a Single Audit or a federal program review.
What QuickBooks classes actually do
QuickBooks classes are a categorization layer in the accounting system. You assign a class to a transaction after the fact, typically when reconciling the bank feed or entering a bill. That class then lets you run class-filtered profit and loss statements, which shows you all activity assigned to a given grant within a date range.
This is useful. It gives you a grant-segregated view of your financials without requiring a separate accounting system for each funding source. For organizations with two or three grants, it works reasonably well.
The limitation is structural: classes are assigned when someone in the accounting function enters or reconciles a transaction. The person who made the purchase has usually moved on. If the card transaction was a $215 purchase at a hardware retailer, the bookkeeper entering it has to make a judgment call about which grant it belongs to, often based on incomplete information. That judgment call is unverifiable after the fact unless the original purchaser documented the business purpose and grant designation at the time of purchase.
Where manual spreadsheets come from
Most nonprofit spreadsheet trackers exist because someone decided they could not trust the QuickBooks class system to give them a real-time view of grant budgets versus actuals. They are right not to trust it. QuickBooks classes do not know your grant budget ceilings, period of performance end dates, or allowable expense categories. They are tags, not rules.
So a grants manager, typically Marcus Okafor's equivalent at any small nonprofit, builds a spreadsheet with grant name, award amount, expenses to date, and remaining balance. They update it monthly or whenever they remember to. It becomes the de facto budget tracker even though it is not connected to the accounting system.
The problem with this approach is synchronization. The spreadsheet reflects what someone updated it to show. If two transactions posted and were not entered into the spreadsheet, the remaining balance is wrong. At the end of a grant period, when a funder asks for a budget-versus-actual reconciliation, the spreadsheet number and the QuickBooks class report may diverge, and reconciling them under time pressure is genuinely stressful.
What breaks at five grants or more
One community health organization we spoke with during our early-access program had five federal and foundation grants running simultaneously. Their finance manager, a single person, was maintaining QuickBooks classes for each grant plus a master spreadsheet cross-referencing them. She spent roughly three days per month on reconciliation that the accounting system should have been handling automatically.
The specific problems she described: class misassignments from bank feed reconciliation (a transaction auto-matches to the wrong grant based on the payee name QuickBooks recognizes from a previous month); spreadsheet rows that were last updated before a program change that shifted two budget line items; and a question from the federal program officer about two transactions that appeared under the wrong class in a mid-year financial report.
None of these are unusual. They are predictable outcomes of a workflow that relies on human attention applied retrospectively to every transaction in a growing portfolio.
The timing problem is the real issue
Both QuickBooks classes and spreadsheet trackers share the same fundamental timing problem: the grant coding happens after the expense is incurred. The person with the most information about which grant a purchase should be charged to is the person at the point of purchase. By the time that information reaches the accounting system, some of it has been lost.
This is why organizations that go through federal grant audits often find transaction-level documentation gaps even when their overall accounting is clean. The QuickBooks class report may correctly show the grant allocation. The supporting documentation may be incomplete at the transaction level, because the receipt, the business purpose, and the grant designation were never captured together at the moment of purchase.
When QB classes work well, and when to supplement them
QuickBooks class tracking works well for: month-end reporting, grant budget-versus-actual views, period-end financial statements by grant, and IRS Form 990 program expense allocations. It is a legitimate and standard part of nonprofit accounting practice.
It needs supplementation when: you are managing federal awards with documentation requirements under 2 CFR Part 200; you have cardholders who make purchases across multiple grants; you need real-time balance visibility rather than month-end views; or your grant portfolio has grown to the point where a single bookkeeper cannot reasonably maintain class accuracy across all transactions.
Spreadsheet trackers can bridge the gap for small portfolios. They stop scaling around the three to four grant mark, not because spreadsheets are bad tools but because the synchronization overhead between the spreadsheet and the accounting system grows with each new award.
What card-level coding changes about this workflow
When the grant code is attached at the card level rather than assigned during month-end reconciliation, the coding decision moves to the point of purchase. The cardholder knows which grant they are buying for because the card they are using is configured for that grant. The transaction record carries the grant designation from the moment the payment is authorized.
This does not replace QuickBooks class tracking. The QuickBooks integration still matters for financial reporting and audit exports. What changes is where the coding errors originate: not during reconciliation, when context is missing, but at purchase, when context is clear. The two systems then reinforce each other rather than competing for who has the accurate grant allocation.
QuickBooks classes are a reporting tool. Card-level grant coding is a controls tool. Treating them as alternatives misses the point: they work on different layers of the compliance problem.
For organizations weighing their options, the honest recommendation is this: keep your QuickBooks classes, because you need them for financial reporting. Add a layer that captures the grant designation at the point of purchase, because that is where the compliance risk actually lives.