Does something look out of place with your numbers? Here’s some possible culprits:
Modified account balance causes most of the troubles – there’s no way to automatically recognize all intentions for changed balance. FirstOfficer.io recognizes setup fees from balance, but not discounts or non-Stripe-payments. You can read more in Best Practices for Using Stripe API.
MRR does not include non-subscription charges, or invoice items charged along with the subscription. In financial analytics, no money = no customer. Customers with 100% discounts are marked as lost. Customers who missed a payment will be marked as lost (until the payment is recovered). Customers who cancelled will not be marked as lost until the payments stop coming. You can read more in Calculation Principles.
Most business models are recognized automatically, but sometimes customization is needed. You might for example want to include non-subscription charges to MRR. Or have created cent-plans for non-quantity usage and would want them removed from calculations. There are also several ways to manually tamper with subscriptions and get them into a condition where MRR gets calculated wrong. In most of the cases the dashboards can still be saved by patching the data.
One common example is when annual subscriptions come up for the renewal the first time. The Net Churn Rate raises as customers finally have a possibility to churn, but as MRR Churn Rate is normalized, it continues to show true churn. You don’t need to know about these special cases yourself, just contact support if you can’t find a plausible explanation for change in numbers.
Although FirstOfficer.io provides reliable and accurate metrics for a large number of customers already, it’s always possible that your data triggers a bug. If you can’t find an explanation for the differences in this article, please contact support . Thanks to the drill-down feature, it’s easy to compare categorizations against customer lists from your old system.