Why convertible note cap table math results differ in New York

New York founders often discover that their carefully built convertible note cap table math doesn’t match what counsel, investors, or tools are showing—especially around closing. When the jurisdiction is New York (US‑NY), those mismatches usually trace back to a small set of recurring issues, not mysterious “New York law magic.”

This post walks through a quick diagnostic: what to check, how to isolate the difference, and how to use the DocketMath convertible note cap table calculator to see the impact of each input.

The top 5 reasons results differ

Below are the most common reasons a New York cap table model for convertible notes yields different numbers than someone else’s spreadsheet or tool.

• Different trigger dates or event definitions were used.
• Inputs were entered with different day-count or compounding assumptions.
• Payments, credits, or tolling periods were handled differently.
• Jurisdiction or court settings did not match the matter.
• Rounding or cutoff-time rules were applied inconsistently.

1. Using pre‑money vs. post‑money caps inconsistently

Some New York deal docs still use older, pre‑money style language; others adopt post‑money style economics even if the words “post‑money” never appear.

Key distinction:

If your model assumes “cap is pre‑money” but the other side’s model treats it as post‑money (or vice versa), the implied note conversion price and resulting ownership will diverge.

What to check:

• Re‑read the cap section in the note or SAFE.
• Confirm whether the cap is defined relative to pre‑ or post‑money.
• Make sure the same assumption is set in DocketMath and in any other model you’re comparing to.

2. Different treatment of accrued interest

New York notes often accrue interest at 4–8% and convert principal plus interest into equity. But not all models treat interest the same way:

Common variants:

• Interest converts at the same discount/cap as principal.
• Interest converts at the equity round price only (no discount or cap).
• Interest is paid in cash and does not convert.

If DocketMath is set to “interest converts with discount/cap” and an investor spreadsheet assumes “interest converts at round price,” you’ll see:

• Different total shares for each note.
• Slightly different founder dilution, especially in older notes.

In the DocketMath convertible note cap table, double‑check:

• Interest rate (%)
• Accrual period (start and end dates)
• “How does interest convert?” option

3. Misaligned discount vs. cap priority

Most New York‑style notes say something like: “convert at the lower of (i) the price based on the valuation cap, or (ii) the price based on the discount.” But some older or bespoke forms have different priority rules or special cases.

If one model:

• Always uses the cap when it’s available, ignoring the discount, while
• Another model truly uses the lower of cap‑price and discount‑price,

you’ll see big differences whenever the round valuation is near the cap.

Quick diagnostic:

1. Compute the discount price:
   discount price = round share price × (1 − discount %).
2. Compute the cap price:
   cap price = (cap valuation / fully‑diluted shares baseline).

Then check:

• Which price is actually required by your note docs.
• Which price DocketMath is using (shown in the breakdown for each note).
• Which price an investor or counsel spreadsheet is using.

4. Different “fully‑diluted” share count definitions

New York counsel frequently negotiate the “fully diluted capitalization” definition. That definition directly controls:

• The denominator for cap price.
• The implied ownership % for each note holder and for founders.

Common toggles:

• Include vs. exclude:

  • Unissued option pool
  • Warrants
  • SAFEs and other convertibles
  • Shares reserved under future plans

If your DocketMath run assumes “fully diluted includes the entire unissued option pool” but another model excludes it, you’ll see:

• Different share counts per note at the same cap.
• Different post‑money ownership percentages.

To diagnose:

• Find the “Fully Diluted Capitalization” definition in the note.
• List what is explicitly included or excluded.
• Match those inclusions/exclusions in DocketMath’s inputs and in the comparison model.

5. New York‑specific rounding and share‑class quirks

New York corporate practice can sometimes introduce subtle differences:

• Rounding:
  Some cap tables round share counts up to the nearest whole share; others round down, or keep fractional shares and round only in closing documents.
• Preferred vs. common base:
  Certain models compute note conversion into preferred, then later show ownership on an as‑converted‑to‑common basis. If someone else’s spreadsheet is treating the numbers as if they were common from the start, you’ll see mismatches in percentages.

While these are not unique to New York, local practice and law firm templates often standardize on particular patterns, so two “standard” models can still disagree.

How to isolate the variable

When your DocketMath results don’t match another set of numbers, the fastest approach is to reduce the problem to “one moving part at a time.”

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Step 1: Start with a single note

1. In DocketMath, turn off all but one convertible note.
2. Enter:

   • Principal
   • Interest rate and dates
   • Discount %
   • Cap and whether it’s pre‑ or post‑money
3. Set the equity round:

   • Round valuation
   • New money raised
   • Option pool size (and whether it’s pre‑ or post‑money)

Then ask the other side for the exact same single‑note scenario in their model. If one‑note math still doesn’t match, the issue is likely:

• Cap vs. discount handling
• Interest treatment
• Fully‑diluted definition

Step 2: Align obvious parameters

Side‑by‑side, confirm that both models are identical on:

• Round valuation (e.g., $20M vs. $20.5M)
• New money amount
• Option pool % and whether it’s pre‑ or post‑money
• Note principal and interest rate
• Note discount and cap

Only after those match should you move to definitions and rounding.

Step 3: Compare per‑note outputs, not just ownership %

Look at these specific outputs for that single note:

• Conversion price used
• Total shares issued to that note
• Implied ownership % after the round

Whichever of those three diverges first tells you where to look:

• Different conversion price → cap/discount/valuation assumptions.
• Same price but different shares → principal/interest/rounding.
• Same shares but different % → fully‑diluted denominator differences.

Once the single‑note case aligns, re‑enable the remaining notes and SAFEs one at a time in DocketMath and in the comparison model.

Next steps

To systematically debug New York convertible note cap table math:

1. Confirm economic definitions in the documents

   • Pre‑ vs. post‑money cap
   • Fully‑diluted capitalization definition
   • Interest conversion rules
   • Cap vs. discount priority

2. Recreate the scenario in DocketMath

   • Use the convertible note cap table calculator with only one note first.
   • Turn on Explain‑style breakdowns (per‑note conversion price, share count, and ownership).

3. Match assumptions with your other model

   • Align valuation, round size, pool, and rounding rules.
   • Add notes/SAFEs one by one until the numbers diverge.

4. Loop in counsel for New York law questions

   • If the discrepancy turns on how a New York definition should be interpreted, that’s a legal question.
   • Use your DocketMath runs as a factual worksheet to show counsel exactly which assumption changes which number, without asking them to debug formulas.

DocketMath is designed to make these differences visible, not to replace legal judgment. Treat it as a diagnostic tool: change one input, watch how the outputs move, and then decide (with your advisors) which version matches your actual deal.

Related reading

• Why we started the DocketMath blog

• Introducing Explain++: step-by-step calculation breakdowns

• Why we started the DocketMath blog

• Why we started the DocketMath blog