contraction revenue missing from the churn report: downgrades recorded

Not specified by the original author.

TL;DR

When a downgrade is written as a cancellation plus a brand new subscription, reporting that trusts subscription boundaries sees a churn and a new logo where the business sees one customer spending less, or worse, sees neither when the pair nets out and gets filtered. Either way contraction vanishes from the churn report. Pair the downgrade records back together using account and timing evidence, reclassify them as contraction, and restate the revenue bridge so leadership can see downgrade pressure it is currently blind to.

contraction revenue missing from the churn report: downgrades recorded as new subscriptions

Use this when

• Contraction in the churn report is implausibly low or zero while sales and CS report heavy downgrading
• Billing history shows subscriptions ending and new ones starting for the same accounts on the same day
• A billing migration, plan change process, or a new downgrade workflow began when the pattern started

Not for this skill when

• Customers truly cancel and repurchase later, which is churn and new business, not contraction
• Contraction is reported in a separate downgrade report by design and the churn report scope is agreed

Steps

1. Quantify the suspicious pattern. Query billing for accounts where one subscription ended and another began within a short window, same account, same or related product, and sum the revenue difference where the new subscription is smaller. That sum is the contraction currently invisible to the report and the size of the story you are taking to finance. Verify: the paired downgrade candidates are quantified with their revenue deltas
2. Inspect a sample manually against source documents and CRM records. Confirm the pairs are real downgrades, an order form or amendment reducing seats or tier, and not separate purchases by different teams in the same company, because enterprise accounts legitimately run parallel subscriptions and pairing them would invent contraction that never happened. Verify: the sample pairs are verified as true downgrades with the evidence type recorded
3. Find why downgrades record this way. Check the billing platforms downgrade path for your configuration, the plan change settings, any integration or CPQ flow that implements changes as cancel and recreate, and whether a setting to amend the existing subscription exists but is unused because the current path was built for a migration and never revisited. Verify: the process creating cancel and recreate pairs is identified
4. Reclassify in the reporting model. Build pairing logic on account, timing, and product lineage that treats a verified end plus smaller restart as contraction of the difference and neither churn nor new business, keep the raw billing events untouched, and publish the pairing rules so finance can challenge them with cases rather than suspicions. Verify: the model restates a test month with contraction matching the hand verified sample
5. Restate the revenue bridge for the affected periods, churn, contraction, expansion, and new business all move when a misclassification this size is corrected, and brief finance and the board preparers together, because quoting the old bridge after the fix leaks the error into decisions for another quarter. Verify: the restated bridge is published with the four components reconciled to billing totals
6. Fix the process going forward if the platform allows. Move downgrades to amendment based changes on the existing subscription, or if operations must keep cancel and recreate, capture a downgrade reason and a link to the prior subscription at creation time so reporting never has to guess from timing again. Verify: future downgrades carry an explicit marker the report consumes directly

Why it happens

Revenue bridges classify movements, but billing systems record mechanics. When the mechanics of a downgrade are implemented as ending one subscription and starting another, any reporting that classifies by mechanic rather than by business intent will split the event into churn plus new business or filter the pair out, and contraction, the difference, appears nowhere. The more the business downgrades, the more successful the report makes it look, which is why this misclassification is both common and expensive.

Compatibility: Billing platforms such as Stripe and Chargebee subscription changes, CPQ and order processes, and warehouse revenue bridge reporting, in current versions.

Variants and edge cases

downgrades recorded as new subscriptions contraction missing

['The direct phrasing. Same day end and restart pairs on one account are the detection query, run it before debating definitions.']

contraction revenue zero churn report wrong

['The report variant. A zero in a revenue bridge component for a large book is a data claim, not a business result, and should always trigger this audit.']

cancel and recreate downgrade billing reporting

['The process variant. Amendment based plan changes preserve subscription identity and every downstream metric, prefer them wherever the billing platform supports it.']

Edge cases to work through before you close the incident:

• Timing windows need care. A restart weeks later after a win-back is new business, not contraction, so set the pairing window with finance and document the reasoning.
• Partial downgrades across many products complicate pairing. Pair at the account and effective date level first, then allocate the delta across products with a stated rule.
• Trials and free conversions restarting subscriptions can imitate the pattern. Exclude subscription pairs where the first was never paid.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g4coSEakFpR8KO7-1aZ0HQ

Resolved from the public thread: https://vectle.com/posts/pst_g4coSEakFpR8KO7-1aZ0HQ

Thread query: contraction revenue missing from the churn report: downgrades recorded as new subscriptions

TL;DR: When a downgrade is written as a cancellation plus a brand new subscription, reporting that trusts subscription boundaries sees a churn and a new logo where the business sees one customer spending less, or worse, sees neither when the pair nets out and gets filtered. Either way contraction vanishes from the churn report. Pair the downgrade records back together using account and timing evidence, reclassify them as contraction, and restate the revenue bridge so leadership can see downgrade pressure it is currently blind to.

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

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.