Read your revenue

One derivation, every rail, every surface

Here's the promise behind every number on the Revenue page: it's computed one way. The same code path produces your MRR whether the subscription came from Stripe, Apple, or Google, and whether you're reading the web dashboard or the iOS companion app. When two surfaces show the same project at the same moment, they cannot disagree — because they read the same record through the same derivation.

That's worth understanding before you trust a number to make a decision. You're not reading three rails bolted together with three different definitions of "paying." You're reading one book.

Two numbers to know: MRR and at-risk

Open Revenue in the dashboard. The headline is your MRR — a monthly-equivalent figure that rolls every active subscription, on every rail, into one number. Next to the money you'll find your active subscriptions and paying customers, and an at-risk count — the slice of the book where a payment has failed and the rail is retrying.

The two numbers that drive most decisions are MRR (how much is on the book) and at-risk (how much of it is currently impaired). The rest of this lesson is exactly what each one counts — so you read them right.

Which subscriptions count, and how intervals normalize

Every subscription Crossdeck mirrors carries one canonical state, and a subscription contributes to MRR if and only if its state is revenue-bearing. Four states count; three don't:

• Counts: ACTIVE (paid and current), BILLING_RETRY (payment failed, rail retrying), GRACE_PERIOD (retries inside a grace window), PAUSED (collection paused, not ended — the stream resumes).
• Doesn't count: TRIAL (no money has moved — becomes MRR the moment it converts), EXPIRED (lapsed or canceled), REFUNDED (the rail reversed the money).

That revenue-bearing set is a single constant in the backend, and every read that asks "is this customer paying?" goes through the same check — so "paying" means the same thing on the Revenue page, the active-subscription count, and the top-products roll-up.

Because MRR is monthly-equivalent, every billing interval is converted by one function, on Gregorian math (a month is 365.25 / 12 days, not 30): a $120/year plan contributes $10.00/mo; a $5/week plan contributes ~$21.74/mo. Annual and weekly plans sit in the same number as monthly ones, correctly weighted.

At-risk still counts as revenue — and that's the accounting answer, not optimism. A subscription in BILLING_RETRY or GRACE_PERIOD hasn't ended; the rail is actively retrying the card and the customer keeps their access through both windows. So it stays on the book at its full monthly amount, and the at-risk count tells you how much of the book is impaired. It resolves one of two ways: recovery (the charge succeeds, the subscription returns to ACTIVE, MRR never moved) or lapse (retries exhaust, it transitions to EXPIRED, and MRR drops by that amount from that day's snapshot forward).

You know what every number means

MRR is your revenue-bearing book, normalized to monthly. At-risk is the impaired slice of it, still counted because it hasn't churned yet. And the same derivation runs on every rail and every screen — so the web and the iOS app always agree.