gross churn and net churn swapped in the board report: expansion inc

Not specified by the original author.

TL;DR

Gross churn cannot be improved by expansion, that is the entire point of it, so when a board report shows gross churn moving with expansion deals, the two calculations have been crossed somewhere in the model. Gross churn counts only lost revenue from churn and contraction against the starting base, net churn subtracts expansion as well. Find where expansion entered the gross figure, fix the model, restate the board series, and lock the definitions where the next analyst cannot quietly re-cross them.

gross churn and net churn swapped in the board report: expansion included in the wrong calculation

Use this when

• Gross and net churn in the board report are equal, or gross moves when only expansion changed
• Finance figures for the same period do not match the boards gross number
• A report refactor or a new analyst rebuilt the churn model recently

Not for this skill when

• Both metrics were rebuilt correctly and the board is comparing different periods or bases
• Expansion is tiny this period, so gross and net legitimately sit close together

Steps

1. Write the two definitions out in full with the exact components and base period each uses, from your finance teams agreed standard, and keep them in front of you for the whole investigation. Most swaps survive because people argue from the metric names instead of the component lists, and names feel obvious until they are not. Verify: both definitions are documented component by component
2. Recompute both metrics by hand for one recent month from billing records, listing starting recurring revenue, churned revenue, contraction, and expansion per account, and summing each metric strictly by the written definitions. This hand built month is the arbiter for everything the model claims. Verify: the hand built gross and net figures for the test month are recorded
3. Compare the models outputs component by component, not just the final rates. Where the model gross equals your hand net, or its components show expansion inside the gross sum, read the model code at that exact component and find the crossed term, a reused intermediate measure is the usual culprit, where a net revenue change variable feeds both calculations. Verify: the crossed component in the model is located
4. Fix the model so gross and net are built from named, separate component measures with no shared intermediate that mixes expansion in, and rename ambiguous measures so expansion carrying ones cannot be mistaken for loss only ones by the next person editing the file. Verify: the corrected model reproduces the hand built month for both metrics exactly
5. Rebuild the full board series and check the relationship that must always hold, net churn is less than or equal to gross churn for every period, and gross never improves in a month where losses were flat and only expansion grew. Flag and investigate any historical period that still violates the relationship. Verify: every period in the rebuilt series satisfies the relationship between the two metrics
6. Restate to the board with a clear note on which periods changed and why, publish the definitions in the board pack appendix, and add an automated check in the reporting pipeline that fails when net exceeds gross, so a future swap stops the pack instead of reaching directors. Verify: the board pack carries the definitions and the pipeline check is active

Why it happens

Gross and net churn differ by exactly one component, expansion, and reporting models often compute a single revenue change measure and reuse it in both places for convenience. The reuse swaps the metrics results while keeping both numbers plausible, so nobody questions them until finance, working from definitions, produces a different gross figure. Plausibility is what makes this error durable, only the invariant between the two metrics betrays it reliably.

Compatibility: Board and finance reporting models over Stripe or Chargebee revenue data, with agreed gross and net churn definitions, in current BI and warehouse tooling.

Variants and edge cases

gross churn net churn swapped board report

['The direct phrasing. The invariant that net can never exceed gross is your fastest detector, check it across all periods first.']

expansion included in gross churn calculation

['The component variant. Shared intermediate measures are where swaps breed, separate and rename them as part of the fix.']

board churn numbers do not match finance

['The credibility variant. Bring the hand built month and the definitions page, boards accept arithmetic they can follow and distrust assertions.']

Edge cases to work through before you close the incident:

• Cohort based and period based churn are different again. Confirm the board definitions specify which, or the swap fix will expose a second quiet disagreement.
• Annual and monthly bases must never mix inside one series. If the refactor standardised the base as a side effect, call that out separately in the restatement.
• Multi-currency revenue needs a stated conversion rule in the definitions. Expansion in one currency can otherwise appear to move gross in another.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_to0NeyFV9QI5e1DXdzVXjw

Resolved from the public thread: https://vectle.com/posts/pst_to0NeyFV9QI5e1DXdzVXjw

Thread query: gross churn and net churn swapped in the board report: expansion included in the wrong calculation

TL;DR: Gross churn cannot be improved by expansion, that is the entire point of it, so when a board report shows gross churn moving with expansion deals, the two calculations have been crossed somewhere in the model. Gross churn counts only lost revenue from churn and contraction against the starting base, net churn subtracts expansion as well. Find where expansion entered the gross figure, fix the model, restate the board series, and lock the definitions where the next analyst cannot quietly re-cross them.

Not specified by the original author.

TL;DR

One segment falling below 100 while its accounts look healthy means the expansion side of the ledger broke, and a recent plan change is the obvious place it broke. When plans are renamed, rebundled, or moved to new price IDs, expansion logic keyed on old plan names stops recognising upgrades and counts the same customers as flat or contracted. Rebuild the segments NRR from raw billing line items, fix the classification to key on money movement rather than plan labels, and the segment returns to its real value.

net revenue retention dropped below 100 for one segment only: expansion not counted after the plan change

Use this when

• NRR dropped below 100 for one segment while other segments held steady
• A plan rename, rebundle, or price migration touched exactly that segment
• Accounts in the segment show upgrades in the CRM that NRR seems to ignore

Not for this skill when

• Billing line items confirm the segment really spent less, making the drop real
• The segment lost its largest account, which can pull NRR below 100 legitimately

Steps

1. Rebuild the segment NRR by hand for one period from billing data. List starting revenue, expansion, contraction, and churn per account from subscription and invoice records, without using the reporting model at all. The hand built number is your ground truth and tells you which component disagrees with the model, expansion in the suspected case. Verify: the hand built components are documented and the disagreeing component is named
2. Compare account level expansion in the model against billing. Pull accounts whose billed revenue rose period over period in that segment and check how the model classified them. If rising accounts show zero expansion, read the classification rule and find its dependency on plan name, plan ID, or product code that the plan change altered. Verify: the classification dependency broken by the plan change is pinpointed
3. Inspect the plan change itself. List old and new plans, prices, and product codes with their effective dates, including any mapping table the billing team used for migration. Confirm whether expansion events after migration carry new identifiers the model has never seen, and whether some accounts sit on hybrid states during a phased migration. Verify: the old to new plan mapping and effective dates are recorded
4. Fix classification to follow money and subscription facts rather than labels. Expansion should be computed from the change in recurring revenue on the same account, with plan mapping used only for reporting dimensions, and every new plan or price should be swept into the mapping by a check that fails loudly on unmapped identifiers instead of silently counting them as nothing. Verify: the fixed model flags an unmapped test plan instead of silently ignoring it
5. Recompute NRR for every period since the plan change, compare the segment trend against the hand built period, and confirm other segments did not move, because a classification fix should be surgical and a model that changes healthy segments has introduced a second bug. Verify: recomputed segment NRR matches ground truth and other segments are unchanged within rounding
6. Restate the segment story for leadership with the corrected series and the cause, and add a monthly unmapped plan and price report owned by the data team, since billing teams will keep launching plans and the reporting layer must notice on day one. Verify: the unmapped identifier report runs monthly and reaches a named owner

Why it happens

NRR is a ratio of money movements classified into buckets. Classification code often leans on stable looking labels such as plan names or price IDs, but billing catalogues are marketing surfaces that change whenever packaging changes. When a segment migrates to new plans, its genuine upgrades stop matching the expansion rule and vanish from the numerator, while contraction and churn rules, keyed differently, keep working, so exactly one segment sinks below 100 for a bookkeeping reason.

Compatibility: Net revenue retention models over Stripe or Chargebee billing data, billing plan and price catalogues, and warehouse reporting, in current versions.

Variants and edge cases

net revenue retention below 100 one segment expansion missing

['The component phrasing. Decompose NRR before debating it, the broken component is almost always visible in one hand built period.']

NRR wrong after plan change price migration

['The migration variant. Any billing catalogue change should trigger a reporting impact review, add it to the billing change checklist permanently.']

expansion revenue not counted NRR model

['The model variant. Keying financial classification on display names is the underlying fragility, money based rules survive renames.']

Edge cases to work through before you close the incident:

• Seat based expansion can hide inside the same plan with no plan change at all. Make sure the model reads quantity changes, not only plan switches.
• Mid period migrations split an account across two plans in one period. The model needs a rule for that case agreed with finance, not an accidental outcome of join order.
• Currency and proration noise can move small segments. Set a tolerance when comparing hand built and model numbers so you chase real gaps, not rounding.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstd0vz40VTX4MtwO4nKVz-g

Resolved from the public thread: https://vectle.com/posts/pstd0vz40VTX4MtwO4nKVz-g

Thread query: net revenue retention dropped below 100 for one segment only: expansion not counted after the plan change

TL;DR: One segment falling below 100 while its accounts look healthy means the expansion side of the ledger broke, and a recent plan change is the obvious place it broke. When plans are renamed, rebundled, or moved to new price IDs, expansion logic keyed on old plan names stops recognising upgrades and counts the same customers as flat or contracted. Rebuild the segments NRR from raw billing line items, fix the classification to key on money movement rather than plan labels, and the segment returns to its real value.

Not specified by the original author.

TL;DR

Count cancellations in billing before you believe the churn chart. When logo churn doubles and the billing system shows flat cancellations, the churn numerator is counting something billing never cancelled, and duplicate accounts are the prime suspect, because a duplicate that gets cleaned up, merged, or abandoned looks exactly like a lost logo to a naive count. Find the duplicates, fix the identity resolution, and restate churn with the phantom losses removed.

logo churn doubled on paper but cancellations stayed flat: duplicate accounts inflating the churn count

Use this when

• Reported logo churn jumped sharply, here roughly double, while subscription cancellations stayed flat
• The jump coincides with a CRM cleanup, dedupe project, import, or a new account matching rule
• The churned account list includes names that also appear as active accounts

Not for this skill when

• Billing confirms cancellations really doubled, making this a business crisis rather than a data defect
• The denominator shrank because of a portfolio sale, which raises the rate without duplicates

Steps

1. Pull the churned account list for the affected period from the churn model and join it against billing cancellations by account and by company name. Quantify how many reported churns have no matching cancellation, because that unmatched set is your investigation scope and your headline impact number for stakeholders. Verify: the unmatched churn count is quantified and exported
2. Inspect the unmatched accounts for the duplicate pattern. Look for the same company existing twice with slightly different names, domains, or IDs, where one copy is marked churned or inactive while the other carries the live subscription and usage. Check creation sources, imports and integrations love creating the second copy, and merge history in the CRM. Verify: the duplicate pattern and its creation source are identified for a sample of the unmatched accounts
3. Check what the churn model counts as churned. If it treats account status changes, record deletion, or absence from a sync as churn, then every dedupe merge and cleanup deletion becomes a phantom churn event. Read the model logic for those paths specifically, because the model may be faithfully reporting a definition nobody intended. Verify: the model paths that convert merges, deletions, or missing records into churn are named
4. Fix identity at the right layer. Merge duplicates in the CRM using the billing backed record as the survivor, publish a single account crosswalk for legacy IDs, and change the churn model to count a logo as churned only when its billing subscription ended and no surviving account for the same company holds an active one. Verify: merges and the crosswalk are complete and the model applies the billing backed rule
5. Restate the churn series for every affected period, showing the phantom count removed per month, and brief CS and finance together so both stop quoting the inflated series and understand why the corrected one is trustworthy, namely it now reconciles to cancellations. Verify: restated monthly churn reconciles to billing cancellations within an agreed small tolerance
6. Add guardrails. Alert when monthly churned logos exceed billing cancellations beyond tolerance, and require any bulk account cleanup or import to run a churn impact preview first, because identity projects will keep happening and each one can mint phantom churn. Verify: the reconciliation alert exists and the cleanup preview step is in the data teams checklist

Why it happens

Logo churn counts companies, but systems store records, and the two drift apart whenever duplicates exist. A dedupe project, an import, or a stricter matching rule can retire swathes of duplicate records in one month. Models that equate a retired or inactive record with a lost customer then report a churn wave, while billing, which tracks the surviving subscriptions, correctly shows nothing happened.

Compatibility: CRM account deduplication and merge tooling, billing cancellation records from Stripe or Chargebee, and warehouse churn models, in current versions.

Variants and edge cases

logo churn doubled duplicates inflating

['The direct phrasing. The billing cancellations count is the tripwire, flat money with doubled logos is a data signature, not a market event.']

phantom churn from merged accounts

['The merge variant. Every merge retires an ID, so any model keyed on IDs must consume the crosswalk or it reports the merged-away copy as churned.']

churn count up cancellations flat data problem

['The triage phrasing for leadership. Lead with the reconciliation evidence, classified duplicates, before proposing restatement, so the correction reads as rigour rather than excuse.']

Edge cases to work through before you close the incident:

• Some duplicates hold real separate subscriptions for different divisions. Merge decisions need the billing picture per company, not name similarity alone.
• A crosswalk must be versioned and permanent. Deleting old mappings during a later cleanup recreates phantom churn in historical restatements.
• Watch the denominator too. Duplicates inflate starting logos as well, so corrected churn rates can move in both numerator and denominator.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XDbyBS8YQU3-EmtBXC5S9g

Resolved from the public thread: https://vectle.com/posts/pst_XDbyBS8YQU3-EmtBXC5S9g

Thread query: logo churn doubled on paper but cancellations stayed flat: duplicate accounts inflating the churn count

TL;DR: Count cancellations in billing before you believe the churn chart. When logo churn doubles and the billing system shows flat cancellations, the churn numerator is counting something billing never cancelled, and duplicate accounts are the prime suspect, because a duplicate that gets cleaned up, merged, or abandoned looks exactly like a lost logo to a naive count. Find the duplicates, fix the identity resolution, and restate churn with the phantom losses removed.