Thanks! I'm curious about your use case and specifics about how you're looking at start date and how often you'd expect to update it (i.e. is this a one-time cleanup or a regular thing?). I'd welcome an email with some details!
I wouldn't say it's unappetizing for us. Even contemplating the possibility offers us insight about what companies the size and complexity of Stripe need to go through in order to migrate Billing systems. e.g. back of house processes for revenue reconciliation and recognition need to work across both systems, we need to support bulk migrations of data, both systems need to recognize the "canonical biller" for a customer so that you avoid double-billing issues, you need to backfill invoices and ensure no gaps in numbering, product teams need to update their integration and provisioning code and so on. My observation is that large companies can spend 10s-100s of engineers on the order of several quarters or years to do this kind of migration safely.
We've made several internal and a few external changes over the years to help our users with these kinds of issues and in my estimation we've been getting closer to making the commitment, but as of right now we haven't done a stop-the-world effort to change systems internally.
Yes, this is definitely a use case we've been working on. If you'd be willing to email me any more details about how you need things to work at [email protected] I'll make sure the feedback makes it to the people working on it.
We’re always working on making Checkout and Billing gel together better, and our Revenue Recognition product automates ASC606-compliant accrual revenue reporting including automatically recognizing data from Stripe Billing. Have you talked to us yet about your use-case? Could you email me at [email protected]?
(I work on Stripe Billing). This is a question we raise fairly regularly internally at Stripe. The real, prosaic answer is because when we started working on Stripe Billing in 2017, Stripe had already built an internal billing system to bill its own customers. Stripe was 7 years old at that point.
At the time, we got lots of feedback from the folks who had built that system. Our goal was to build a flexible billing system for all kinds of companies at different sizes, but we were definitely focused on smaller (doing maybe $100k–$10M of ARR) SaaS companies to start. We've come a long way since then and now power billing for a number of large/public companies. Atlassian, Figma, Notion and Slack are either using or migrating onto Stripe Billing today.
Stripe Billing is a powerful tool with a role to play in any company's revenue management system, including Stripe's. Newer Stripe products (such as Atlas) do build on top of Stripe Billing but we haven't gotten around to migrating our existing stack. That said, I do have a personal goal of taking on more internal billing responsibilities over time (e.g. I think we could easily use Stripe Invoices internally today, and it's mostly opportunity cost keeping us from actually doing so).
I do want to say that the specific use case covered in the post is something we have thought about a lot. I think about it as a pipeline with stages for collecting high volumes of usage events, aggregating them, mapping them to rate cards based on usage, and then producing recurring bills, collecting payment, dunning, etc... The post claims we don’t do a good job on the first two stages (collecting usage events and aggregating them) is perhaps missing that the style of percentage-based fees is a one-line addition to a Connect integration as my colleague edwinwee mentioned below. It is also possible to have a scalable usage event collection/aggregation pipeline integrated with Stripe Billing. You can read this AWS blog post https://aws.amazon.com/blogs/apn/building-a-third-party-saas... for information about how to build such a system according to our best practices.
While I’m here, I’m always eager to hear feedback on Stripe Billing from folks who are using it. My email is [email protected].
(Engineering Manager at Stripe Billing) Ah - sorry about that, a last minute fix caused a bug. This is now fixed in production. Thank you so much for reporting!