Can Your Beancount Automations Prove Their Own ROI? CFOs in 2026 Demand Hard Numbers—We Should Too

I have been thinking about something that hit close to home this week. A Deloitte report from early 2026 found that 97% of CFOs say their boards now expect regular readouts on AI investment and ROI—not vague “it saves time” hand-waving, but actual numbers: cost savings, productivity gains, faster closes that show up in working capital.

The era of “AI is cool, trust us” is over. As one Accounting Today piece put it, AI in 2026 must “pay for itself like any other capital investment.”

This applies to us too

Now, most of us are not running enterprise AI deployments. But if you have spent any time building Beancount automation—importers, categorization scripts, report generators, reconciliation tools—you have made the same kind of investment. Development time is real. Maintenance time is real. The question is: can you prove the return?

I decided to actually measure mine, and the results were… humbling.

My automation audit

I went through every script in my Beancount workflow and tracked:

Automation Dev Time Monthly Savings Monthly Maintenance Annual Net
Chase CSV importer 6 hrs 45 min/mo 10 min/mo (format changes) +$292
Vanguard investment importer 12 hrs 30 min/mo 30 min/mo (API breaks) -$100
Auto-categorization rules 8 hrs 60 min/mo 15 min/mo +$275
Monthly FIRE dashboard script 20 hrs 20 min/mo 45 min/mo (Fava updates) -$583
Tax lot tracking plugin 15 hrs 15 min/mo 5 min/mo -$167

(Using my consulting rate of $75/hr as the opportunity cost baseline)

Two out of five automations have negative lifetime ROI. The FIRE dashboard was by far the worst—I spent 20 hours building it, it saves me 20 minutes a month, and it breaks almost every quarter when Fava updates change something.

The meta-question: tracking automation ROI in Beancount itself

Here is what I find delicious about this problem. You can use Beancount itself to track automation ROI. I set up:

2026-01-01 open Expenses:Automation:Development
2026-01-01 open Expenses:Automation:Maintenance  
2026-01-01 open Income:Automation:TimeSavings

Every time I spend an hour building or fixing a script, I log it:

2026-03-15 * "Auto-categorization rules" "Quarterly maintenance - updated merchant patterns"
  Expenses:Automation:Maintenance    0.5 HOURS {75 USD}
  Assets:TimeBank

Every month I log the estimated savings:

2026-03-31 * "Monthly automation savings" "Chase importer saved ~45 min"
  Income:Automation:TimeSavings    -0.75 HOURS {75 USD}
  Assets:TimeBank

Then a simple BQL query gives me my automation P&L:

SELECT account, sum(convert(position, 'USD')) 
WHERE account ~ 'Automation' 
GROUP BY account

After 3 months of tracking, my automation portfolio is running at about $40/month net positive—but only because the Chase importer and auto-categorization rules are carrying the dead weight of the others.

The honest questions

  1. How many of your automations actually have positive ROI? Be honest—factor in development time, maintenance, and the hours you spent debugging when something broke at 11pm.

  2. Do you track this at all? Or do you just assume “automation = good” and never measure?

  3. Has anyone else tried the meta-approach of using Beancount to track Beancount automation costs?

  4. What is your highest-ROI automation? And your worst?

I suspect most of us are carrying at least one automation that costs more than it saves but we keep it because we enjoyed building it. Nothing wrong with that—but we should be honest about it, especially as the industry moves toward demanding proof over promises.

Fred, this is the kind of rigor I wish more people applied to their tools—and honestly, the kind of rigor I preach to clients but have not consistently applied to my own practice.

From a CPA perspective, I want to push back slightly on one thing: your opportunity cost baseline of $75/hr is actually too generous for personal automation. When you build a personal Beancount importer on a Saturday afternoon, the true opportunity cost is not your consulting rate—it is whatever else you would realistically do with that time. For most of us, that is leisure, not billable work.

But for professional automation—scripts I build for client workflows—the math gets brutal fast. Here is my honest audit:

Positive ROI:

  • Bank reconciliation importer (Chase, BofA, Wells): Built once, saved ~3 hours/month across 8 clients = 24 hrs/mo × $125/hr = $36,000/year in recovered capacity. This is my single best investment.
  • Quarterly estimated tax calculator: 2 hours to build, saves 45 min per client × 30 clients per quarter. ROI is embarrassingly good.

Negative ROI:

  • Custom Fava reports for client presentations: 40 hours of dev time. Clients liked them for about 3 months, then asked for PDFs anyway. Net loss.
  • Multi-entity consolidation script: Worked for 2 clients. Broke every time a new entity was added. Now I do it manually—faster and more reliable.

Your Beancount-tracks-Beancount approach is clever, but I would add one more dimension: track the error cost. When an automation introduces a mistake that makes it past review, the cost of finding and fixing it downstream is usually 5-10x the original time saved. I had an auto-categorization rule that was silently miscategorizing a client’s merchant for 4 months. The cleanup took 6 hours.

The real lesson from the CFO ROI movement: it is not enough to measure time saved. You have to measure quality maintained.

This thread is making me slightly uncomfortable because I have never once measured the ROI of my automations and I manage books for 20+ small business clients.

I just… assumed they were saving me time? Let me think through this live.

My biggest automation is a set of CSV importers for my clients’ bank feeds. I built them over maybe 40 hours total across the past 2 years, and I update them probably 2-3 hours per month when banks change formats or clients switch accounts. They replace what used to be 1-2 hours of manual entry per client per month.

So: 20 clients × 1.5 hrs saved/mo = 30 hrs/mo saved. Minus 2.5 hrs/mo maintenance. Net savings: 27.5 hrs/mo.

At my rate that is roughly $1,650/month in recovered time. Against 40 hours of initial development at $60/hr = $2,400 investment. Payback period: about 6 weeks. OK, that one is clearly positive.

But here is the uncomfortable one: I spent about 3 weekends building a “client dashboard” in Fava that shows each client a pretty overview of their finances. I was so proud of it. Not a single client has ever logged into Fava to look at it. They all just ask me to email them a summary. That is maybe 50 hours of development with zero return. I keep maintaining it “just in case.”

Fred, your point about keeping automations because we enjoyed building them hits hard. I think there is also a sunk cost problem—I cannot bring myself to delete the dashboard code because of all the time I put into it.

Question for the group: has anyone successfully “retired” an automation? Like, made the conscious decision to stop maintaining something and go back to manual? How did it feel?

The Beancount-tracking-Beancount idea is brilliant though. I am going to set that up this weekend. Even if the numbers are unflattering, at least I will know.

I love this thread. And I am going to be the grumpy veteran who says: most of you are measuring the wrong thing.

ROI calculated as time-saved-minus-time-spent misses the two biggest benefits of Beancount automation:

1. Error reduction has compound value

When I was doing manual entry from CSVs, I made maybe 1-2 errors per 100 transactions. Tiny rate, right? But over a year with ~3,000 transactions, that is 30-60 errors. Each one takes 5-15 minutes to find during reconciliation—if you find it at all. Some of mine hid for months and cascaded into wrong tax estimates.

My importers have an error rate of effectively zero for the data they handle (garbage in, garbage out still applies to the source data). The value of that is not “time saved on entry” but “time not spent hunting ghosts during reconciliation, times not filing amended returns, times not explaining discrepancies to yourself at 2 AM.”

I have no idea how to quantify that precisely. But it is not zero.

2. The option value of clean data

My 4-year Beancount history is clean, consistent, and queryable. When I decided to analyze my rental property performance across all years, I could run a BQL query and have the answer in 30 seconds. If I had been doing manual entry with occasional errors? That analysis would have taken days—or been impossible.

Clean, automated data collection creates option value: the ability to ask questions about your finances that you have not thought of yet. How do you put an ROI number on a question you have not asked?

That said…

Fred is right that we should be honest. My GnuCash-to-Beancount migration scripts? Never used again after the initial migration. 15 hours of work for a one-time task. My custom commodity price fetcher? Replaced by bean-price improvements 6 months after I built it. My experimental plugin for tracking frequent flyer miles as commodities? Let us not talk about that one.

I think the real framework is not pure ROI but a “build vs. buy vs. skip” decision matrix:

  • Build if: high frequency use, stable inputs, unique to your workflow
  • Buy/use existing if: someone else has solved this already (check the Beancount ecosystem first!)
  • Skip if: low frequency, unstable inputs, or you are building it because it sounds fun rather than because you need it

The fun ones are fine—just do not pretend they are investments.

These replies are exactly what I was hoping for. Let me respond to a few things:

@accountant_alice — you are absolutely right about the opportunity cost baseline. On weekends I am not choosing between building an importer and billing a client. I am choosing between building an importer and watching Netflix. The “real” ROI of my weekend projects is probably much higher than my table suggests, because the alternative was not productive anyway. But for professional use, your $125/hr baseline makes the stakes much clearer. And the error cost dimension is critical—I had not factored that in.

@bookkeeper_bob — the sunk cost trap is SO real. I have a portfolio rebalancing calculator that took 25 hours to build and I use maybe twice a year. I could do the same thing in a spreadsheet in 10 minutes. But deleting the code feels like deleting the learning. Maybe the answer is to “archive” rather than “delete”—move it out of your active workflow but keep it as a reference.

To your question about retiring automations: yes, I deliberately killed my Vanguard importer last month. They changed their CSV format for the third time in a year and I realized I only have 4 investment transactions per month. Manual entry takes 5 minutes. The importer was costing me more in maintenance anxiety than it saved in keystrokes. It felt surprisingly good. Like cleaning out a closet.

@helpful_veteran — the option value argument is the one I cannot figure out how to quantify but know is real. When I did my year-end FIRE analysis last December, I asked questions about my spending patterns that I never could have answered without 3 years of clean Beancount data. Is that worth the 200+ hours I have spent on automation over those years? Probably. But I cannot prove it with a spreadsheet.

Maybe the honest framework is:

  • Measure what you can (time saved, time spent, errors caught)
  • Acknowledge what you cannot (option value, learning, satisfaction)
  • Be honest about which category your favorite automation falls into

I am going to keep running my automation P&L in Beancount. If anyone wants the template, I will clean it up and share it as a post.