Generic FIRE Calculators vs. Beancount Reality Check: My Estimated $45K Spending Was Actually $61K

General
1

I just had one of those humbling moments where I realized I’ve been lying to myself with numbers for the past two years.

Like many of you, I’ve been obsessively tracking my path to FIRE using the Engaging Data FIRE calculator. It’s a great tool—I’d plug in my estimated annual spending ($45K), estimated investment returns (7%), and watch it tell me I could retire in 12 years. Motivating stuff.

Then last weekend, I decided to actually analyze my Beancount data from the past 3 years instead of guessing. Wrote a quick Python script to extract real numbers from my ledger.

The reality check hurt:

  • Estimated annual spending: $45,000
  • Actual average spending (36 months): $61,247
  • I was off by 36%.

That’s not a rounding error. That’s “retire at 45 vs retire at 52” level of difference.

Why Generic Calculators Have This Problem

Tools like Engaging Data, ProjectionLab, and FIREkit are sophisticated—they do Monte Carlo simulations, factor inflation, model different withdrawal strategies. But they all have the same fundamental weakness: they trust your estimates.

And humans are terrible estimators:

  • We forget irregular expenses (that $4K car repair, annual insurance lump sum, Christmas spending)
  • We underestimate lifestyle inflation (my “fixed” expenses increased 18% over 3 years)
  • We remember aspirational spending, not actual spending (I want to spend $45K, so that’s what I report)

The Beancount Advantage: Truth From Transactions

Here’s what I extracted from my actual ledger:

# Simplified version of my analysis
from beancount import loader
from beancount.query import query
import pandas as pd

entries, errors, options = loader.load_file('main.beancount')

# Get all expenses for trailing 36 months
q = """
SELECT year, month, sum(position) as total
WHERE account ~ 'Expenses' AND year >= 2023
GROUP BY year, month
"""

results = query.run_query(entries, options, q)
# Average monthly spending: $5,104
# Annual projection: $61,247

Even more eye-opening, when I calculated my actual investment returns from my Assets:Investments accounts (using bean-price historical data):

  • Estimated returns: 7% annually
  • Actual 3-year CAGR: 4.8%

Between spending 36% more than I thought AND earning 31% less than I assumed, my generic FIRE calculator was living in fantasy land.

Questions for the Community

1. Time horizons: I used 36-month average. Is that too long (includes old spending patterns) or too short (vulnerable to one-time events)? How do you handle this?

2. Irregular expenses: My Beancount data shows I spend $8K every other year on vacations, $2K annually on car maintenance, $1200 on gifts in December. Do you annualize these, or track “baseline” vs “irregular” spending separately?

3. Projection methodology: Once you have real data, do you:

  • Use simple linear projection (current savings rate = X years to FI)?
  • Build Monte Carlo on actual spending variance?
  • Factor in planned lifestyle changes (kids, house, downsizing)?

4. Integration with generic tools: Do you still use calculators like Engaging Data, but feed them real numbers from Beancount? Or have you built custom FIRE projections entirely?

My Current Approach

I now run a monthly script that:

  1. Calculates trailing 12-month and 36-month average spending from Beancount
  2. Extracts current net worth from balance sheet
  3. Computes savings rate and years-to-FI using 4% rule
  4. Outputs to simple CSV that I paste into a Google Sheet for visualization

It’s not fancy, but it’s honest. And honestly, seeing real numbers is more motivating than optimistic guesses—even when they’re worse than I hoped.

Has anyone else done this analysis? Did your actual spending match your estimates, or were you surprised like me?

Curious if there’s appetite for a community-built Fava plugin that shows FIRE metrics (net worth trend, savings rate, years to FI) calculated from actual ledger data rather than user guesses.

Sources:

2

This post is exactly why I track everything in Beancount. Welcome to the “actual data is humbling” club!

I had a similar wake-up call about 2 years ago. I was telling everyone I lived on $38K/year (felt frugal!), then I ran the numbers from my ledger and discovered I was spending $47K. The gap was almost entirely “invisible” expenses—stuff I’d genuinely forgotten when estimating:

  • Annual expenses I’d mentally amortized wrong (insurance, property tax, HOA fees)
  • Quarterly expenses that weren’t salient (vet visits, dentist, car registration)
  • Category creep (my “groceries” budget was actually groceries + restaurants + coffee shops)

My Simple Approach: BQL Queries

I don’t do anything fancy. Here’s my monthly ritual (takes ~5 minutes):

-- Trailing 12-month expenses
SELECT account, sum(position)
WHERE account ~ 'Expenses'
  AND date >= 2025-04-01
GROUP BY account
ORDER BY sum(position) DESC

I paste the results into a simple spreadsheet with one formula: Total Expenses / 12 = Monthly Burn Rate.

Then I have a second query for net worth:

-- Current balances
SELECT account, sum(position)
WHERE account ~ 'Assets|Liabilities'
GROUP BY account

From there it’s just arithmetic:

  • Net worth ÷ (Monthly burn × 12 × 25) = Progress to FI (using 4% rule)
  • (FI number - Current net worth) ÷ (Monthly savings × 12) = Years to FI

No fancy Monte Carlo, no probabilistic modeling—just: here’s what I actually spend, here’s what I actually have, here’s how long at current rate.

Time Horizons: My Take

You asked about 36-month vs shorter periods. My rule of thumb:

  • 12 months: Use this for detecting changes in spending (am I spending more this year than last?)
  • 36 months: Use this for stability (what’s my true baseline once anomalies smooth out?)
  • 60+ months: Only if your lifestyle is truly stable (no major life changes, kids, moves)

I personally use trailing 24 months as my “source of truth” because:

  • Long enough to capture annual cycles (holiday spending, tax season, summer travel)
  • Short enough to reflect current lifestyle (not averaging in pre-pandemic spending)

Irregular Expenses: The Annualization Question

I struggled with this too. Here’s what worked for me:

  1. Identify lumpy expenses (anything >$1K that happens <quarterly)

  2. Create dedicated “sinking fund” accounts in Beancount:

    • Assets:Checking:VacationFund
    • Assets:Checking:CarMaintenanceFund
    • Assets:Checking:GiftsFund

  3. Fund them monthly based on historical average:

    • Vacation: $8K every 2 years = $333/month transfer
    • Car: $2K/year = $167/month transfer
    • Gifts: $1200/year = $100/month transfer

This way, your “monthly expenses” include the sinking fund transfers (which are regular), and when the lumpy expense hits, it comes out of the designated fund. Makes spending tracking way cleaner and FIRE projections more stable.

Don’t Over-Engineer

Your current approach (monthly script, trailing averages, simple 4% calc, output to CSV) is perfect. Seriously.

I see people waste weeks building elaborate Monte Carlo simulations with probability cones and stochastic modeling… then they still have the core inputs wrong because they estimated spending instead of measuring it.

You’ve solved the hard problem (getting real data). The rest is just arithmetic.

The Fava plugin idea is great, but don’t let perfect be the enemy of good enough. Your current script sounds like it’s working!

One last thought: I find that seeing actual numbers is weirdly more motivating than optimistic projections. Yeah, it stings to learn you’re farther from FI than you thought. But at least you’re navigating with an accurate map now instead of wishful thinking.

Keep us posted on what you learn!

3

This is such a software developer problem and I love it. :joy:

“My projections are precise and sophisticated… but my inputs are completely made up.”

As someone who just started using Beancount 3 months ago (coming from 4 years of Excel hell), this is exactly the kind of project I want to build. The whole reason I switched to plain text accounting was version control for my financial data—treating my ledger like source code.

And what you’re describing is basically the natural next step: treat FIRE calculators like deployment artifacts that get built from the source of truth (your Beancount ledger), not independent systems with their own data.

Developer Brain Questions

I’m trying to understand the implementation. A few questions if you don’t mind:

1. Data extraction: You showed a BQL query, but how are you handling the Python integration? Are you:

  • Using beancount.loader to parse the file, then beancount.query.query to run SQL-like queries?
  • Or going full Pandas (reading the ledger, building DataFrames, doing analysis there)?

2. Time series analysis: For calculating things like “investment returns” and “spending trends,” are you using any specialized libraries? I’m thinking:

  • pandas for time series manipulation
  • numpy for financial calculations (CAGR, etc.)
  • matplotlib or plotly for visualization?

3. Irregular expense handling: How do you distinguish between:

  • “This was a one-time event, exclude from average” (e.g., bought a car)
  • “This is irregular but recurring, should be annualized” (e.g., annual vacation)
  • “This is baseline monthly spending” (e.g., groceries)

Do you tag transactions in Beancount, or is it just manual categorization when analyzing?

Why This Matters (Beyond FIRE)

What you’ve discovered isn’t just about retirement projections. It’s about the gulf between models and reality.

In software, we deal with this all the time:

  • Estimated velocity vs. actual velocity
  • Predicted user behavior vs. actual user behavior
  • Load testing projections vs. production performance

And the solution is always the same: measure, don’t guess.

Beancount gives us the measurement infrastructure. The question is just how to analyze it effectively.

Open Source This?

You mentioned the idea of a Fava plugin for FIRE metrics. I would 100% use this (and would probably contribute to building it if someone started the repo).

Imagine a Fava extension that shows:

  • Net worth trend (line graph over time, with projections)
  • Savings rate (monthly and rolling 12-month average)
  • Years to FI (based on 4% rule, calculated from actual spending)
  • Spending categories (treemap or pie chart of where money actually goes)
  • FI progress bar (current net worth vs. FI number)

All calculated from the actual ledger data, not user estimates.

Even a minimal version would be incredibly useful. The Beancount community seems small enough that a well-built plugin could actually get traction.

Has anyone started something like this? Or should we fork Fava and add it ourselves? :thinking:

Anyway, thanks for sharing your analysis. The 36% estimation error is sobering but also clarifying. I’m definitely going to run this on my own data (though I’ve only got 3 months of Beancount history so far—might need to backfill from spreadsheets to get meaningful averages).

4

As a CPA who’s watched clients make financial decisions based on optimistic spreadsheets for 15 years, I appreciate both the rigor of your analysis AND want to inject some professional caution here.

The Value of Actual Data

First, you’re absolutely right that real transaction data beats estimation. I can’t tell you how many times I’ve had this conversation:

Client: “I spend about $4,000 a month.”
Me: “Let’s look at your bank statements… it’s actually $6,200.”
Client: “Oh, I forgot about [insurance/property tax/kids’ activities/eating out/Amazon].”

Every. Single. Time.

So yes: Beancount gives you truth. That’s valuable. Especially for FIRE planning where a 36% estimation error literally changes your retirement date by 7+ years.

But: Projections Are Not Promises

Here’s where I need to put on my CPA hat and add some caveats:

1. Historical Performance ≠ Future Results

You mentioned your actual 3-year investment returns were 4.8% vs. estimated 7%. But that 4.8% includes:

  • 2022 (S&P 500 down ~18%)
  • 2023 (S&P 500 up ~24%)
  • 2024-2025 (your actual allocation and contributions)

Is 4.8% your “real” return? Or just what happened during those specific 3 years?

The challenge: 3 years is too short to be statistically meaningful, but 30 years includes regimes that may not repeat. There’s no perfect answer.

2. Tax Optimization Changes Everything

When I help clients with retirement planning, the sequence of withdrawals often matters more than the total amount saved:

  • Roth conversions in low-income years can save $50K+ in lifetime taxes
  • Tax-loss harvesting can reduce capital gains dramatically
  • 0% capital gains bracket planning (for couples with <$96K taxable income in 2026)
  • Strategic QLAC and RMD planning

Your Beancount data can help you model this (I actually use it for client tax projections!), but simple “4% rule” calculations miss this entirely.

3. Life Happens

Your spending data from 2023-2026 might not reflect:

  • Future healthcare costs (pre-Medicare FIRE = $15K-$30K/year for insurance)
  • Lifestyle changes (kids, elder care, moving, divorce, disability)
  • Inflation variability (groceries up 25% in 2022-2023, but housing? healthcare? education?)

I’m not saying “don’t plan.” I’m saying: build in buffers.

What I Actually Do With Clients

Here’s my framework for Beancount users pursuing FIRE:

Tier 1: Baseline Reality (Your Approach)

  • Calculate actual spending from trailing 24-36 months
  • Calculate actual investment returns (with caveats about time horizon)
  • Compute straight 4% rule projection

Tier 2: Tax-Aware Planning

  • Model Roth conversion strategies
  • Plan capital gains realization timing
  • Calculate Social Security impact on taxation
  • Optimize withdrawal sequencing (taxable → tax-deferred → tax-free)

Tier 3: Risk Management

  • Add 20% buffer to spending (for healthcare, inflation surprises, lifestyle creep)
  • Model sequence-of-returns risk (early market crashes kill FIRE plans)
  • Stress test: what if returns are 3% instead of 7% for first decade of retirement?

Tier 4: Qualitative Factors

  • Can you return to work if needed? (BaristaFIRE option)
  • Do you have geographic flexibility? (CoastFIRE in lower COL area)
  • Is your FI number based on enjoyment or survival?

My Honest Opinion

Your analysis is excellent and more people should do it. The 36% gap you found is real and matters.

But don’t over-index on precision at the expense of flexibility:

  • Spending varies year-to-year naturally (±15% is normal, not noise)
  • Markets vary decade-to-decade (2010s were incredible, 2000s were terrible)
  • Life throws curveballs (2020 pandemic, 2022 inflation spike, 2025 regional bank crisis)

The value of Beancount isn’t just accuracy—it’s adaptability. You can re-run your analysis quarterly, adjust assumptions, model scenarios, stress-test changes.

That real-time feedback loop is more valuable than any single projection number.

Bottom Line

Keep doing what you’re doing. Track actual data. Build projections from truth.

Just remember: FIRE is a probability, not a date.

Your Beancount analysis helps you understand the probability better than generic calculators ever could. But it’s still not a guarantee—and that’s okay. Financial independence is about building options and resilience, not hitting an exact number on an exact date.

(Also: if you want to do serious tax-optimized FIRE planning with your Beancount data, feel free to DM me. This is literally what I do professionally, and the Beancount → tax projection workflow is surprisingly powerful when done right.)

5

Wow, this discussion took off! Thanks everyone for the thoughtful responses. Let me address some of the questions and share what I’ve learned.

@helpful_veteran - Your Sinking Fund Approach Is Brilliant

I love the idea of creating dedicated accounts for irregular expenses and funding them monthly. I’ve been treating those as “surprises” when they hit, which artificially inflates my monthly variance.

Going to implement this immediately:

2026-04-09 * "Monthly sinking fund allocation"
  Assets:Checking                           -600.00 USD
  Assets:Checking:VacationFund               333.00 USD  ; $8K/24mo
  Assets:Checking:CarMaintenanceFund         167.00 USD  ; $2K/12mo
  Assets:Checking:GiftsFund                  100.00 USD  ; $1.2K/12mo

Then when the vacation happens, it’s just a transfer from VacationFund → actual expense. The monthly “burn rate” becomes way more stable because the lumpy expense is already accounted for via the sinking fund transfer.

This is the kind of practical workflow insight that only comes from experience. Thank you!

@newbie_accountant - Implementation Details

Happy to share the code! Here’s the actual script I’m using (simplified version):

#!/usr/bin/env python3
"""
Calculate FIRE metrics from Beancount ledger
"""
from beancount import loader
from beancount.query import query
from datetime import datetime, timedelta
import pandas as pd

# Load ledger
entries, errors, options = loader.load_file('main.beancount')

# Calculate trailing 12-month and 36-month expenses
def get_expenses(months):
    start_date = (datetime.now() - timedelta(days=months*30)).strftime('%Y-%m-%d')

    q = f"""
    SELECT sum(position) as total
    WHERE account ~ 'Expenses' AND date >= {start_date}
    """

    result = query.run_query(entries, errors, options, q)
    # Parse result and return total
    return float(str(result[1][0][0]).split()[0])

expenses_12mo = get_expenses(12)
expenses_36mo = get_expenses(36)

print(f"12-month expenses: ${expenses_12mo:,.2f}")
print(f"36-month expenses: ${expenses_36mo:,.2f}")
print(f"Annual run rate (12mo): ${expenses_12mo * 12:,.2f}")
print(f"Annual run rate (36mo): ${expenses_36mo / 3:,.2f}")

# Calculate net worth
nw_query = """
SELECT sum(position)
WHERE account ~ 'Assets|Liabilities'
"""
result = query.run_query(entries, errors, options, nw_query)
net_worth = float(str(result[1][0][0]).split()[0])

# FIRE calculations (using 4% rule)
fi_number = (expenses_36mo / 3) * 25  # Annual spending * 25
progress_pct = (net_worth / fi_number) * 100

print(f"\nNet Worth: ${net_worth:,.2f}")
print(f"FI Number: ${fi_number:,.2f}")
print(f"Progress: {progress_pct:.1f}%")

Libraries needed: Just beancount (you already have it) and pandas (optional, only if you want to do time series analysis).

For irregular expenses: I’m currently doing manual categorization (I know which expenses are one-time vs. recurring from context). But I’m planning to add metadata tags:

2025-08-15 * "Bought used car" #onetime
  Assets:Checking                    -15000.00 USD
  Assets:Car                          15000.00 USD

2025-12-20 * "Annual vacation" #irregular #annual
  Assets:Checking                     -4000.00 USD
  Expenses:Travel                      4000.00 USD

Then my query can filter: WHERE account ~ 'Expenses' AND NOT tags ~ 'onetime'

@accountant_alice - The Professional Reality Check

You’re absolutely right, and I needed to hear this. My post was too focused on “precision” and not enough on “adaptability.”

The 3-year investment return point especially resonates. I’ve been treating 4.8% CAGR as “my number,” but:

  • It includes 2022 crash (artificially low)
  • It doesn’t account for changing allocation (I shifted more conservative in 2024)
  • It’s not statistically meaningful over just 36 months

Your Tier 1/2/3/4 framework is exactly the kind of structure I need. Right now I’m doing Tier 1 (baseline reality) and thinking I’m done. But I’m completely ignoring:

  • Tax optimization (my marginal rate will drop from 24% to 12% in early retirement—huge planning opportunity)
  • Healthcare costs (I’ve budgeted $0 because I’m healthy and have employer insurance—classic planning failure)
  • Sequence-of-returns risk (if I retire in 2030 and market crashes in 2031, my plan collapses)

This is where a CPA’s perspective is invaluable. The math is the easy part; the risk management and tax strategy is the hard part.

Next Steps

Based on this discussion, here’s what I’m going to do:

  1. Implement sinking funds (per helpful_veteran’s advice) to stabilize monthly spending tracking
  2. Add metadata tags for one-time vs. irregular vs. baseline expenses
  3. Expand time horizon for investment return analysis (maybe backfill data from my old spreadsheets to get 7-10 year view)
  4. Build healthcare cost projection (research ACA subsidies, high-deductible plans, HSA strategies)
  5. Run sequence-of-returns scenarios (what if market drops 30% in first year of retirement?)

The Fava plugin idea is still appealing, but I think I need to solve my own use case first before generalizing. Once I have a robust personal workflow, then it might make sense to package it for others.

Open Source Sharing

@newbie_accountant - I’ll clean up my scripts and throw them on GitHub this week. Nothing fancy, just the working code for extracting FIRE metrics from Beancount. If others find it useful, great. If not, at least it’s documented for future me.

Thanks again everyone. This is why I love this community—rigorous analysis, practical wisdom, and professional skepticism all in one thread. :folded_hands: