Multi-Scenario Budget Planning: A Pattern We Should All Consider for 2026

helpful_veteran · March 13, 2026, 5:05pm

Hey everyone! Mike here. I’ve been using Beancount for over 4 years now (came from GnuCash back in the day), and I wanted to start a discussion about something I’ve been seeing more and more in the community lately: scenario-based financial planning.

Why I’m Thinking About This Now

2026 has been… interesting, hasn’t it? Between economic uncertainty, policy changes, and general volatility in everything from job markets to healthcare costs, I’ve noticed a pattern in the questions people are asking on forums and in the Beancount community.

We’re all great at tracking what actually happened. That’s what Beancount excels at. But increasingly, I’m hearing: “How do I plan for what might happen?”

This applies across the board:

Nonprofits wondering how to model different funding scenarios
Small businesses trying to prepare for best-case growth and worst-case downturns
FIRE folks (like me) stress-testing retirement timelines under different market conditions
Freelancers modeling income volatility and tax implications

The common thread? Single-number budgets and projections don’t cut it anymore when the future is genuinely uncertain.

The Three-Scenario Framework

From what I’ve researched (and I’d love to hear from folks with professional FP&A experience), the standard approach seems to be three scenarios:

Best Case / Optimistic: Things go better than expected. What opportunities could you pursue? How would you deploy extra resources wisely?
Base Case / Realistic: Most likely outcome given current trends. This is what you communicate to stakeholders and use for day-to-day planning.
Stress Test / Adverse: Things go wrong. What’s your survival strategy? How long can you weather the storm? What’s non-negotiable?

The wisdom I’ve picked up: plan cash flow around the worst case, set stretch goals around the best case, and communicate the base case to your team/family/board.

That framework makes intuitive sense—but how do we actually implement it in Beancount?

My Beancount Scenario Planning Questions

I’ll be honest: I’ve built and abandoned three different approaches to scenario planning over the past year. Each time I either over-engineered it (too complex to maintain) or under-engineered it (too simplistic to be useful).

Here are the patterns I’ve considered. I’d love to hear what’s actually working for others:

Pattern 1: Multiple Ledger Files

Maintain separate files for each scenario:

2026-actual.beancount (what really happened)
2026-forecast-base.beancount (base case projection)
2026-forecast-stress.beancount (stress test projection)

Pros: Clean separation, easy to compare with diff tools
Cons: Maintenance burden, duplication, hard to keep scenarios in sync

Pattern 2: Single Ledger + Forecast Files

Main ledger = actuals
Separate forecast file includes future transactions with metadata tags
Use BQL queries filtered by metadata to generate scenario reports

Pros: Easier maintenance, single source of truth for actuals
Cons: Mixing actuals and projections feels messy to me

Pattern 3: Actuals in Beancount, Projections in Scripts

Use Beancount only for actual transactions (what it’s best at)
Write Python/Excel scripts that query Beancount for historical data
Build projection models outside Beancount using different assumptions

Pros: Separation of concerns, flexibility in modeling
Cons: Loses the “everything in plain text” philosophy

What pattern are you using? Or something completely different?

Specific Use Cases I’d Love to Hear About

For Nonprofit / Small Business Folks

How do you model variable revenue assumptions? (Grants that might come through at different levels, sales that could vary 30%+)
Do you track restricted vs unrestricted funds separately in scenarios?
How do you present multiple scenarios to boards/stakeholders without causing confusion?
What metrics do you monitor: runway, break-even point, reserve months?

For FIRE / Retirement Planning People

How are you modeling the “healthcare cliff” (pre-Medicare years)?
What withdrawal rate assumptions do you use across scenarios? (4% best case, 3.5% base, 3% stress?)
Do you model job loss scenarios? How?
Anyone tracking “Barista FIRE” options where you work part-time for benefits?

For Freelancers / Variable Income

How do you model income volatility when clients can disappear overnight?
Quarterly estimated tax planning under different income scenarios?
Do you build in worst-case “dry spell” periods?

What I’ve Learned From Failed Attempts

I’ll share my own lessons learned from over-complicating this:

Mistake #1: Too many scenarios
I tried building 5 scenarios (best, good, base, bad, worst). Impossible to maintain. Three is the sweet spot.

Mistake #2: Too much granularity
I modeled every expense category under different assumptions. Way too complex. Focus on the 2-3 variables that actually matter (for me: investment returns, healthcare costs, job stability).

Mistake #3: Perfect accuracy delusion
I spent weeks trying to “get the numbers right” in my stress scenario. But that’s not the point! The point is to ask: “Could I survive if X happens?” The exact number doesn’t matter as much as the qualitative preparation.

What worked: Quarterly “stress test check-ins” where I ask: “If my stress scenario triggered today, what would I do?” That simple exercise has changed my behavior more than any spreadsheet.

Broader Philosophy Question

Here’s something I’m genuinely curious about: Is scenario planning always worth the complexity?

I think there are cases where simple is better:

If you have 12 months emergency fund, maybe you don’t need stress scenarios
If you’re in early accumulation phase (not FIRE, not retiring soon), maybe base case is enough
If your income/funding is genuinely stable, maybe one projection works fine

But 2026 feels different. Stability feels like the exception, not the rule.

When do YOU think scenario planning becomes essential vs. optional?

What Would Be Helpful From This Discussion

I’d love to see:

Real examples of Beancount structures people are using (even pseudocode or simplified examples)
BQL queries that help compare scenarios or calculate key metrics (runway, reserves, etc.)
Lessons learned from approaches that failed or succeeded
Philosophical takes on when complexity is justified vs. over-engineering
Tool recommendations (plugins, scripts, visualizations) that make scenario planning more manageable

My Commitment

If this discussion generates useful patterns, I’m happy to:

Document best practices in a wiki or guide
Share any scripts I build for scenario comparison
Create example ledger structures people can adapt

I believe one of Beancount’s superpowers is transparency and auditability. Scenario planning shouldn’t undermine that—it should enhance our ability to make informed decisions about uncertain futures.

What’s working for you? What have you tried and abandoned? What questions are you wrestling with?

Looking forward to learning from this community!

—Mike

accountant_alice · March 13, 2026, 5:06pm

Mike, this is such a timely discussion! I’ve been wrestling with exactly these questions as I work with my small business clients.

Multi-Scenario Planning Saved a Client in 2025

I have to share a real story because it illustrates why this matters. One of my manufacturing clients built three budget scenarios in fall 2024:

Best case: New product line succeeds, revenue up 25%
Base case: Modest 8% growth, stable operations
Stress case: Major customer cancels contract, revenue down 35%

Guess which one happened? The stress case. Their biggest customer (40% of revenue) went bankrupt in March 2025.

But here’s the thing: because we’d already war-gamed that scenario, they knew exactly what to do. We’d already identified:

Which expenses to cut immediately (discretionary spending, contractors)
Which staff positions were “defend at all costs” (core production team)
How long they could survive on reserves (7 months at reduced burn rate)
What triggers would force deeper cuts (cash below $150K = layoffs)

Within 48 hours of losing that customer, they’d activated the stress plan. No panic. No scrambling. Just execution.

That client is still in business today because we’d thought through the worst case before it happened.

My Pattern: Separate Projection Files

To answer your question about what’s working, I use Pattern 1: Multiple Ledger Files, but with a specific workflow:

File structure:

ledger.beancount = actual transactions only (sacred, never touch projections here)
forecast-2026-base.beancount = base case projection
forecast-2026-stress.beancount = stress test projection

Key insight: I include the actual ledger at the top of each forecast file:

include "ledger.beancount"

; Base case assumptions for 2026
; Revenue: 8% growth YoY, stable customer mix
; Expenses: 4% inflation on costs

2026-04-01 * "Projected Monthly Revenue"
  Income:Sales:ProjectedBase  -45000 USD
  Assets:Receivables

2026-04-01 * "Projected Monthly Operating Expenses"
  Expenses:Salaries  22000 USD
  Expenses:Rent  4500 USD
  Expenses:Materials  8000 USD
  Assets:Checking

This way I can run Fava or queries on either file and get:

Actuals through today (from the included ledger)
Plus projections forward (from the forecast file)

Maintenance burden is real but manageable. I update scenarios quarterly, not monthly. And I only model high-level categories (revenue, major expense buckets), not every individual transaction.

Trigger-Based Decision Points

The other pattern that’s been invaluable: pre-defined triggers that activate scenario shifts.

For that manufacturing client, we documented:

Trigger 1: Revenue

If Q1 actual > base case by 15%: Unlock hiring budget for 2 production staff
If Q1 actual < base case by 20%: Freeze all hiring, activate cost reduction plan

Trigger 2: Cash Position

Cash > $250K: Operating normally, base case plan
Cash $150K-$250K: Yellow alert, reduce discretionary spend
Cash < $150K: Red alert, activate layoff plan

Trigger 3: Customer Concentration

If any customer > 40% revenue: Activate customer diversification stress scenario

This removed emotion from decision-making. We all agreed on the triggers when times were good. When stress hit, there was no debate—just execution.

BQL Query for Runway Calculation

Here’s a query I use to calculate “months of runway” under different burn rate assumptions:

SELECT 
  sum(convert(position, 'USD')) AS liquid_assets
WHERE 
  account ~ 'Assets:(Checking|Savings)'
  AND date <= today()

Then in Python or Excel:

runway_months = liquid_assets / monthly_burn_rate

For scenario planning, I calculate three runway numbers:

Best case burn: $28K/month → 9.8 months runway
Base case burn: $35K/month → 7.8 months runway
Stress case burn: $42K/month → 6.5 months runway

Seeing those numbers changes behavior. It’s not abstract anymore.

What I’m Still Figuring Out

Where I struggle:

Mid-year scenario switching: If we activate stress scenario in April, how do I cleanly “restart” projections from that point? Do I create a new file forecast-2026-stress-apr-start.beancount?
Communicating to clients: Some business owners find three scenarios overwhelming. I’ve started presenting: “Here’s what we’re planning for (base). Here’s what we’re prepared for (stress).” That framing helps.
When to update assumptions: Quarterly feels right, but if market conditions change dramatically mid-quarter, do I update sooner? How often is too often?

For CPAs and Business Advisors

If you work with clients (vs. just personal finance), scenario planning is a huge value-add. Clients will pay for:

War-gaming their risks
Building contingency plans
Having answers before questions arise

This is advisory work, not compliance work. It’s where Beancount’s transparency really shines—clients can see the assumptions, challenge them, and understand the logic.

Mike, I love your quarterly “stress test check-in” idea. I’m going to steal that for my client review meetings.

What’s the Beancount community’s experience with presenting scenarios to non-technical stakeholders? That’s the part I find hardest—making this accessible without dumbing it down.

—Alice

tax_tina · March 13, 2026, 5:07pm

This thread is gold! As a CPA who works with freelancers and small business owners, I see the consequences of not doing scenario planning all tax season long.

The Freelancer Income Volatility Problem

Mike, you asked about freelancers and variable income—that’s literally 60% of my client base now. Here’s what I’m seeing in 2026:

The pattern: Freelancers land a great contract in January, earn $15K/month for 6 months, then… crickets. Client budget cuts. Project ends. New sales cycle starts from zero.

If they budgeted based on “$15K/month forever,” they’re in trouble by October.

My Two-Scenario Approach for Freelancers

I’ve found that three scenarios is too much for most solo freelancers. They barely have time to track actuals, let alone maintain complex projections. So I simplified:

Scenario 1: “Plan for Reality” (Base Case)

Average monthly income based on last 12 months actual, not current month
This smooths out the peaks and valleys
Conservative assumption: “What I’ve actually proven I can earn consistently”

Scenario 2: “Survival Mode” (Stress Case)

What happens if income drops 50% for 3-6 months?
How long can I survive on savings?
What expenses can I cut? (Subscriptions, coworking space, contractors)
What’s my “ramen profitability” number?

I explicitly tell clients: “We don’t budget for best case. We plan for reality and prepare for stress.”

Best case becomes “extra savings” or “early debt payoff,” not lifestyle inflation.

Beancount Structure for Freelancers

Here’s the pattern I use with freelancer clients:

Main ledger = actuals only
All real transactions, categorized properly. This is the source of truth.

Separate analysis spreadsheet
(I know, not pure Beancount philosophy, but hear me out)

I query Beancount monthly for:

Last 12 months income by client
Monthly expense burn rate
Current cash reserves

Then build a simple spreadsheet:

Current Savings: $18,000
Monthly Burn Rate: $4,200

Scenario: Income drops to $0
Runway: 4.3 months

Scenario: Income drops to $2,000/mo (survival contracts)
Runway: 8.2 months

Scenario: Maintain current $6,000/mo average
Surplus: $1,800/mo

Why not keep projections in Beancount?

Because freelancers change assumptions constantly. Client signs? Update model. Contract ends? Update model. Trying to maintain that in Beancount ledger format becomes painful.

I use Beancount for what it’s best at: tracking actuals with perfect accuracy. Then use simpler tools for forward-looking “what-if” analysis.

This is basically Mike’s Pattern 3 (Actuals in Beancount, Projections in Scripts/Spreadsheets).

Quarterly Estimated Tax Nightmare

Here’s where scenario planning becomes essential for freelancers: quarterly estimated tax payments.

You’re supposed to pay 90% of your current year tax liability or 100% of prior year (whichever is lower) across four quarterly payments. But if your income is volatile, you’re basically guessing.

Stress scenario helps here:

I calculate quarterly estimates under three income assumptions:

Best case: On track for $120K year → $X quarterly payment
Base case: On track for $80K year → $Y quarterly payment
Stress case: On track for $50K year → $Z quarterly payment

Then we decide: which scenario is most likely right now? Pay that amount.

The IRS safe harbor is 100% of prior year tax. If you’re unsure, pay that and avoid penalties. But scenario modeling helps clients make informed decisions rather than panicking or underpaying.

Real Example: Client Who Avoided Disaster

One freelance developer client had three scenarios in early 2025:

Best: Three contracts running = $180K year
Base: Two contracts = $120K year
Stress: One contract + job search = $60K year

In March, two contracts ended simultaneously. Stress scenario triggered.

Because we’d already planned for it:

Emergency fund: 6 months expenses (we’d built this by saving in good months)
Immediate cuts: Cancelled $400/mo coworking space, paused contractor help
Tax adjustment: Filed Form 2210 to reduce Q2 estimated payment (annualized income method)
Activated job search: Had resume updated, LinkedIn optimized

By June he landed a full-time role. The stress scenario preparation prevented panic and allowed clear-headed decision making.

Without scenario planning, he would’ve:

Burned through savings faster (no spending cuts)
Overpaid Q2 taxes based on Q1 income (cash flow problem)
Delayed job search (hoping contracts would return)

What I’m Wrestling With

Questions I don’t have great answers for:

How often should freelancers update scenario assumptions? Monthly feels like overkill, quarterly feels too slow when income is volatile.
Healthcare costs: Freelancers on ACA exchange have income-based subsidies. If income drops (stress scenario), subsidy increases, but reconciliation is complex. How do others model this?
Client concentration risk: Many freelancers get 70%+ income from one client. How do you model “what if my biggest client disappears tomorrow”? It feels too scary to plan for, but ignoring it is dangerous.

Alice’s Trigger Approach Is Brilliant

Alice, I love your trigger-based framework. I’m going to adapt this for freelancers:

Cash Triggers:

Savings > $20K: Operating normally
Savings $10K-$20K: Reduce discretionary spending, increase sales effort
Savings < $10K: Activate survival mode (cut all non-essential)

Income Triggers:

Income stable 3 months: Maintain base case plan
Income drops 30% for 2 months: Activate stress scenario
Income drops 50% for 1 month: Emergency job search + survival cuts

Pre-committing to these removes emotion. My clients struggle with “when do I panic?” Having objective triggers helps.

For the Beancount Community

I’d love to see more discussion about:

Patterns for variable income tracking that inform scenario assumptions
Tax modeling across different income scenarios (I know this is complex)
Simple tools to present scenarios to clients who aren’t financial people

Thanks for starting this, Mike. This is the most practical discussion I’ve seen in the Beancount community in months.

—Tina

finance_fred · March 13, 2026, 5:07pm

Mike, you’re speaking my language! As a FIRE pursuer, scenario planning has completely changed how I think about financial independence.

The FIRE Number Is a Range, Not a Point

Here’s what I wish someone had told me when I started: your FIRE number isn’t one target, it’s a range across scenarios.

I used to obsess over “I need exactly $1.25M to retire.” But that assumed:

7% investment returns forever
4% withdrawal rate is safe
Healthcare costs stay flat
No major market crashes in first decade of retirement

Any ONE of those assumptions breaking invalidates the whole plan.

Now I think in ranges:

Lean FIRE (Stress Scenario): $800K

3.25% withdrawal rate = $26K/year
Extreme frugality, healthcare subsidies required
Part-time work likely needed for insurance
This is “I can survive if everything goes wrong”

FIRE (Base Scenario): $1.1M

3.5% withdrawal rate = $38.5K/year
Comfortable living, modest healthcare costs
Could work part-time by choice, not necessity
This is “I’m probably safe to retire”

Fat FIRE (Best Scenario): $1.5M+

4% withdrawal rate = $60K/year
Full healthcare coverage, travel budget, buffer for surprises
This is “I’m definitely safe and can enjoy life”

My current strategy: Work until I hit the base case number ($1.1M), but have the stress case fully planned ($800K as absolute floor).

Healthcare Cliff Modeling Is Critical

Alice and Tina both mentioned healthcare—this is THE variable that makes or breaks early retirement math.

My current situation (age 31, employer coverage):

Premium: $180/month (employer pays $620/month)
Out-of-pocket max: $3,000/year
Total annual cost: ~$5,200

Post-FIRE scenario modeling:

Best Case (ACA subsidy eligible):

Income kept below 400% FPL via Roth conversions and capital gains harvesting
Estimated premium with subsidy: $300/month
Out-of-pocket: $4,000/year
Total: $7,600/year
Difference from employed: +$2,400/year

Base Case (Partial subsidy):

Income slightly above subsidy cliff
Premium: $700/month
Out-of-pocket: $5,000/year
Total: $13,400/year
Difference from employed: +$8,200/year

Stress Case (No subsidy, high deductible):

Income too high for any subsidy OR subsidy program eliminated
Premium: $1,200/month (family coverage assumed by age 40)
Out-of-pocket: $8,000/year
Total: $22,400/year
Difference from employed: +$17,200/year

That $17K difference is almost 45% of my current annual expenses. If I don’t model it, I’ll completely underestimate my FIRE number.

My Beancount + Python Approach

I use Mike’s Pattern 3: Actuals in Beancount, Projections in Scripts.

Monthly workflow:

Track all actuals in Beancount (every dollar, every transaction)
Export annual data via BQL query
Run Python projection model with three scenario assumptions

Python script (simplified):

import beancount.query as bq

# Query actual expenses from Beancount
actual_expenses = query_expenses_last_12_months()  # Returns $42K

# Scenario assumptions
scenarios = {
    'lean_fire': {
        'annual_expenses': 26000,  # Extreme cuts
        'withdrawal_rate': 0.0325,
        'healthcare_annual': 7600,
        'returns': 0.04  # Conservative
    },
    'regular_fire': {
        'annual_expenses': 38500,
        'withdrawal_rate': 0.035,
        'healthcare_annual': 13400,
        'returns': 0.05
    },
    'fat_fire': {
        'annual_expenses': 60000,
        'withdrawal_rate': 0.04,
        'healthcare_annual': 22400,
        'returns': 0.06
    }
}

# Calculate FIRE numbers
for name, params in scenarios.items():
    total_expenses = params['annual_expenses'] + params['healthcare_annual']
    fire_number = total_expenses / params['withdrawal_rate']
    
    # Calculate years to FI
    current_nw = get_current_net_worth()  # From Beancount
    annual_savings = get_annual_savings()  # From Beancount
    years_to_fi = calculate_years(current_nw, annual_savings, 
                                   params['returns'], fire_number)
    
    print(f"{name}: ${fire_number:,.0f} ({years_to_fi:.1f} years)")

Output:

lean_fire: $802,154 (7.2 years)
regular_fire: $1,102,857 (10.8 years)  
fat_fire: $1,540,000 (14.3 years)

This tells me:

Absolute floor: $800K (I can survive)
Target: $1.1M (I’m comfortable retiring)
Stretch goal: $1.5M (I’m living well)

Barista FIRE as Middle Path

Tina mentioned this—it’s become my default stress scenario plan.

Barista FIRE = Part-time work for benefits + supplemental income

Scenario: Reach $800K invested, then:

Work 20 hrs/week at Starbucks (literally, for health insurance)
Earn $15K/year (covers healthcare + reduces portfolio withdrawals)
Withdraw only $20K/year from portfolio (2.5% rate = ultra-safe)

This dramatically reduces sequence-of-returns risk in early retirement years.

Beancount modeling:

I track “Barista FIRE” as a separate scenario where:

Investment returns can be lower (3% real) because withdrawal rate is lower
Required portfolio is smaller ($800K vs $1.1M)
But I need to model part-time income for 10-15 years

It’s not as “pure” as full retirement, but it’s way more resilient to worst-case scenarios.

What Changed My Behavior

Mike, you asked what scenario planning changes—everything.

Before stress testing:

Chasing highest returns (risky stock picks, crypto)
Minimizing savings to “enjoy life now”
FIRE target: $1.2M seemed achievable in 9 years
Anxiety level: High (what if I’m wrong?)

After stress testing:

Prioritizing stable income and recession-proof skills
Savings rate up from 45% to 57% (live on $36K, save $48K)
FIRE range: $800K minimum, $1.1M target, $1.5M ideal
Anxiety level: Lower (I have plans for bad scenarios)

The stress case motivated me. Realizing I could hit minimum FIRE in 7 years (vs “perfect” FIRE in 10+) made me work harder.

Questions for the Community

For other FIRE folks:

What healthcare assumptions are you using? Am I being too pessimistic?
Anyone modeling “job loss during accumulation phase”? (Unemployed for 6-12 months before hitting FI)
What withdrawal rates do you use across scenarios? (I’m using 4%/3.5%/3.25%)

For Beancount developers:

Is there interest in a FIRE scenario planning plugin that hooks into Beancount data?
Would others find value in a shared library of BQL queries for FI metrics? (Savings rate, runway, years to FI, withdrawal safety, etc.)

Alice and Tina, your real-world client stories are incredibly valuable. It’s easy to get lost in spreadsheets and forget these decisions affect actual lives.

Thanks for this discussion, everyone. I’m learning a ton.

—Fred

bookkeeper_bob · March 13, 2026, 5:08pm

This is one of the best threads I’ve seen here in months. Mike, Alice, Tina, Fred—thank you all for the practical wisdom.

The Small Business Perspective: Keep It Simple or You Won’t Maintain It

I work with a lot of small businesses (under 20 employees), and here’s what I’ve learned: if the system is too complex, it doesn’t get used.

I tried implementing Alice’s three-ledger-file approach with a restaurant client. Beautiful structure. Clean separation. Lasted exactly one month before they stopped updating it.

Why? Because the owner doesn’t have a finance team. They’re managing front-of-house, hiring cooks, dealing with food suppliers, and trying to grow the business. Maintaining three separate Beancount projection files? Not happening.

The Two-Scenario Reality Check

I’ve settled on Tina’s approach: two scenarios maximum for small businesses.

Scenario 1: “What We’re Planning For” (Base)

Realistic revenue projection based on last 12 months
Known expense increases (lease renewal, minimum wage hikes)
This is what we communicate to staff and use for hiring decisions

Scenario 2: “What We’re Prepared For” (Stress)

Revenue drops 30-40% (economic downturn, competition, seasonality)
What’s the minimum viable business?
Which expenses are truly fixed vs can be cut?
How many months can we survive?

I specifically frame stress case as “prepared for” not “planning for.” It’s insurance, not destiny.

The One Question That Matters

Here’s my favorite framework from a CFO I used to work with:

“If revenue dropped 30% tomorrow, what would you do?”

That single question forces scenario planning without spreadsheets. We map it out:

Immediate cuts (Week 1):

Pause all marketing spend
Cancel contractor/temp workers
Reduce owner draw to minimum
Freeze all capital purchases

30-day cuts (if revenue stays down):

Renegotiate supplier terms
Reduce operating hours
Consider staff reductions (last resort)

60-day cuts (if it’s a long-term problem):

Sublease excess space
Pivot business model (takeout-only for restaurant, for example)
Consider closure if runway < 3 months

This isn’t fancy Beancount modeling. It’s a decision tree we document and review quarterly.

Then we track actual cash reserves in Beancount to know how long we could execute that plan.

My Beancount Pattern: Actuals Only, Stress Test in Google Sheets

I use Pattern 3 exclusively for small business clients.

In Beancount:

Track every actual transaction with discipline
Monthly reconciliation of all accounts
Balance assertions to catch errors

Monthly export to Google Sheets:

Monthly P&L Summary (from Beancount):
- Revenue: $42,000
- COGS: $18,000  
- Operating Expenses: $19,000
- Net Income: $5,000

Cash Position (from Beancount):
- Checking: $32,000
- Savings: $15,000
- Total Liquid: $47,000

Stress test calculation (in spreadsheet):

If revenue drops 35%:
New monthly revenue: $27,300
Break-even burn: ~$37,000/month
Monthly shortfall: -$9,700/month
Runway: 4.8 months (before we hit zero)

Actions required if this happens:
[Decision tree documented above]

I update this quarterly, not monthly. Monthly is overkill for small business volatility.

The “Known Unknowns” Category

One pattern I use with all clients: track seasonal volatility as data, not surprise.

Many businesses have predictable slow months. For a landscaping company, winter is always slow. For retail, January is dead after holidays.

I track this in Beancount with strict date discipline, then calculate:

Average monthly revenue
Seasonal variance (best month vs worst month)
Slowest quarter cash needs

This informs the stress scenario. If you know Q1 is always 40% below average, you can plan cash reserves accordingly.

Example BQL query I use:

SELECT 
  year, 
  month,
  sum(convert(position, 'USD')) as monthly_revenue
WHERE 
  account ~ 'Income'
  AND year >= 2023
GROUP BY year, month
ORDER BY year, month

Export to spreadsheet, calculate average and variance. Now seasonal volatility is planned not panicked.

When Scenario Planning Saved a Client

I had a retail client enter 2025 with:

$28,000 cash reserves
Base case: $8,000/month revenue, $6,500/month expenses
Stress case: $5,000/month revenue (past worst month was $4,800)

In February, a new competitor opened two blocks away. Revenue dropped to $5,200.

Because we’d planned for this scenario:

Knew exactly how long they could survive (8 months at reduced revenue)
Had pre-negotiated reduced rent with landlord (triggered stress clause)
Already identified which product lines to cut
Pivoted marketing to emphasize their unique value prop

They’re still in business. Revenue recovered to $7,000/month by summer. The competitor closed (they hadn’t done scenario planning, apparently).

For the Beancount Community: We Need Simpler Tools

Fred mentioned a FIRE scenario planning plugin—I’d love to see that extended to small business.

What would help:

Simple runway calculator that queries Beancount cash + burn rate
Seasonal variance analyzer that identifies your slow months automatically
Stress test templates (pre-built “what if revenue drops X%” scenarios)
Cash flow forecasting that’s dead simple (not full-blown projections)

I know fancier tools exist (Fava extensions, Python scripts) but small business owners need “click button, get answer” simplicity.

Philosophical Take: Perfection vs Action

Mike asked about over-engineering vs under-engineering. Here’s my framework:

Over-engineering signals:

Updating projections more than quarterly
Modeling more than 2-3 key variables
Building scenario models you don’t actually review with decision-makers
Spending more time modeling than executing

Under-engineering signals:

No idea how long you can survive if revenue drops
Never reviewed worst-case scenarios
Making gut decisions during crisis instead of executing pre-planned responses

The sweet spot: Simple enough to maintain, detailed enough to inform real decisions.

For most small businesses, that’s:

Beancount for actuals (detailed, accurate)
Quarterly stress test review (simple, actionable)
Pre-documented decision tree (clear, executable)

Thank You All

Alice’s manufacturing client story, Tina’s freelancer guidance, Fred’s FIRE math—this is exactly the kind of practical discussion that helps real people make better decisions.

I’m saving this thread to share with clients. Way better than generic “you should have a budget” advice.

—Bob