Section 1031 like-kind exchanges — modeling the deferred-basis chain across multiple decades and properties

Section 1031 — the like-kind exchange — is the structural backbone of high-net-worth real-estate investing. Defer the capital gain on a sale by exchanging into like-kind property within prescribed timing windows, and the gain rolls forward as a reduction in the basis of the replacement property. Chain together exchanges over decades, and what would have been a series of taxable events becomes a single ultimate sale, often planned to coincide with death and a basis step-up that washes the deferred gain away entirely.

Real-estate planning platforms — whether they're full property-tracking products like Stessa or Rentastic, family-office systems handling commercial real estate, or wealth-tech adding real-estate alongside other asset classes — have to model 1031 properly or they can't credibly advise on the most important tax decision their real-estate-investor clients face.

This article is the working note on what the data model needs to look like, why a property-by-property flat schema fails, and what the test corpus should contain to exercise the chain logic.

What §1031 actually does (in 2025)

The Tax Cuts and Jobs Act of 2017 narrowed §1031 to real property only. Prior to TCJA, like-kind exchanges of personal property (artwork, equipment, vehicles) were also allowed; post-TCJA, only real estate qualifies, and even within real estate, certain restrictions apply.

The mechanics: a taxpayer (the exchanger) sells a relinquished property and rolls the proceeds, through a qualified intermediary (QI), into a replacement property within prescribed timing windows. If executed correctly, the realized gain on the relinquished property is not currently recognized. Instead, the basis of the replacement property is reduced by the deferred gain — a substituted basis that carries the deferred gain forward.

The timing windows are strict and unforgiving:

• 45 days from the date the relinquished property is sold to identify replacement property in writing to the QI
• 180 days from the date of sale to close on the identified replacement property

Miss either window, and the exchange fails — the gain on the relinquished property is recognized in the year of sale.

Additional structural requirements: the replacement property must be of equal or greater value (any cash boot received is taxable to the extent of gain), the debt structure must equal-or-exceed the relinquished property's debt (debt boot is taxable), and the property must be held for investment or business use (not personal residence).

Why flat schemas fail

The intuitive data model is property-centric: each property is a row with cost basis, depreciation, current value, debt structure, etc. This works for a single-property holder and breaks for any holder who has done even one 1031.

Consider a holder who:

1. Bought Property A in 1995 for $400K, depreciated to $300K over 12 years.
2. Sold A for $1.2M in 2007, exchanged into Property B at $1.5M. Deferred gain of $900K reduced B's basis from $1.5M to $600K.
3. B was depreciated to $400K, sold in 2020 for $2.5M, exchanged into Property C at $3M. Deferred gain $2.1M (from B's gain $2.1M) reduced C's basis from $3M to $900K.
4. Currently holds Property C with a "tax basis" of $900K but a current market value of $4.5M.

What's the right answer to "what is the holder's basis in Property C"? If the platform shows $900K, that's the depreciated tax basis after the cumulative deferrals. If the platform shows $3M, that's the original cost without the deferral history. Neither is wrong but they answer different questions.

A flat schema with one row per property has nowhere to put the chain. The chain is a graph where each replacement property has a pointer to the relinquished property whose deferred gain it carries.

interface Property {
  id: string;
  acquired_date: ISODate;
  acquired_method: 'purchase' | '1031_exchange' | 'gift' | 'inheritance';
  
  // For non-1031 acquisitions
  original_cost?: number;
  
  // For 1031 acquisitions — the chain link
  exchange_record?: {
    relinquished_property_id: string;
    qi_used: string;
    identification_date: ISODate;
    closing_date: ISODate;
    boot_received: number; // Cash + non-like-kind property
    debt_relief: number;
    exchange_basis_substitution: number;
  };
  
  // Computed fields, depend on the chain
  cumulative_deferred_gain: number;
  current_tax_basis: number;
  step_up_at_death_potential: number;
  
  // Depreciation per holding period
  depreciation_taken: number;
  depreciation_recapture_potential: number;
  
  // Disposition planning
  current_market_value: number;
  hypothetical_immediate_sale_tax: number; // Federal + state + NIIT + recapture
  hypothetical_immediate_1031_swap_tax: number; // Bounded by boot
}

The key field is exchange_record.relinquished_property_id — the link that lets the platform walk the chain backward to the original cost basis. Without that link, basis tracking becomes "trust me, the basis is $900K" with no audit trail.

The 45-day identification rule and the data the platform must capture

The 45-day window is one of the harshest deadlines in the tax code. The exchanger must identify, in writing to the QI, replacement property by day 45. The identification can be one of three forms:

• Three-property rule: identify up to three properties of any value
• 200% rule: identify any number of properties whose aggregate fair-market value doesn't exceed 200% of the relinquished property's value
• 95% exception: identify any number of properties at any value, provided 95% of the identified value is acquired within the 180-day window

For a platform tracking a live exchange, the data structure must capture:

• The QI's name, contact, and the trust account
• The 45-day deadline date
• The 180-day deadline date
• Each identified property with its identification status (not yet acquired, under contract, closed, abandoned)
• The identification rule used (so the platform can validate that the client stays within the chosen rule)

A common bug pattern: the client identifies four properties under the three-property rule, doesn't realize the fourth violates the rule, and the entire identification is invalidated retroactively. A platform tracking the exchange should fire a hard validation error if the rule is violated.

The boot tracking

If the replacement property is of lesser value than the relinquished property, or if the exchanger receives cash or non-like-kind property as part of the exchange, the difference is "boot" and is currently taxable to the extent of the realized gain.

The boot calculation has three components: cash boot (proceeds not reinvested), debt boot (debt relief in excess of new debt incurred), and other property boot (non-like-kind property received). Each must be tracked and summed against the realized gain to determine the currently-taxable portion.

The data model needs explicit boot fields per exchange record. A platform that omits these can't tell the holder how much current-year tax they'll owe on a partially-deferred exchange.

The depreciation-recapture overlay

Real-estate exchanges have a depreciation-recapture component. Depreciation taken on the relinquished property carries forward as a separate tax-character bucket — when the exchanger eventually sells (without exchanging), the cumulative depreciation taken is recaptured at ordinary-rate-up-to-25% (§1250 unrecaptured) plus the LTCG rate on the appreciation.

The data model must track cumulative depreciation across the chain. The replacement property's depreciation reset (it can be re-depreciated from the substituted basis) doesn't erase the relinquished property's depreciation history — it adds to it.

For a chain of three properties spanning 25 years, the cumulative depreciation can be $400K-$1M. At eventual sale (or partial sale), the recapture is the difference between today's tax bill and the bill that would have been owed if depreciation had never been taken.

The death step-up: the chain's terminus

§1014 grants a step-up in basis at the holder's death — the heir takes the property at fair market value, washing away any deferred gain. For 1031 chains, this is the strategic terminus: chain together exchanges across decades, hold the final property until death, and the heir receives a basis-stepped-up property with no deferred-gain liability.

A real-estate planning platform that models 1031 chains correctly can surface this strategy explicitly. The advice surface: "Your Property C has $3.6M of cumulative deferred gain. Selling now triggers $X of federal + state + NIIT + recapture. Holding until death and stepping up via §1014 saves $X. Estate planning trade-offs to consider:..."

For the platform to surface this, it needs the chain. Property C alone, without the chain, shows a $900K basis and a $4.5M FMV — implying $3.6M of LTCG at sale. With the chain, the platform also knows that of the $3.6M, $1.6M is depreciation recapture (higher rate), and the original $400K of basis from Property A is the terminal cost basis the heir would step up from.

What the test corpus needs

A test corpus for a 1031-modeling platform must include:

• Single-property holders (no exchange) — baseline case
• Holders mid-exchange (45-day window open) — timing pressure
• Holders mid-exchange with multiple identified properties — rule-validation case
• Holders with completed two-property chains
• Holders with longer chains (3+ properties)
• Holders with chains involving boot (partial-deferral case)
• Holders with depreciation-heavy chains (recapture surface)
• Holders contemplating death-step-up planning (terminal case)

Each of these exercises a different code path. A test corpus that includes only completed exchanges misses the live-exchange logic; one that includes only single-link chains misses the chain-traversal logic.

The synthetic-corpus value

Real-estate data is state-heavy in a way most synthetic generation misses — property values, depreciation schedules, exchange chains, depreciation-recapture overlays. The corpus that actually exercises a 1031 engine needs chain integrity at the record level: Property B's exchange_record has to link to a Property A that exists in the same corpus, with consistent basis math across the edge. A flat fixture set can't be retrofitted into that shape; the chain integrity has to be a generator invariant.

The same corpus doubles as a specification for production data capture. If the test data has the chain-record fields, the production schema needs them too — and if onboarding doesn't ask for them, the platform ships without the data its largest tax-planning advice surface depends on. The chain is either modeled end-to-end or it's "trust me" basis tracking the first time the holder asks what their step-up will be in 2032.

§1031 is the highest-leverage tax provision in the real-estate-investor toolkit, and it's structurally graph-shaped in a way most wealth-tech platforms aren't designed for. Modeling the chain correctly is the prerequisite for being a competent real-estate planning platform. Without it, the platform's advice on the most important tax decision its clients face defaults to "consult your tax advisor" — same as it was before the platform existed.