Stripe Data vs. Open‐Source Alternatives: A MRR Example

100%. Stripe is a blackhole.

For my current project, I pay nearly 5-7% on each transaction to Stripe. For my next project, I'm implementing custom billing and using Stripe just as a payment processor.

Often the database structure that is amenable for running the app or billing system isn't the one that is ammenable for generating a graph of historical MRR over your company's lifetime (or future expected revenue!)

And when you get into cohort analysis, it gets a bit messier. Your cohort calculations might be cheap on one user but not across your entire system.

This is often just a question of some very simple data engineering. But you get queries that are "good enough" and "basically are right". So you use them. And they get slower and slower until they take like 10 minutes to run because you're calculating historical app usage data for your bespoke cohort. And then they start taking hours. And then they're just timing out constantly. And then you start fundraising and you do "MRR/ARR vs actual money in/out", and find weird discrepencies (yes you included one-time purchases. Or did you? And your rebates done through the stripe dashboard definitely were captured in your app database right?)

Oh and of course your top sales person has been giving people discount coupons but they were doing it in Stripe instead of in your bespoke system and you weren't properly flowing the data back into your system because of webhooks and now you realize that your MRR is 5% less than it actually is (and it's been like this for 2 years so now you have lied to investors consistently for 2 years).

Nothing is really hard, but it's too easy to get a "close enough" answer and the activation energy to doing this stuff right is just high enough to where people put it off for way too long.

Partly. There is always some data you will need in the future that you don't think to store today. So I suspect MRR is not the only issue these startups are having. Another example is stripe just does not make some fields available via api. Say, the date an external account was added to a connected account. That is not in the api, so if you then want to add some logic that depends on the age of certain accounts (maybe fraud prevention), you're out of luck. You would have to handle the event when it happened, and use the current time. But Stripe does show this date on the UI.

....that's exactly what the article is describing.

Retrieving the metrics you want from raw data.

Some businesses are large enough that polling the API and/or ingesting webhooks is a poor architectural choice or simply impossible — Sigma and the other bulk data products are extremely useful for these businesses.

The other kind of business that benefits from Sigma is much lower tech than yours, and most likely doesnt have a database or something that can accept webhooks.

they already have the data, so at some level it's easier to give them the rest of it and process it with their service than do it yourself

I consult in this space, and Sigma is one of my favorite tools. It can be useful specifically for fighting delinquent churn. One of the first things I like to check is to see if a particular card brand is declining more than others. I also like seeing the average time between the first failed payment and success. There is all sorts of data in Stripe that can help create a strategy for combating delinquent churn.

Sure you could get and store all of this data from webhooks and into the database, but most product teams don’t want to spend the time implementing this. Keep in mind it’s usually the finance/revenue team that needs this data. They’d rather pay Stripe a couple hundred/thousand dollars and get the data instantly, rather than bugging the product team only to find out the ticket got back burnered.

We had the same issue, but it was over by 10-20% in our case. Discussed this with them multiple times, and the last response I got was:

"I've checked in with our engineering teams, and we unfortunately don't yet have a fix or timeline to share here, though we have made additional progress on scoping a path forward. It's extremely complex on our end, as existing data models don't have the required information in place to make the change here, and we'd need to scope how to add that and backfill data (which we're approaching, but again, no timeline to share as of now)."

Obviously I don't know anything about them internally, but if I can export the data as a CSV-file, and then calculate the MRR myself in GSheets, then what data needs to be backfilled? The data is already available to properly calculate it.

Exactly, Lago seems like its riding the open source wave. Nobody reasonable is going to self host this.

Such a common oversight for writers. Define your acronyms when they are first used, it takes very little effort and it will help some of your readers.

Yes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently

I don't think it's quite so subjective. At least, the edge cases you bring up would not significantly affect your metrics no matter how you handled them. MRR is a metric used for strategic planning and evaluation, it doesn't have to be exact, it's not going on your tax submissions.

You usually track MRR based on users who are currently paying for your service (summing recurring subscription amounts, as you put it). Whether their payment falls at the end of the month or is delayed a day to the next month doesn't affect MRR. Most subscriptions must be paid before the billing period begins.

Things like cancellations or chargebacks are counted separately and would not affect past MRR calculations. No you never count free trials. Yes, you count people who have a credit or balance assuming they overpaid to get that balance. If it was just given as a comp, then no.

Yes, you count people who are set to expire until they actually expire and don't renew.

Much of this would be solved if you specified whether you used cash or accrual basis

Would equals be simple enough for a staff member with limited accounting and tech background who has been putting simple revenue, churn, product trend reports together by hand using our stripe data? If so, how can we reach out to schedule a meeting to discuss?

> The article is correct that calculating MRR is difficult and requires access to your billing data.

Then Stripe should provide the metric as an API and precalculate it. (They already have as it powers their dashboards, it's just inaccessible via API access.)

It's extremely frustrating that external metrics dashboards report MRR as significantly higher than it actually is.

It makes me distrust and dislike Stripe that such a core figure is absent in their API. There should be zero excuse for not providing it. It's a ridiculous omission.

I've spent too much time trying to solve this and it disappoints me.

I have to agree here. Feels like pure marketing/selling blogpost. I was not convinced.

The question is: how can we (Lago) make it much easier (if you think it's not the case today) than working with the data from Sigma and from data pipeline exports?

Lago doesn’t store card data. You still use a Payment Processor like Stripe to process one-off payments. But the Subscription management and data related to subscriptions moves into Lago, in short you save on the fee you pay Stripe to manage subscriptions (Called Stripe Payments), it’s aprx 2% of the charge.

Who has subscriptions and when they are charged is now handled in your Lago code.

You can also then mix in other payment processors and regain control of your data.

I would still use Stripe as a startup. However I do provide services with integrated gateway and processor if you are in Canada or USA. I can be reached with the email in my profile.