Definitions you can defend, and a difference you can explain

Reproducibility before precision

The complaint that shows up most often about subscription analytics is not that a figure is wrong. It is that nobody can say how it was produced. Rules are undocumented, they are not configurable, and when the tool's MRR disagrees with the payment provider's the vendor's answer is that they normalise things differently. That is an unfalsifiable claim, and finance cannot sign one.

Bastle's position is that a definition is a business decision, so it belongs to the business. Every metric carries the formula that produced it, the period boundaries and the record set behind it. If you disagree with a result you can find out exactly where the disagreement starts.

The policies that actually move the number

A handful of choices account for most of the variance between two honest calculations of the same subscription business:

• Delinquency window — whether a subscription with a failed payment is still revenue after thirty days, sixty, or indefinitely.
• Trial handling — whether trialing subscriptions are counted as customers and as revenue.
• Coupon treatment — whether a full-discount coupon reads as churn or as a customer paying zero.
• Same-day wash — whether a subscription started and cancelled the same day is a signup plus a churn, or neither.
• Annual churn lookback — because annual plans are invisible to a thirty-day churn window and a blended rate hides them.

Each is set per workspace. Change one and history recalculates against the new rule, so a comparison across periods is a comparison on one definition rather than a comparison of two definitions.

Reconciliation is work you still do yourself

Bastle reports what the business earned; the payment provider reports what it billed. Those differ for reasons that are individually sensible — trialing users are not customers, your test account is not revenue, a refund reverses recognition, delinquency is a policy question. What Bastle gives you today is the input side of that bridge: each figure names its formula, its period and the records underneath, and the policies driving each adjustment are ones you set and can read back. Assembling the bridge is still manual. An automated view that itemises the variance against your provider's figure is on the roadmap and is not built, and it would be easy to imply otherwise on a page like this.

Where the boundary is

Bastle is not an accounting system and does not perform revenue recognition. There are no deferred revenue schedules, no GL journals, no locked periods, no ASC 606 or IFRS 15 automation. If recognised revenue and audit-grade subledgers are the requirement, the products built for that job are the right purchase, and a comparison that claimed otherwise would waste an evaluation cycle. There are also no managed warehouse destinations; you get an API, webhooks and exports and build the pipe yourself.

What Bastle covers is the subscription measurement layer beside that: MRR and its movements, churn in each of its forms, cohort retention, segmentation, and forecasting in beta with expense modelling, runway and budget variance, with accounting actuals synced from QuickBooks Online or Xero.

Getting it out

Every metric is a daily series over the REST API, with the customers and plans behind each movement and cohort retention as structured cells. Daily snapshots, CSV export of customers and series, and signed outbound webhooks with automatic retries cover the rest. The API returns figures from the same engine as the dashboards, which is the actual point: an internal report and a Bastle screen cannot quietly diverge into two versions of MRR.