The Section 1250 Time Bomb: Tracking Rental Property Depreciation Recapture in Beancount

As a CPA who specializes in real estate investors, I see the same pattern every tax season: clients who love rental property depreciation deductions but have absolutely no idea they’re building up a Section 1250 recapture liability. When they eventually sell and I mention the 25% recapture tax, they’re shocked.

Last week, a FIRE-focused client came to me planning to sell a rental property. He was excited about his $120K gain - until I showed him the math: $75K of that “gain” was accumulated depreciation, triggering $18,750 in recapture taxes at 25%. He had zero documentation of component-level basis, making it impossible to optimize the calculation.

This got me thinking: How should we be tracking rental property depreciation in Beancount to avoid this mess?

The Section 1250 Recapture Problem Nobody Talks About

Here’s what most investors don’t understand:

When you sell rental property, the IRS taxes your depreciation deductions at 25% ordinary income rates - not the favorable 0%/15%/20% long-term capital gains rates. They call this “unrecaptured Section 1250 gain,” and it applies to ALL depreciation you claimed (or were allowed to claim).

Example calculation:

  • Original purchase: $300,000 (land $60K, building $240K)
  • Annual straight-line depreciation: $240,000 ÷ 27.5 years = $8,727/year
  • After 10 years of ownership: $87,270 accumulated depreciation
  • Recapture tax at sale: $87,270 × 25% = $21,818

If that same $87,270 was taxed as long-term capital gains at 15%: $13,091. The difference? $8,727 in extra taxes many investors don’t plan for.

The Component Tracking Requirement (That Everyone Ignores)

The tax code requires tracking depreciation by component, not just total building value. This matters because:

Different asset types = Different depreciation schedules:

  • Building structure: 27.5 years
  • HVAC, plumbing, electrical (if structural): 27.5 years
  • Appliances (fridge, stove, dishwasher): 5-year property
  • Carpeting, blinds: 5-year property
  • Land improvements (fencing, landscaping): 15-year property

With 2026’s permanent 100% bonus depreciation (thanks to the One Big Beautiful Bill Act), investors can now deduct the full cost of 5/7/15-year property in year one - but this accelerates recapture accumulation.

The component replacement problem:
When you replace an HVAC system or appliances, IRC Section 1016 requires you to:

  1. Remove the old component from your basis (even if fully depreciated)
  2. Add the new component at its cost basis
  3. Start a NEW depreciation schedule for the replacement
  4. Track BOTH for recapture calculations at sale

Most investors using QuickBooks or spreadsheets have no idea this is required. The data gets buried, making it impossible to reconstruct at sale time.

The Professional Record-Keeping Gap I See Constantly

Client scenarios I encounter every year:

:cross_mark: The spreadsheet tracker: Formulas broke 3 years ago, nobody noticed, depreciation off by $40K
:cross_mark: The QuickBooks auto-calculator: System calculates depreciation, but component detail is buried in reports
:cross_mark: The “I’ll figure it out at sale” approach: Tries to reconstruct 10 years of component changes from memory
:cross_mark: The cost segregation disaster: Paid $10K for detailed component breakdown, then didn’t maintain the records

What the IRS actually requires:

  • Transaction-level documentation for every component purchase/replacement
  • Basis tracking adjusted for depreciation allowed OR allowable (even if you forgot to claim it)
  • Component retirement calculations when assets are replaced
  • Audit trail connecting tax returns to underlying records

Why Beancount Could Solve This (And I Need Your Help Figuring Out How)

As I’ve started using Beancount for client work, I see potential advantages over traditional accounting software:

Plain text = permanent audit trail

  • Every transaction timestamped with original documentation
  • Git version control = time travel to any prior state
  • No proprietary database lock-in
  • Can’t accidentally “lose” historical data

Flexible account hierarchies for component tracking

Assets:RealEstate:123MainSt:Building
Assets:RealEstate:123MainSt:Land
Assets:RealEstate:123MainSt:HVAC_2024
Assets:RealEstate:123MainSt:Appliances_2023
Expenses:Depreciation:123MainSt:Building
Expenses:Depreciation:123MainSt:HVAC

Query language for tax reporting

  • Can aggregate depreciation by property
  • Can split by asset class (5-year vs 27.5-year)
  • Can calculate accumulated recapture liability dynamically

BUT: I need the community’s help with implementation details.

Questions for the Beancount Community

1. Account Structure for Component Tracking

  • How do you model multiple depreciation schedules for the same property?
  • Should each component be a separate account or use metadata tags?
  • How do you handle component replacements (retiring old, adding new)?

2. Depreciation Posting Automation

  • Are you doing manual monthly depreciation entries?
  • Has anyone built Python scripts that auto-generate depreciation transactions?
  • What about scheduled transaction plugins - do they work for depreciation?

3. Recapture Liability Tracking

  • Should we create a Liabilities:DeferredTax:DepreciationRecapture account?
  • Post 25% of each depreciation transaction to show phantom liability?
  • Or just calculate recapture dynamically with queries?

4. Tax Return Reconciliation

  • How do you verify Beancount accumulated depreciation matches Form 4562?
  • Do you use balance directives to assert depreciation totals?
  • What’s your year-end tax preparation workflow?

5. Cost Segregation Integration

  • For clients with cost segregation studies, how do you track the detailed component breakdowns?
  • Any automation for importing cost seg schedules into Beancount?

The Broader FIRE Investor Context

Many of my clients pursuing FIRE through real estate have:

  • Multiple rental properties (need consolidated AND per-property tracking)
  • Mix of residential (27.5 years) and short-term rentals (39 years if commercial)
  • Active component upgrades to maximize NOI
  • Complex 1031 exchange histories (carried-over basis from prior properties)

Most FIRE calculators show real estate equity as:

Market value - Mortgage = Net worth

But financially accurate calculation should be:

Market value - Mortgage - Accumulated recapture liability = TRUE net worth

For a 10-property FIRE portfolio with $500K accumulated depreciation, that’s a $125K phantom tax liability that affects retirement readiness calculations.

Professional Best Practice I’m Developing

Here’s what I want to recommend to clients, but I need to build the system first:

:white_check_mark: Transaction-level tracking in Beancount for every property purchase, improvement, and component replacement
:white_check_mark: Separate accounts for each major component (building, HVAC, appliances, etc.)
:white_check_mark: Metadata tags for tax categorization: asset_class: "5_year_property"
:white_check_mark: Automated depreciation posting via Python script, reviewed monthly
:white_check_mark: Annual reconciliation with Form 4562 using balance assertions
:white_check_mark: Recapture liability dashboards showing true after-tax equity

What I need from this community: Working examples, battle-tested workflows, and lessons learned from those who’ve actually sold properties and dealt with recapture.

The IRS Compliance Angle (What Keeps Me Up at Night)

A few regulatory warnings based on my CPA experience:

:warning: You owe recapture even if you never claimed depreciation - IRS says it’s “allowed or allowable”
:warning: Cost basis must be reduced for depreciation per IRC Section 1016 - affects capital gains calculation
:warning: Component retirement is REQUIRED when you replace assets - can’t just keep adding
:warning: Bonus depreciation increases audit risk - make sure your records can withstand IRS scrutiny

The beauty of Beancount: if implemented correctly, it creates the exact audit trail the IRS wants to see.

Call for Community Collaboration

I’m committed to building a proper real estate depreciation tracking system in Beancount. If others are interested, I’d love to collaborate on:

  1. Account structure standards for rental property component tracking
  2. Python depreciation calculators that generate Beancount transactions
  3. Query templates for tax reporting and recapture analysis
  4. Documentation guide for CPAs and tax preparers using Beancount

Who’s already doing this? What am I missing? What mistakes should I avoid?

Let’s solve the Section 1250 time bomb together.


Additional Resources: