QSBS Section 1202 software — a builder's guide to the stacking, holding-period, and gross-asset tests

Qualified Small Business Stock — Section 1202 of the Internal Revenue Code — is one of the most consequential provisions in the founder-tax universe. Get it right and an early employee or founder excludes up to $10 million of gain (or 10× basis, whichever is greater) from federal tax. Get it wrong and the same gain is fully taxable.

The provision is not new. What's new is the volume of software trying to model, track, and surface QSBS eligibility — driven by the rise of founder-focused wealth platforms, equity-management tools (Carta, Pulley, AngelList), tax-prep automation, and family-office software serving newly-liquid founders. We've spent enough time looking at the test data behind those tools to have an opinion: most QSBS engines are right on the easy cases and quietly wrong on the hard ones.

This guide is for the engineers and product managers building those tools. It walks through the four Section 1202 tests that drive the analysis, the structural facts your data model has to capture to evaluate them, and the specific edge cases — stacking, multi-grantor trust planning, redemption look-back rules, working-capital limits — that separate a credible QSBS engine from one that will eventually generate a large and embarrassing tax bill for somebody.

The four tests, in the order they actually matter

A QSBS engine has to answer four questions for any given share lot:

1. Was the corporation a qualified small business at issuance? (Gross-asset test, corporation status, eligible-trade-or-business test.)
2. Did the holder satisfy the five-year holding period? (With all the tacking and exception rules.)
3. Was the holder eligible to claim the exclusion? (Original-issuance rule, no disqualifying redemptions.)
4. What's the per-issuer exclusion cap, and is the holder stacking it? (Greater of $10M or 10× basis, per issuer, per taxpayer — and the trust-stacking strategies that multiply it.)

Most engines do (2) well, (3) acceptably, and (1) and (4) badly. Let's walk through each.

Test 1 — Was the corporation a qualified small business at issuance?

This is the test most engines underweight. It's also the test where the answer can change between issuances of the same company's stock.

Gross-asset test (§1202(d)). The corporation's aggregate gross assets must not have exceeded $50 million at any time before, and immediately after, the share issuance. "Aggregate gross assets" includes cash. Most importantly: this is a moment-in-time test at issuance, not a rolling test. A founder's pre-seed shares may qualify even if the company is later worth $5 billion. A late-stage employee's options exercised after a $200M Series C are simply not eligible — for those shares — even if earlier employees' shares qualify.

What your data model has to capture. A timeline of the corporation's gross assets, with timestamps, and a way to associate each share-lot issuance with the gross-asset value at that moment. "The company" is not the unit of analysis. "The share lot" is.

Eligible-trade-or-business test (§1202(e)). The corporation must be engaged in a qualified trade or business — which excludes finance, insurance, farming, mining, hospitality, and "the performance of services in the fields of health, law, engineering, architecture, accounting, actuarial science, performing arts, consulting, athletics, financial services, brokerage services, or any trade or business where the principal asset is the reputation or skill of one or more of its employees."

This is famously, deliberately ambiguous. Is a SaaS company providing tax-prep automation a "consulting" business or a software business? (Generally software, but not always.) Is a fintech with a broker-dealer subsidiary "financial services"? (Often partially.) Is a healthcare company providing software to clinicians "health"? (Usually not, but case-specific.)

What your engine should do. Surface the question rather than answer it. Tag the issuer with a qualified_trade_status field that takes values like qualified, excluded, gray_area_review_required, with a notes field for the specific facts that drove the classification. Don't pretend you can resolve a question that practitioners argue about.

Active-business requirement (§1202(c)(2)). The corporation must use at least 80% of its assets in the active conduct of one or more qualified trades or businesses. Working capital counts as active-business use only if it's reasonably expected to be used in the business within two years. A company sitting on $80M of cash and burning $5M/year may have a working-capital problem that breaks the active-business test.

This is one of the most-overlooked QSBS tests. In our Founder & QSBS Tax Planning Pack, we model this explicitly because it's exactly the kind of structural fact that destroys QSBS eligibility silently.

Test 2 — Did the holder satisfy the five-year holding period?

This one most engines get right. The standard rule: holding period begins on the date the shares are acquired and must extend at least five years before the gain is exclusion-eligible.

The complications are in the tacking rules.

• Tacking on conversion. Shares received on conversion of other QSBS-eligible securities can tack the holding period. Shares received on conversion of non-QSBS-eligible securities (most SAFEs and convertible notes, per the more conservative reading) cannot.
• Tacking on gift. A gift recipient tacks the donor's holding period. Important for trust planning.
• Tacking on death. This one's actually a non-issue — death is a stepped-up-basis event and the QSBS exclusion is moot.
• Tacking on §1045 rollover. §1045 allows a holder who's held QSBS for at least six months to roll proceeds into new QSBS within 60 days, deferring the gain and tacking the holding period to the new shares. Several QSBS engines we've reviewed don't model §1045 at all, which means they can't represent the most aggressive tax-deferral strategy in the founder universe.

Edge case engines miss. A founder who's been on the cap table since incorporation but received additional shares via a later anti-dilution adjustment has two holding-period clocks. The original shares may be five-year-eligible while the anti-dilution shares are not. Your data model has to track holding period per share lot, not per holder.

Test 3 — Was the holder eligible to claim the exclusion?

The two big rules here are the original-issuance rule and the redemption look-back rule.

Original issuance (§1202(c)(1)(B)). The shares must have been acquired by the taxpayer at original issuance — directly from the corporation, in exchange for money, property (other than stock), or as compensation for services. Shares purchased on a secondary market are not QSBS-eligible to the secondary-market buyer. Shares received via gift or inheritance from someone who held QSBS do tack and qualify, with their own rules.

Every share lot needs an acquisition_method field with values like original_issuance, secondary_purchase, gift_from_qualified_holder, inheritance, etc. A QSBS engine that doesn't distinguish between these is producing wrong answers for any holder who acquired shares through anything other than primary issuance.

Redemption look-back (§1202(c)(3)). Two flavors of disqualification, both temporal:

This is a real foot-gun for founder-tax engines. A founder who exercises stock options shortly before participating in a tender offer can disqualify the QSBS treatment of the newly-acquired shares without realizing it. Your engine has to track the corporation's full redemption history relative to each holder's issuance dates.

In practice, very few engines do this. The data is hard to get (it requires the corporation's redemption ledger, not just the holder's), and the rule is unintuitive. But silent disqualification is exactly the kind of failure that creates a six-figure tax surprise three years after the founder believed they had a clean QSBS exclusion.

Test 4 — The exclusion cap, and stacking

The standard cap is the greater of $10 million or 10× the holder's adjusted basis in the shares, per issuer, per taxpayer.

For a founder with $100K of basis, the cap is $10M. For a holder with $5M of basis (e.g., a late-stage exercise), the cap is $50M.

Now, the stacking strategies.

Spousal stacking. A married couple gets two caps if both spouses are holders. A founder who gifts shares to a spouse before sale doubles the household exclusion to $20M (subject to the gift's tacking and basis rules).

Non-grantor trust stacking. A founder who gifts shares to a non-grantor trust before the holding period clock matures and before sale gets an additional $10M cap — because the trust is a separate taxpayer for §1202 purposes. Stack multiple non-grantor trusts (one per family member, typically), and the per-issuer cap multiplies. We've seen pre-IPO planning that legitimately stacks $40M–$80M of exclusion across a founder, a spouse, and several non-grantor trusts.

The structural facts your engine needs. Per-share-lot ownership, with current holder, original holder, gift dates, and grantor/non-grantor classification of any trust holders. Per-taxpayer (not per-household) tracking of cumulative QSBS exclusion claimed against each issuer. The cap is per issuer, not per transaction — a founder selling shares of two different QSBS issuers gets $10M of exclusion against each.

What your data model needs to capture

If you're building a QSBS engine, the minimum viable data model is something like this:

At the issuer level. Aggregate gross assets (time-series, day precision). Active-business asset percentage (time-series). Working-capital classification. Trade-or-business classification with effective dates (companies pivot). Redemption history, every redemption, every holder, every date.

At the share-lot level. Issuer reference. Acquisition date. Acquisition method (original_issuance, secondary, gift_from_qualified, etc.). Original holder. Current holder. Adjusted basis at acquisition. Holding period start (which may not equal acquisition date due to tacking). Eligibility status with derivation log.

At the holder level. Taxpayer classification (individual, married filing jointly, non-grantor trust, grantor trust, partnership, S-corp shareholder). Cumulative QSBS exclusion claimed, per issuer, per tax year. Related-party graph for §1202(b)(3) aggregation.

At the transaction level. §1045 rollover events with source-shares and replacement-shares linkage. Gifts with donor-recipient tacking. Sales with gain calculation and exclusion application.

This is a lot. It's also the structural minimum to model QSBS correctly. Engines that try to shortcut this end up with the kind of bugs that don't surface until a CPA reviews the output and starts asking questions.

What we'd test against

A defensible QSBS engine should pass all of the following structural tests:

Test data that exercises all eight of these patterns is hard to construct from production systems — partly because most production datasets don't have enough QSBS holders to surface the rare cases, partly because the cases involve corporate-side data (gross-asset histories, redemption ledgers) that the holder's wealth platform usually doesn't have.

This is exactly the kind of corpus our Founder & QSBS Tax Planning Pack was built to provide. Sixty households with QSBS positions, every test pattern represented, complete attestation chains, full holding-period documentation, modeled stacking via non-grantor trusts, IPO and secondary-sale liquidity events. JSON, CSV, Parquet, and a methodology PDF that walks through each test pattern's derivation.

If you're building, validating, or auditing a QSBS engine, that's the corpus we'd put it through. And if there are edge cases in your engine that we haven't modeled yet, we want to hear about them — those are exactly the gaps that determine whether a QSBS calculator is right on the easy cases or right when it matters.

Related reading:

• Founder & QSBS Tax Planning Pack (Data Set)
• Equity Compensation Tax Pack (Data Set)
• Modeling QSBS §1202 — the holding-period clock and the bugs algorithms ship without it
• How to Backtest a Tax-Loss Harvesting Algorithm with Synthetic Households
• Pre-Launch Synthetic-Data Fidelity QA Checklist

This is general information for engineering teams building QSBS software, not tax advice. Section 1202 has provisions and exceptions this article does not cover. Holders making §1202 elections should consult qualified tax counsel.