Report numbers you can defend line by line

Twenty-eight, covering revenue (MRR, ARR, net revenue, other revenue, fees, MRR growth rate, quick ratio), MRR movements (new and active subscriptions, plan quantities, upgrades, downgrades, failed charges, refunds, coupons), and customer metrics (ARPU, ASP, LTV, new, active and churned customers, reactivations, user churn, gross and net revenue churn, net revenue retention, cohort retention and trial metrics). All of them come from one calculation engine, so a figure shown on a dashboard, returned by the API and quoted by the assistant is the same figure.

Because Stripe reports what it billed and Bastle reports what the business earned. Stripe counts trialing users as customers, has no way to exclude your own test accounts, and treats delinquent subscriptions inconsistently. Bastle normalises those cases, applies the rules you configured, and attaches the formula and source records to every figure, so the gap traces back to a rule you can inspect. A view that itemises each adjustment line by line is on the roadmap and is not built yet.

Yes. The delinquency window (30 days, 60 days, or disabled), whether trialing subscriptions are excluded from revenue, whether a full-discount coupon counts as churn, whether a subscription started and cancelled on the same day is treated as a wash, and the annual-plan churn lookback are all per-workspace policy. Changing one recalculates history against the new rule and records the change, so past reports remain explainable.

Every active subscription is converted to a monthly-equivalent amount: an annual plan at 1,200 a year contributes 100 a month, and quarterly or custom intervals are handled through the interval count. Quantities and recurring add-ons are added, discounts subtracted. One-off charges, setup fees, usage-based line items, free plans and trials are excluded from MRR and reported separately, because mixing them in makes the number stop meaning recurring revenue.

Billing events stream in continuously and metrics recompute against them, so dashboards reflect recent activity rather than a batch that ran overnight. Every event carries both a business time and an ingest time, which means a backdated correction lands in the period it actually belongs to instead of the day it arrived.

No. Connecting a billing source with OAuth is the whole setup, and the metrics, cohorts and segments are ready as soon as the backfill finishes. There is no script to deploy and no modelling work for the core metrics. Teams that do have data infrastructure can pull the same figures over the REST API rather than recomputing them.