The Great Beancount Simplification: My Journey from 47 Scripts to 5

Three years ago, I started my Beancount journey with the kind of excitement only a FIRE-obsessed financial analyst could muster. The flexibility! The scriptability! The automation possibilities! Fast forward to January 2026, and I found myself staring at a directory containing 47 Python scripts, 12 different importers, 8 plugins, and a maintenance backlog that ate up my entire weekend.

I’d fallen victim to what the accounting industry is calling the “unused coats in a closet” problem – except instead of SaaS subscriptions, I’d accumulated a wardrobe of custom scripts.

The Wake-Up Call

It hit me during tax prep season. I needed a simple P&L breakdown, but I couldn’t remember which of my three reporting scripts actually worked. One was from 2023 (broken after Beancount v3 update). Another was an “improved version” I’d started but never finished. The third was cobbled together from Stack Overflow answers.

I ended up running a manual Beancount query. It took 2 minutes. I’d spent hours maintaining scripts I didn’t even use.

The Audit

I did what any data-driven person would do: I created a spreadsheet. Every tool, script, plugin, and automation in my Beancount ecosystem went into three columns:

  • Last Used: When did I actually run this?
  • Value Delivered: What problem does it solve?
  • Maintenance Cost: How often does it break?

The results were shocking:

  • Daily use: Beancount core + Fava (obviously)
  • Weekly use: 2 bank importers, 1 investment price fetcher
  • Monthly use: 1 tax report generator
  • Literally never used: 41 other scripts

I had three different CSV importers for the same bank because they’d changed formats over the years. I had experimental plugins that never quite worked. I had automation scripts solving problems I no longer had.

The Consolidation

I got ruthless. Here’s what survived:

  1. Core: Beancount + Fava (non-negotiable)
  2. Import: 2 reliable bank importers (covers 90% of accounts)
  3. Tracking: 1 investment price updater
  4. Reporting: 1 tax report generator (used annually, but tested quarterly)
  5. Utility: 1 multipurpose script for one-off data transformations

Everything else went into an archive folder (I’m not that brave) labeled “probably-dont-need.”

The results:

  • Before: 3+ hours/month maintaining scripts, debugging imports, updating plugins
  • After: 30 minutes/month, mostly just running the 5 tools that actually work

The Irony

Here’s what makes this funny: In 2026, accounting firms are consolidating from dozens of SaaS tools down to integrated platforms. The industry is finally realizing that “lots of products doing a few things” creates workflow chaos.

But Beancount users? We can fall into the opposite trap. Plain text accounting’s flexibility is both its greatest strength and its most dangerous temptation. Every problem looks scriptable. Every inefficiency looks automatable.

I’d recreated the SaaS bloat problem, just with Python scripts instead of subscription fees.

What Actually Matters

After this simplification exercise, I’ve realized:

90% of value comes from the basics: Beancount’s core functionality + Fava handles nearly everything. Manual queries are often faster than maintaining custom tools.

Quality beats quantity for importers: Two rock-solid importers that work every time beat ten half-broken scripts that need constant tweaking.

Version control reduces need for backup tools: Git already gives you history, diffs, and recovery. I’d written redundant backup scripts “just in case.”

Sometimes manual is optimal: For one-off data fixes or rare transactions, typing them manually is faster than building, testing, and maintaining automation.

The Challenge

So here’s my challenge to the community: Audit your Beancount ecosystem.

Open your scripts folder. Your plugins directory. Your importers. Ask yourself:

  • When did I last use this?
  • What problem does it actually solve?
  • Could I live without it?

I’d bet money that 80% of your tools handle 20% of your actual workflow, and the remaining 80% of your workflow uses 20% of your tools.

What does your essential stack look like? Are you accumulating unused coats, or have you found the minimalist sweet spot?

I’m genuinely curious – for those of you using Beancount professionally or for complex financial tracking, what made the cut? What’s truly essential versus nice-to-have versus “I-should-probably-delete-this”?


Currently tracking 8 years of financial data, 3 rental properties, investment accounts, and HSA with my lean 5-tool stack. Maintenance time down 83%. Stress about broken scripts: eliminated.

Fred, you’re describing a phase almost every Beancount user goes through. I’m nodding my head reading this because I lived this exact journey.

About 18 months into my Beancount experience, I counted 20+ scripts in my repository. Most were solving yesterday’s problems – edge cases I’d encountered once and then “future-proofed” with automation. The kicker? I’d moved banks twice in that period, making half those importers obsolete.

The Natural Evolution

Here’s what I’ve learned after 4+ years: the accumulation phase is actually normal. You discover Beancount’s flexibility and think “I can automate this!” for every little friction point. You experiment. You build. You accumulate.

Then reality hits: maintenance is work. Scripts break when dependencies update. Importers fail when banks change CSV formats. That clever plugin you wrote at midnight stops working after a Beancount upgrade, and you can’t remember how it worked.

The pruning phase is when you become a real Beancount user.

The 80/20 Rule in Practice

After all these years, here’s what actually powers my workflow:

  • Beancount + Fava: Obviously. This is 90% of the value right here.
  • 2 bank importers: One for my primary checking/savings, one for credit cards. These two cover 95% of my transactions.
  • Price fetcher: Yahoo Finance API script for investment prices. Runs weekly via cron.
  • Occasional Python for queries: Not really a “tool,” just opening a Python REPL and importing beancount.query when I need something custom.

That’s it. Everything else lives in a folder I affectionately call my “Museum of Failed Experiments.”

The Museum Folder

Here’s a tip that helped me: I didn’t delete the old scripts. I moved them to with a README explaining what each one did and why I stopped using it.

Psychological win: I don’t feel like I’m throwing away work. Practical win: I’ve needed something from that archive exactly twice in 4 years. Both times I realized the script was broken anyway and just solved the problem manually.

Advice for Newcomers

If you’re just starting with Beancount, learn from Fred’s (and my) journey:

Month 1-3: Go manual. Seriously. Enter transactions by hand. Learn Beancount’s syntax. Understand the data model. Get comfortable with Fava’s interface and basic commands.

Month 4-6: Add automation only when pain is real. Downloaded 15 bank statements and manually entered them? Now it’s time for an importer. Not before.

One tool at a time. Build an importer. Use it for a month. Make sure it works reliably. Then consider the next automation. Don’t build your entire dream setup in week one.

Resist the “I might need this someday” urge. The beauty of plain text accounting: if you need something later, you can build it later. Your data isn’t locked in a proprietary format. There’s no penalty for starting simple.

The Real Superpower

Here’s what makes Beancount special: it’s not that you should build custom tools for everything. It’s that you can build custom tools when you actually need them.

Most accounting software forces you into their workflow. Beancount trusts you to figure out your own workflow. That’s powerful, but it requires discipline.

Fred’s 83% reduction in maintenance time isn’t about which tools he kept. It’s about recognizing that simplicity is a feature, not a limitation.

Welcome to the pruning phase, Fred. Your future self (and your weekends) will thank you.


Current stack: Beancount, Fava, 2 importers, 1 price fetcher, and a museum folder I’ll probably never open.

As a CPA who’s been through several tax seasons with Beancount, I can tell you: your simplification journey is smart accounting practice, Fred.

Let me share the professional angle on this.

The Audit Trail Perspective

When you’re dealing with IRS audits or regulatory compliance, simplicity is your friend. Every transformation in your data pipeline needs to be defensible and documented.

I once had a client with an incredibly elaborate custom Beancount setup – data went through 8 different processing steps before landing in the final ledger. Beautiful engineering. But when the IRS sent an audit notice, we spent days just documenting what each script did and proving the transformations were accurate.

Simpler workflows = clearer audit trails = easier to defend.

The “Bus Factor” in Accounting

Here’s something every CPA thinks about but doesn’t always say out loud: What happens if you’re unavailable?

Let’s say you get sick during tax season, or you’re on vacation when a critical financial question comes up. Can your backup accountant (or spouse, or business partner) step in and understand your system?

I had a client get hospitalized right before an important audit. Nobody else could figure out his custom Beancount system. We had to postpone, which created all sorts of problems with the auditors.

The best system is one that someone else can operate in an emergency.

Fred’s consolidation isn’t just about saving time – it’s about reducing single-point-of-failure risk.

Consolidation as Governance

Here’s a 2026 angle: Everyone’s talking about AI governance – ensuring AI systems are auditable, explainable, and accountable.

The same principle applies to your accounting automation. Can you audit your own processes? If you had to explain your entire workflow to a regulator, could you do it without spending a week creating documentation?

Fred’s tool inventory exercise is actually a governance best practice. I recommend clients do this annually, just like reviewing their chart of accounts:

  1. List every tool/script/plugin
  2. Document what it does and why you need it
  3. Test that it still works
  4. Archive anything that fails this review

What Matters for Compliance

From a professional accounting standpoint, here’s what you actually need:

:white_check_mark: Core accounting engine (Beancount): Records transactions with double-entry discipline
:white_check_mark: Clear audit trail (plain text ledger + Git): Every change is documented and reversible
:white_check_mark: Reliable data import (1-2 tested importers): Transaction data from banks is accurate
:white_check_mark: Reporting capability (Fava + bean-query): You can generate required financial statements

Everything beyond that is nice-to-have, not need-to-have.

The Complexity Counterpoint

That said – and this is where I’ll gently push back – some complexity is genuinely justified.

If you’re running:

  • Multiple legal entities (LLCs, S-Corps, partnerships)
  • Rental property portfolios with property-level P&L
  • Complex investment structures with cost basis tracking
  • Multi-currency international business

…you may need specialized tools that go beyond the basics.

The key question: Is this complexity serving a legitimate business requirement, or am I over-engineering?

For personal FIRE tracking with a few rental properties? Fred’s 5-tool stack is probably perfect.

For a CPA firm managing 50 clients with diverse structures? You might need more.

My Recommendation

Here’s what I tell clients:

Aim for “Minimum Viable Complexity.” Build the simplest system that meets your actual requirements. Not your imagined future requirements. Not the coolest technical solution. The simplest system that handles your real needs.

Then – and this is critical – document why you kept each tool.

I keep a file in my Beancount repository that explains:

  • What each tool is
  • What problem it solves
  • Why I can’t eliminate it
  • Last time I verified it still works

This is useful for future-me when I inevitably ask “What does this script do again?”

It’s also useful for compliance if I ever need to explain my processes to auditors or colleagues.

Question for Fred

What was your decision process for the tools you kept? Did you have any close calls where something almost got archived but survived the cut?

And for the tax report generator you kept – have you tested it on your 2025 tax year yet? (We’re getting close to deadline season…)


My essential stack: Beancount, Fava, 3 client importers, 1 tax automation script, and a documented rationale for each one.