MRR and its movements, with NRR and GRR

Compute each customer's MRR on the last day of the month and compare it with the last day of the previous month. Each customer-month falls into a single movement. The raw change log counts back-and-forth changes within the month and, in one real base, inflated movement by about 18%. The month's snapshot uses the last day of the month for every segment, never the last day each segment had a row.

Churn is a customer who had MRR at the end of the previous month and ends the month with no active subscription. A plan change, renewal or subscription swap for the same customer is expansion, contraction or nothing. Migrating the same customer from one product to another can still count as churn on the source and new on the destination in the per-product view, but must be flagged separately so it doesn't appear as logo loss. Economic-group consolidation follows the rule the workspace already has: if the rule is not to consolidate, each billing account is a customer and only the groups listed in the exceptions are merged.

Annual, semiannual, quarterly or non-standard cycle plans go in divided by the months in the cycle (in Stripe, price.unit_amount x quantity divided by the months of price.recurring.interval x interval_count). Prices with billing_scheme = tiered or usage_type = metered have no unit_amount, and the formula returns zero with no error: value that item by the total of the lines on its latest paid invoice (a tiered item produces several lines in the same period, sum them all) or sum the tiers for the contracted quantity. Before moving on, list the items on active subscriptions that ended up with zero MRR: the list must be empty or every case explained. When the source is the invoice, allocate the recurring amount across the accrual months it covers.

Implementation, setup, one-off credit purchases (one_time price), prorations, one-off services, marketplace fees and partner revenue stay out. Usage-based billing (metered price) only counts in MRR up to the contractual minimum; variable usage above it goes to its own usage revenue column, otherwise every swing in consumption becomes expansion or contraction. A recurring discount reduces MRR; declare when a temporary discount starts to count (some only consider open-ended discounts or those lasting more than 3 months).

Active subscriptions go in. Trialing is not MRR. Canceled and incomplete_expired go out, and the filter is mandatory because a canceled subscription still has items and price filled in. Past_due is a business decision: the safest is to keep it in MRR flagged as at risk until it becomes canceled or unpaid. Removing past_due from MRR creates churn and reactivation that never happened when the invoice gets paid. Unpaid is also a declared decision: state whether it leaves MRR and check it against the finance report's criterion, which often keeps unpaid, or the reconciliation won't close. A freeze shows up in Stripe as status paused or pause_collection filled in on the subscription: classify it as a freeze, not as churn.

On cancellation, the customer's current MRR goes to zero. The amount lost is the customer's MRR at the end of the previous month, or the last known value before canceled_at. Zero MRR never means a free customer: it means a customer who left.

A customer with zero MRR at the end of the previous month and more than zero now is new if they never paid and a reactivation if they had MRR in some earlier month. Reactivation doesn't go into the cohort's NRR, because the customer wasn't in the starting base.

Billing exposes the current state, and Stripe's events API only keeps the last few days. A change in quantity or plan on the same subscription disappears. Write a daily snapshot of subscriptions and items, or a history with valid from and valid to, from day one. For the months before the history starts, rebuild from paid invoice lines with a recurring price and no proration, counting each line in the month whose last day falls inside its service period (period.start to period.end). The first month with a snapshot compares two different sources: flag it as the seam month and keep its movement out of the board deck.

After the close, write the month's result as a provisional version and allow a single correction, which becomes final. Later retroactive corrections go in as an adjustment in the month they were discovered, with the reference month recorded, never rewriting the number already reported.

Convert everything to the reporting currency at a declared rate and use the same fixed rate across the whole movement series: with a monthly rate, a foreign-currency customer who didn't change plans shows up as expansion or contraction. If you need the view at realized exchange rates, show the FX effect on a separate line. Check whether the converted column comes through null for foreign currency before summing.