Fund Accounting for Nonprofits: Can Beancount Compete with Wave, Aplos, and QuickBooks in 2026?

General
1

As a CPA running a small practice in Chicago, I’ve spent the last few months fielding the same question from nonprofit clients: “Should we use plain text accounting, or bite the bullet and pay for commercial software?”

The timing makes sense. 2026 has brought incredible pressure on nonprofit finances—donor trust is eroding (only a third of Americans trust charities to spend wisely), budgets are tight, and the expectation for real-time financial transparency has never been higher. My clients are looking at their options, and I need to give them honest advice.

The Commercial Landscape

Let me lay out what’s available:

Aplos Fund Accounting ($159/month): This is purpose-built for nonprofits. True fund accounting from the ground up—tracks restricted, temporarily restricted, and permanently restricted funds natively. You get nonprofit-specific reports (Statement of Financial Position, Statement of Activities by Fund), grant budgeting by fund, and Form 990 support. It’s not cheap, but it’s designed for this exact use case.

QuickBooks Nonprofit ($75/month): This is general accounting software adapted for nonprofits. It uses “Classes” to simulate fund accounting, which works but feels like a workaround. You’re essentially hacking a business accounting tool to do nonprofit fund tracking. It’s cheaper than Aplos and more businesses know QuickBooks, which helps with accountant transitions.

Wave (Free): Solid free option for very small organizations—good for income/expense tracking, invoicing, basic reporting. But: no fund accounting, no grant management, no Form 990 tools. It’s free, but limited.

Where Beancount Excels

I’ve been exploring Beancount as an alternative, and there are genuinely compelling advantages:

Radical transparency: A nonprofit could publish its Beancount ledger on GitHub. Donors can literally trace their donation from income to allocation in the expense accounts. No black boxes. No vendor intermediary. Just double-entry accounting anyone can verify. In 2026’s trust-starved environment, this matters.

Git-based collaboration: Many small nonprofits rely on volunteer accountants and board treasurers who don’t want to share passwords or manage user licenses. With Beancount, you work in Git—multiple people can contribute via pull requests, every change has an audit trail, and nobody needs expensive software licenses.

Zero recurring costs: For a nonprofit with a $200K annual budget, saving $75-159/month ($900-1900/year) is meaningful. That’s money that goes to mission, not software subscriptions.

Complete audit trails: Version control means every transaction has a timestamp, author, and commit history. You can see exactly who entered what, when, and why (if they write good commit messages).

Where Commercial Platforms Win

But let’s be honest about the gaps:

Native fund accounting: Aplos was built for fund accounting. Beancount requires you to architect it yourself using metadata, account structures, and custom queries. It’s possible, but it’s work.

Donor management: Commercial platforms integrate donor databases, automated tax receipts, recurring gift workflows, and donor self-service portals. Beancount is an accounting system, not a donor management system—you’d need to pair it with something else (Bloomerang, DonorPerfect, etc.).

Form 990 generation: Commercial platforms generate Form 990 directly from your books. With Beancount, you’re building spreadsheets from query outputs and feeding them into tax software. Doable, but manual.

AI automation: 2026 brings AI-assisted transaction categorization, anomaly detection, and predictive insights. Commercial platforms are embedding this. Beancount is scriptable, but you’re writing your own automation.

Non-technical staff: If your bookkeeper isn’t comfortable with the command line, text files, and SQL-like queries, Beancount is a tough sell. Commercial platforms have GUIs that accountants without programming backgrounds can use immediately.

The Real Question

Here’s what I’m wrestling with: For a small nonprofit—let’s say $200-500K annual budget, 5-10 restricted grants, volunteer board treasurer who’s moderately technical, and a part-time bookkeeper—which path genuinely makes sense?

Beancount offers unmatched transparency and eliminates recurring costs, but requires technical comfort and custom query development. Commercial platforms deliver turnkey functionality but lock you into monthly fees and vendor ecosystems.

I’m not here to defend Beancount as the answer to everything. I genuinely want to know: Where does plain text accounting deliver equal or better value for nonprofits, and where should organizations just pay for commercial tools?

Has anyone here worked with nonprofits using Beancount for fund accounting? What worked? What was painful? Where did you hit walls that made you wish you’d just bought Aplos?

Let’s have an honest conversation—I’ve got client meetings next week where I need to give real recommendations, not theoretical idealism.

2

This hits close to home—I actually made this exact transition with a client last year.

I run a small bookkeeping practice in Austin, and one of my nonprofit clients (small arts education org, ~$250K annual budget) was struggling with QuickBooks. They’d been using the Classes workaround for fund accounting, and honestly, it was a mess. Every month I’d spend hours reconciling grant restrictions across classes, and the board treasurer (a retired software engineer) kept asking, “Can’t we just use something simpler?”

What We Did

We migrated to Beancount in Q3 2025. The driver? Budget. They were paying $75/month for QuickBooks, and when renewal came up, the board said, “That’s $900 a year we could spend on art supplies for kids.” Hard to argue with that.

Fund tracking approach: We used metadata tags for fund restrictions:

2025-08-15 * "Grant payment from City Arts Council"
  Income:Grants:CityArts  -10000 USD
    fund: "temporarily-restricted"
    grant: "arts-education-2025"
    expiration: "2026-06-30"
  Assets:Checking

Then custom queries to generate fund reports for the board. It worked. The board could see exactly which funds were restricted, what they were allocated to, and when restrictions expired.

Git collaboration: The board treasurer loved this part. He could review the ledger in GitHub, open pull requests for corrections, and see full commit history. For a volunteer position where he’s donating 3-4 hours a month, not needing software licenses or shared passwords was huge.

Transparent reporting: We built a monthly dashboard with Fava showing restricted vs unrestricted balances. The executive director could pull it up in board meetings and say, “Here’s what we can spend, here’s what’s locked to grants.”

Where It Hurt

But Alice, you asked for honesty, so here’s what sucked:

Donor receipts: We had to build a separate system for this. Every time someone donated, the office manager manually generated a receipt in Google Docs. There’s no “send automated tax receipt” button like there would be in Aplos or Bloomerang. It worked because they only have ~100 individual donors, but it’s manual.

Form 990: Come tax season, I had to export Beancount query results to a spreadsheet, massage the data, and feed it into tax software. It took me about 6 extra hours compared to when I work with nonprofits on platforms that generate 990-ready reports. We billed those hours to the client, but it’s overhead.

Technical barrier: This only worked because I’m comfortable with the command line and writing BQL queries. When I’m on vacation and they need a report, the executive director can’t generate it herself. She can read the Fava dashboard, but she can’t create new queries or modify the importer. That’s vendor lock-in of a different kind—they’re locked into having a tech-savvy bookkeeper.

Donor management gap: They still use a separate spreadsheet for donor contact info, giving history, and relationship tracking. We considered integrating Beancount with a donor CRM, but that felt like overkill for their size. So they’ve got two systems: Beancount for accounting, Google Sheets for donor management. It’s not elegant.

Bottom Line

It works if you have a tech-savvy bookkeeper. If the org needs a turnkey solution where non-technical staff can run everything independently, Beancount is probably not the right fit.

For this particular client, saving $900/year and gaining Git-based transparency was worth the trade-offs. But I wouldn’t recommend this approach for every nonprofit I work with.

If the board treasurer wasn’t technical, or if they had 500+ donors needing automated receipts, or if they needed someone other than me to generate reports on demand—I’d probably tell them to pay for Aplos and move on.

Question for you, Alice: When you’re advising clients, how do you factor in the “technical comfort” variable? Do you assess the long-term sustainability of relying on one person (the bookkeeper) having specialized Beancount knowledge?

3

Really appreciate this honest discussion, Alice and Bob. It’s easy to get evangelical about plain text accounting, but you’re both asking the right questions: where does this actually work, and where should we be realistic?

I’ve been using Beancount for 4+ years (started with personal finances, now tracking rental properties and a small side consulting business), so I’ve seen what works and what doesn’t.

Fund Accounting Is Definitely Possible

Bob nailed the approach—metadata + custom queries. I’d add that Beancount’s account hierarchy gives you another dimension for organization:

Assets:Checking:Unrestricted
Assets:Checking:Restricted:GrantA
Assets:Checking:Restricted:GrantB

Income:Donations:Unrestricted
Income:Donations:Restricted:GrantA

Combined with metadata for grant expiration dates and reporting requirements, you can build pretty sophisticated fund tracking. It’s not as turnkey as Aplos, but it’s not black magic either.

The Transparency Advantage Is Real

Alice, you mentioned donor trust erosion—this is where Beancount could genuinely differentiate a nonprofit. I’ve been following the “Open Ledger” movement (inspired by Buffer and GitLab’s public finances). Some nonprofits are starting to publish their Beancount ledgers on GitHub as a trust signal.

Imagine a donor considering a $10K gift. They can literally go to GitHub, search for their friend’s $500 donation from last year, and trace it through the ledger to see exactly how it was spent. No PDF reports that could be doctored. No black-box accounting software. Just raw, auditable double-entry bookkeeping.

For a nonprofit in 2026 trying to rebuild donor confidence, that’s powerful.

But Let’s Be Real About the Gaps

Donor management is a gap. Period. Beancount is an accounting system, not a donor CRM. Nonprofits need:

  • Donor contact databases
  • Automated tax receipts
  • Recurring gift workflows
  • Donor portal (self-service giving history, update payment methods)
  • Relationship tracking and engagement history

None of that exists in Beancount. You’d pair it with something like Bloomerang, DonorPerfect, or even a good CRM like HubSpot.

The question is: is a “best-of-breed” approach (Beancount for accounting + separate donor platform) better or worse than an all-in-one like Aplos?

In tech, we’ve gone back and forth on this forever. Sometimes integration wins. Sometimes modular wins. I honestly don’t know the right answer for nonprofits.

Where Beancount Makes Sense

From what I’ve seen and experienced, Beancount is a good fit when:

  1. The board treasurer or bookkeeper IS technical. If you’ve got a volunteer developer or someone comfortable with the command line, Beancount’s transparency and scriptability become assets. If not, it’s a liability.

  2. Budget constraints are real. $900-1900/year in software costs might sound small, but for a small nonprofit, that’s meaningful. If you can reallocate that to mission, it matters.

  3. You value transparency as a competitive advantage. If your nonprofit wants to differentiate on radical financial openness (public ledger, GitHub-based audit trails), Beancount enables that in a way commercial platforms don’t.

  4. You’re okay with “separation of concerns.” Use Beancount for accounting. Use a separate tool for donor management. Accept that integration requires some manual work.

Where You Should Just Pay for Aplos

If you need:

  • Non-technical staff to run everything independently
  • Automated donor receipts and 990 generation
  • Turnkey solution with minimal bookkeeper customization
  • Donor portal and recurring gift management built-in

…then bite the bullet and pay for Aplos. It’s $159/month, but you’re buying time, reduced complexity, and features you’d have to build yourself with Beancount.

My Take

Bob asked about vendor lock-in. Beancount has a different kind of lock-in: knowledge lock-in. If your bookkeeper leaves and you need to hire someone new, finding a bookkeeper who knows Beancount is harder than finding one who knows QuickBooks.

But with Aplos or QuickBooks, you’ve got vendor lock-in: switching platforms is painful, and you’re paying forever.

Pick your trade-off based on your nonprofit’s situation.

Alice, for your client meetings: I’d assess these variables:

  1. How technical is the board treasurer / bookkeeper?
  2. How many donors do they have? (100? 1000? 10,000?)
  3. What’s their annual budget vs software cost sensitivity?
  4. Do they value transparency enough to invest in custom setup?

If answers are: “very technical,” “under 500,” “tight budget,” and “yes on transparency”—Beancount could work.

Otherwise, Aplos or even QuickBooks might be the pragmatic choice.

4

This has been incredibly helpful—exactly the kind of real-world experience I was hoping to hear. Bob, your arts education nonprofit story is the perfect case study. Mike, your framework for assessing fit is spot-on.

Let me respond to Bob’s question about the “technical comfort” variable, because it’s maybe the most important factor in these decisions.

Assessing Technical Sustainability

When I evaluate whether a nonprofit should consider Beancount, I literally draw a 2x2 matrix:

Axis 1: Technical Capacity (board treasurer + bookkeeper combined)

  • Low: Neither person comfortable with command line or scripting
  • High: At least one person can write basic queries and manage Git

Axis 2: Organizational Stability (volunteer/staff turnover)

  • Low: High turnover, rotating board, contract bookkeepers
  • High: Stable board treasurer, long-term bookkeeper relationship

Beancount only makes sense in the High Technical Capacity + High Organizational Stability quadrant. If either axis is low, I recommend commercial platforms.

Why? Because Bob’s right—you get knowledge lock-in. If the one person who understands Beancount leaves, you’re stuck. You can’t just hire a temp bookkeeper from the local CPA network to fill in. With QuickBooks or Aplos, you can.

The “Separate Systems” Insight

Mike, you hit on something that’s been crystallizing for me: maybe the best-of-breed approach is actually healthier than all-in-one platforms.

Here’s my professional observation: When I work with nonprofits on all-in-one platforms (Aplos, Blackbaud, etc.), I often end up rebuilding financial statements for accuracy anyway. The 990 generator produces something, but it’s rarely right on the first pass. We still spend hours checking.

So if you’re going to need manual work no matter what, maybe there’s an argument for:

  • Beancount for accounting: where accuracy, audit trails, and transparency are paramount
  • Separate donor platform (Bloomerang, DonorPerfect, HubSpot): where donor relationship management, recurring gifts, and receipting live

The integration point is manual (export from donor platform, import to Beancount), but maybe that manual step is where quality control happens?

I’m not fully convinced yet, but I’m more open to this than I was before this discussion.

The Form 990 Reality Check

Let me be honest about Form 990: commercial platforms don’t actually save as much time as you think.

I prepare a lot of nonprofit tax returns. Even with Aplos or QuickBooks generating a 990, I still:

  1. Pull raw transaction reports
  2. Verify accuracy of functional expense allocation
  3. Cross-check restricted vs unrestricted fund calculations
  4. Manually adjust for any errors or reclassifications

Bob mentioned it took him 6 extra hours with Beancount. In my experience, commercial platforms save maybe 3-4 hours on 990 prep, not 20 hours. It’s a real cost, but not insurmountable.

If the nonprofit is paying their CPA $200/hour, that’s $600-800 extra for 990 prep with Beancount. Compared to saving $900-1900/year in software costs, the math might still work out.

Where I’m Landing for Client Recommendations

After this conversation, here’s my evolving framework:

Recommend Aplos when:

  • Non-technical staff need to operate independently
  • More than 500 active donors
  • High volunteer/staff turnover
  • Organization prioritizes convenience over cost

Recommend Beancount + separate donor CRM when:

  • Board treasurer or bookkeeper is technical AND stable
  • Under 500 donors (manageable in separate system)
  • Budget is genuinely tight ($900-1900/year matters)
  • Organization wants radical financial transparency (public ledger as trust signal)
  • Volunteer accountants want to collaborate without license fees

Recommend QuickBooks when:

  • Organization wants something familiar most accountants know
  • Budget can handle $75/month but not $159/month
  • They’re okay with the “Classes” workaround for fund accounting
  • They prioritize ease of hiring replacement bookkeepers

My Open Question

Has anyone here actually integrated Beancount with a donor CRM like Bloomerang or DonorPerfect? Or are nonprofits just running parallel systems (donor data in CRM, accounting in Beancount) and manually reconciling?

If there’s a clean integration pattern, that would significantly strengthen the “best-of-breed” case.

Thanks again for the honest input, everyone. I’m walking into those client meetings next week with way more clarity than I had before.