The 95-5 Billing Rule

After almost a decade of billing engineering, I’ve landed on a ratio that I think captures most of what goes wrong in this space: billing is 95% data management and 5% billing vendor management. Stripe, Recurly, Chargebee, whatever you use, is a payment execution layer. It charges cards and sends invoices. That’s the 5%. The other 95% is knowing who owes what, why, since when, and being able to prove it. Most companies I’ve seen get this completely backwards. They pour engineering effort into Stripe product configs, price objects, coupon logic, and subscription lifecycle management inside the vendor dashboard. Their own database is an afterthought. Maybe a stripecustomerid column on the users table and a prayer.

You feel the pain when someone asks you to change pricing. If your billing truth lives in Stripe, a pricing change isn’t a data migration. It’s archaeology. You’re spelunking through price objects, checking which subscriptions reference which prices, wondering if that coupon from 2023 still applies to anyone, and manually verifying edge cases in the dashboard. I’ve watched this take months at companies that should be able to ship a pricing change in a week. The problem isn’t Stripe. Stripe’s API is good. The problem is that Stripe became the source of truth for business logic it was never meant to own.

What actually works is treating your billing vendor as an output, not a source. You build a canonical internal model: your own representation of plans, entitlements, pricing tiers, and customer state. You ingest every webhook and store it. You build state machines around subscription lifecycles so you can answer “what happened to this account and when” without calling an external API. You maintain audit trails. When Stripe charges a card, it’s because your system told it to, based on your data, following your rules. Stripe is the last mile, not the brain. This is the 95%: event-driven architecture, clean internal models, and knowing your own data cold.

The companies that get this right can change pricing in a deploy. They can migrate billing vendors without a six-month project. They can answer finance’s reconciliation questions with a query instead of a spreadsheet. The ones that don’t are stuck, locked into a vendor’s data model, terrified of touching anything, and spending months on changes that should take days. This matters even more now. In an AI world, you don’t need a billing team. You need someone who knows how to call the Stripe API but, more importantly, can architect a data plane that captures every dimension of a customer’s usage. Token counts, seat changes, feature access, metering events. That’s the job now. The Stripe integration is a weekend. The data architecture is the actual work. If you’re building billing right now and you’re spending most of your time in Stripe’s dashboard, you’re probably doing it backwards. Build your data layer first. Let the vendor be the 5% it’s supposed to be.