ProjectionLab vs Empower vs Beancount: The FIRE Tool Reconciliation Challenge

bookkeeper_bob · March 29, 2026, 4:29am

I’ve got a client situation that’s got me thinking about the bigger picture of FIRE tracking tools, and I’d love the community’s input.

The Client Scenario

One of my small business clients is a 32-year-old software engineer planning early retirement at 45. He came to me with financial data scattered across:

Beancount ledger (his personal preference—loves the plain text control)
ProjectionLab subscription for retirement projections and Monte Carlo simulations
Empower (Personal Capital) dashboard linked to his investment accounts
Custom spreadsheets for tax planning scenarios

Every month, he manually reconciles these systems. Every tax season, I get slightly different numbers from each source.

The Tool Gap I’m Seeing

Here’s what each tool does well:

Beancount:

Perfect historical record—every transaction accounted for
Complete audit trail (crucial for my CPA work)
Precise to the cent
No vendor lock-in, version controlled via Git
But: no built-in projection or Monte Carlo simulation features

ProjectionLab ($120/year):

Monte Carlo simulations for retirement probability
Scenario modeling (what if I retire at 43 vs 45?)
Tax-aware withdrawal strategies
But: requires manual data entry from Beancount monthly

Empower (free):

Auto-synced investment accounts
Portfolio allocation visualizations
Fee analysis across accounts
But: categorization errors, can’t fix transactions, aggressive upselling

The Reconciliation Problem

Every month, there are discrepancies:

Empower shows $847,293 net worth
Beancount calculates $847,156
ProjectionLab uses $847,000 (rounded from last month’s manual entry)

The $137-$293 difference comes from:

Pending transactions in Empower
Beancount’s precise accounting vs Empower’s estimates
Manual entry lag in ProjectionLab

For FIRE planning, these small differences compound over 10-15 year projections.

My Questions for the Community

From a bookkeeping perspective, I’m wondering:

Should Beancount be the “source of truth”? Should we build FIRE projection tools on top of Beancount data rather than maintaining parallel systems?
Has anyone built Python scripts for FIRE metrics? Things like:
- Savings rate calculation from Beancount transactions
- FI number based on actual expense history (not estimates)
- Withdrawal rate sustainability analysis using historical data
- Monte Carlo simulations pulling from Beancount account balances
What’s the practical workflow? For those of you (or your clients) pursuing FIRE:
- Do you accept the hybrid tool approach?
- How often do you reconcile across systems?
- Which tool do you trust most for decision-making?
Client communication challenge: How do you explain discrepancies to clients? “Your Beancount says X, but ProjectionLab shows Y because…”

Why This Matters

I’m seeing more FIRE-focused clients (tech workers, mostly). They want:

Precise historical tracking (Beancount delivers this)
Sophisticated projections (commercial tools deliver this)
One source of truth (nobody delivers this)

The current solution—maintaining data in 3 places—feels like a recipe for errors and confusion.

Would especially love to hear from:

CPAs/bookkeepers handling FIRE clients
Anyone who’s built custom FIRE tracking on top of Beancount
People who’ve reconciled Beancount with commercial projection tools

What’s the path forward here?

Context: Small practice in Denver, CO. 6 clients pursuing FIRE strategies, all using some mix of Beancount + commercial tools.

helpful_veteran · March 29, 2026, 4:30am

Bob, this is such a common pain point, and I think you’re asking exactly the right questions.

My Journey with This Problem

I went through this same struggle about 2 years ago. I was obsessively tracking everything in Beancount (still am!), but found myself constantly copying data into spreadsheets for “what-if” scenarios and Monte Carlo simulations.

At one point, I spent three weekends trying to build my own Monte Carlo retirement calculator in Python that would read directly from my Beancount files. It was a fascinating learning experience, but ultimately I realized: I was building ProjectionLab, poorly, for free.

The Hybrid Approach Is Reality

Here’s what I landed on, and what I recommend to your clients:

Beancount is the source of truth for what has happened.

Every transaction, perfectly reconciled
Complete audit trail for tax purposes
Asset allocation and net worth calculations I trust 100%
This is my financial system of record

Commercial tools (ProjectionLab, Empower) are for what might happen.

Scenario exploration: “What if I work 3 more years?”
Monte Carlo probability assessments
Visualizations that help with decision-making
These are analysis tools, not records

My Practical Workflow

Every month, I:

Run a Beancount query to get current net worth and asset allocation
Update ProjectionLab with these numbers (takes 5 minutes)
Run new projections based on current data
Make decisions based on Beancount actuals + ProjectionLab scenarios

I stopped using Empower because:

The auto-sync convenience wasn’t worth the categorization headaches
I didn’t trust it as a source of truth
The aggressive advisory services upselling got annoying

On Building Custom FIRE Tools

To answer your question about Python scripts for FIRE metrics—yes, I’ve built some:

Savings Rate Calculator:

bean-query main.beancount "
  SELECT
    YEAR(date) as year,
    SUM(position) as total_savings
  WHERE account ~ 'Assets:Investments'
  GROUP BY year
"

This gives me actual savings rates based on real transactions, not estimates.

Expense Tracking for FI Number:
I run queries to calculate true annual expenses (excluding one-time purchases, true recurring costs). This gives me a much more accurate FI number than guessing “$60K/year.”

But I didn’t build Monte Carlo simulations. That’s complex statistical work that ProjectionLab does better than I could in a reasonable time investment.

The Reconciliation Discrepancy Issue

For the $137-$293 differences you’re seeing:

Tell your clients:
“Beancount is our official record. The $847,156 is what you actually have. Empower’s $847,293 includes pending transactions that may not clear. ProjectionLab’s rounded $847,000 is fine for projections—that $156 difference won’t matter over a 15-year Monte Carlo simulation.”

The key is: use the right tool for the right job.

Tax planning? Beancount’s precision matters.
Retirement scenario modeling? ProjectionLab’s $847K rounding is irrelevant.

Bottom Line Advice

Don’t try to build ProjectionLab in Python unless that’s a hobby project you’ll enjoy. Use:

Beancount: Historical tracking, tax records, audit trail
ProjectionLab or similar: Future projections, Monte Carlo, scenario modeling
Manual reconciliation monthly: 5-10 minutes, totally worth it

Accept the hybrid approach. These tools serve different purposes, and that’s okay.

The $120/year for ProjectionLab is worth it if it saves your clients (and you) the time and stress of building/maintaining custom simulation tools.

Been using Beancount for 4+ years. Tracking personal finances + 2 rental properties. Gave up on building everything custom and embraced the hybrid workflow. Much happier now.

accountant_alice · March 29, 2026, 4:30am

Bob, from a CPA perspective, this hybrid tool situation creates some interesting compliance and audit trail challenges that I want to highlight.

The Audit Trail Problem

When I’m preparing tax returns or responding to IRS inquiries, I need one definitive source of truth. The discrepancies you’re describing—$847,156 vs $847,293—might seem small, but they can become problems when:

Scenario 1: Capital Gains Reporting
Client sells $50K of stock. Which cost basis are we using?

Empower’s auto-calculated basis (often wrong due to missing transaction history)
Beancount’s meticulously tracked basis with full transaction trail

Answer: Always Beancount. Empower doesn’t have the detail needed for Schedule D.

Scenario 2: Retirement Account Distributions
Client takes their first distribution at age 59½. IRS wants to see contribution history to verify Roth vs Traditional basis.

ProjectionLab: “You contributed $6,500/year for 10 years”
Beancount: Exact dates, amounts, account types, with bank statement backup

Answer: Only Beancount holds up to IRS scrutiny.

Tax Season Pain Points

Every year, I get clients who say: “But Empower shows my capital gains as $X!” And I have to explain:

Empower doesn’t have your full transaction history (it only goes back to when you linked accounts)
It doesn’t track wash sales correctly
It doesn’t handle corporate actions (splits, mergers) properly
It’s an estimate, not an audit trail

Then we spend 4-6 hours reconstructing their actual basis from brokerage statements, which they could have avoided if they’d been using Beancount from day one.

Empower’s Fee Analyzer: Caveat Emptor

Mike mentioned he stopped using Empower, and I want to second that with a specific warning about their fee analyzer.

It misses:

Trading commissions (if you’re actively rebalancing)
Bid-ask spreads on bond ETFs
Expense ratios on funds not in their database
Advisory fees charged directly from accounts (it’ll show these, but often miscategorizes them)

I had a client who thought they were paying 0.25% in fees based on Empower. Actual calculation from Beancount + manual analysis: 0.87%.

That 0.62% difference over 20 years on a $1M portfolio? Over $130K in missed projections.

My Recommendation: Beancount-First Hierarchy

For FIRE clients, I recommend this order of trust:

Tier 1: Beancount (Official Record)

All transactions recorded
Used for tax preparation
Source of truth for IRS purposes
Cost basis tracking
Contribution limit monitoring

Tier 2: Brokerage Statements (Validation)

Monthly statements from Vanguard, Fidelity, etc.
Used to reconcile Beancount balances
Official documentation for disputes

Tier 3: ProjectionLab (Planning Tool)

Populated monthly from Beancount queries
Used for scenario modeling only
Not a source of truth
Acceptable to round to nearest $1,000

Tier 4: Empower (Convenience Dashboard - Optional)

I tell clients they can use it for quick net worth glances
But NEVER for tax planning, cost basis, or official calculations
And they must be prepared to explain discrepancies during audits

Python Scripts I’ve Built for FIRE Clients

Since you asked about custom tools, here’s what I actually use:

1. IRA Contribution Tracker:
Monitors annual contribution limits (Traditional + Roth combined) and flags when clients are approaching limits. This is crucial for FIRE folks who max out accounts.

2. MAGI Calculator:
For clients doing Roth conversions as part of their FIRE strategy, this calculates Modified Adjusted Gross Income from Beancount data to predict whether conversions will push them into higher tax brackets.

3. Estimated Tax Calculator:
FIRE clients often have irregular income (side hustles, consulting). This script calculates quarterly estimated tax payments based on YTD Beancount data.

4. Tax-Loss Harvesting Opportunities:
Scans Beancount investment accounts for positions with unrealized losses that can offset gains. This is valuable for FIRE folks still in accumulation phase.

I did NOT build Monte Carlo simulations. That’s statistical modeling that ProjectionLab does better, and frankly, my professional liability insurance doesn’t cover giving retirement planning advice anyway. I stick to tax strategy.

Client Communication Script

When explaining discrepancies, I tell clients:

“Your Beancount ledger shows $847,156—this is your official financial record, and it’s what we’ll use for tax planning. ProjectionLab’s $847,000 is fine for projections because we’re modeling 15-year scenarios where a few hundred dollars don’t change the outcome. Empower’s $847,293 includes pending transactions that haven’t cleared yet. For IRS purposes, we trust Beancount.”

This frames Beancount as the authoritative source while explaining why other tools are useful for their specific purposes.

The Path Forward

Bob, I think the hybrid approach is actually the correct approach, but with clear hierarchy:

Beancount = Financial system of record (what actually happened)
Commercial projection tools = Decision support (what might happen)
Monthly reconciliation between them (making sure #2 is based on accurate data from #1)

The key is making sure clients (and their tax preparers!) understand which tool serves which purpose.

Don’t fight the hybrid workflow—embrace it with clear boundaries and hierarchy.

CPA in Chicago, 15 years experience. Use Beancount for 8 personal clients pursuing FIRE. Built custom tax scripts but stopped trying to replace commercial projection tools.

finance_fred · March 29, 2026, 4:31am

This thread is exactly what I needed to see! I’m living this workflow myself (FIRE journey, 42% to FI), and both Mike and Alice just validated—and improved—my approach.

What I’m Doing Right Now

My current setup:

Beancount: Every transaction since Jan 2024 (18 months of data)
ProjectionLab: $120/year subscription, updated monthly
Python scripts: Custom FIRE metric calculations

I was feeling guilty about paying for ProjectionLab when “I should just build it in Python,” but Mike’s comment hit home:

“I was building ProjectionLab, poorly, for free.”

That’s exactly the trap I was falling into!

The Scripts I’ve Actually Built

Since Bob asked about Python scripts for FIRE metrics, here’s what I’ve got working:

1. Savings Rate Calculator

# Query Beancount for income and essential expenses
# Calculate monthly savings rate
# Track rolling 12-month average

This gives me my actual savings rate (currently 58.3%), not an estimate. ProjectionLab uses my estimated 60% savings rate for projections, which is close enough.

2. FI Number Based on Real Expenses

# Extract last 12 months of expenses from Beancount
# Exclude one-time costs (car purchase, medical emergency)
# Calculate true recurring annual spend
# Multiply by 25 (4% rule) or 33 (3% rule) for FI number

This is way more accurate than guessing “$60K/year.” My actual spend: $47,342 last year. That’s a $313K difference in my FI number!

3. Asset Allocation Tracker

# Pull all investment account balances from Beancount
# Categorize by asset class (US stocks, international, bonds, real estate)
# Compare current allocation to target
# Flag rebalancing needs

ProjectionLab has portfolio allocation tools, but they require manual entry. With Beancount, I have actual real-time data.

4. Time to FI Calculator

This is where it gets fun:

# Current net worth from Beancount
# FI number calculated from actual expenses
# Current savings rate from last 12 months
# Assume 7% investment returns
# Calculate months to FI

Right now: 104 months to FI (8.7 years). Target retirement: 2033 at age 37.

What I Didn’t Build (And Won’t)

Monte Carlo simulations: ProjectionLab does this with:

Multiple return scenarios (bear markets, bull markets)
Variable inflation rates
Tax-aware withdrawal strategies (Roth ladder, RMDs)
Social Security integration (even though I’m planning not to count on it)

Building this myself would take weeks or months, and I’d still be less confident in the results than ProjectionLab’s tested models.

Alice’s comment about professional liability insurance is smart too—ProjectionLab takes on that risk, I don’t.

My Hybrid Workflow (Detailed)

Weekly:

Enter transactions in Beancount (Sunday evening, 15 minutes)
Run bean-check to validate

Monthly:

Run Python scripts for FIRE metrics (5 minutes)
Update ProjectionLab with current net worth and asset allocation (5 minutes)
Review Monte Carlo projections in ProjectionLab (10 minutes)
Write blog post about progress (1 hour—this is my hobby/side project)

Quarterly:

Deep dive into spending categories
Adjust FI number if spending patterns changed
Rebalance portfolio if needed

Total time investment: ~30 minutes/month for financial tracking. The blog takes more time but that’s content creation, not tracking.

Data Reconciliation: My Approach

I stopped using Empower after their 2023 rebrand became too aggressive with upselling. Now my reconciliation is:

Beancount = official record (precise to the cent)
Bank/brokerage statements = validation (reconcile monthly)
ProjectionLab = rounded to nearest $100 (good enough for 15-year projections)

Alice’s point about tax season is crucial. I’m not a CPA, but when I hired one last year, they were thrilled that I had Beancount records. Made tax prep so much easier.

Code Sharing Offer

If anyone’s interested, I’d be happy to share my Python scripts on GitHub:

Savings rate calculator
FI number from expenses
Time to FI calculator
Asset allocation tracker

They’re not polished production code (I’m a data analyst, not a software engineer), but they work with standard Beancount files.

Would there be interest in a community repo for “Beancount FIRE Scripts”?

Bottom Line: Hybrid Approach FTW

After reading Mike’s and Alice’s responses, I’m 100% confident in my approach:

Use the right tool for the right job:

Beancount: Official financial record, tax documentation, historical truth
Python: Extract FIRE metrics from Beancount data (savings rate, FI number, time to FI)
ProjectionLab: Future scenario modeling, Monte Carlo simulations, retirement planning

The $120/year for ProjectionLab is worth it. I value my time at ~$75/hour (my day job rate). If ProjectionLab saves me 2 hours/year versus building my own Monte Carlo simulator, it’s paid for itself.

And Alice’s tax/compliance perspective confirms: Beancount must be the source of truth for anything IRS-related.

Thanks for starting this thread, Bob. Really helpful to hear from others navigating the same challenges!

Finance analyst & FIRE blogger in Seattle. 18 months into tracking with Beancount. 42% to FI number. Targeting 2033 retirement at age 37. Blog: [redacted to avoid self-promotion]