Subscription data is deceptively complex
Can AI write your metrics queries?
Yes. Writing code has never been easier, and this is the part where pretending otherwise would waste your time. Point an assistant at a billing schema and it will produce working SQL, a chart library wired up, and something deployable, in an afternoon. Ten years of "engineering time is expensive" arguments stopped applying.
What it produces is a calculation. Whether that calculation matches how your business actually bills is a separate question, and it is the one that costs money.
Why subscription data is harder than it looks
A payment processor records transactions. Subscription metrics describe relationships over time, and converting one into the other means taking a position on every way a billing arrangement can deviate from a flat monthly charge.
The billing situations that quietly break reporting.
Billing setup
- Multiple billing systems
- Auto vs. manual collection rules
- Payment method changes
- Billing system migrations
- Delinquent and past-due subscribers
- Mobile app stores
- Accounting integrations
Plans and pricing
- Multiple products
- Multi-component subscriptions
- Add-ons and overages
- Pro-rated adjustments
- Free subscriptions
- Free and paid trials
Currencies and regions
- Multiple currencies
- Multiple geographies
- Forex fluctuations
Billing exceptions
- Recurring charged as one-time
- Custom contract terms
- Paused subscriptions
- Pending invoice items
- Refunds and credits
- Written-off and voided invoices
Count how many of those apply to you today, then how many will in eighteen months. Almost nobody is at zero, and each one is a decision an AI assistant will make for you, reasonably, without mentioning it.
Seven of them are worth spelling out, because they are the ones that move a reported number most.
An annual plan paid upfront
A customer pays $12,000 in January for a year. Is January's MRR $12,000 or $1,000?
Amortizing over twelve months is the convention, because otherwise January looks like a spike and February looks like catastrophic churn. But now the cash and the MRR disagree, and your finance lead will ask which one is real. Both are, for different questions, which is why the answer has to be deliberate rather than whatever the query happened to do.
A mid-cycle upgrade with proration
A customer on $100 a month upgrades to $200 on the 15th and is charged $50 for the remainder of the period. Expansion MRR for that month is $100, not $50, because MRR is the normalized run rate rather than the amount invoiced.
Use the prorated charge and expansion is understated every month it happens. The error is small per event and compounds silently across a growing customer base.
A failed payment in dunning retry
A card fails on the 1st. Dunning retries for three weeks. The customer updates their card on the 22nd and the charge succeeds.
Were they churned for three weeks, or never churned at all? Both answers are defensible, and they produce materially different churn rates. Involuntary churn also behaves differently from voluntary churn, so folding them together hides a problem you could actually fix.
A customer who cancels and comes back
Someone cancels in March and resubscribes in May. Churn plus new business, or reactivation?
Treating it as new business inflates both churn and acquisition, and makes your cohort retention curves look worse than the business is. The gap that counts as "returning" rather than "new" is a threshold somebody has to choose, and it will not be obvious later that anyone chose it.
One company with five subscriptions
An enterprise customer has five subscriptions across three teams. One customer or five?
This single decision changes customer count, ARPA, logo churn, and every per-customer metric at once. It gets harder when the same company pays through two processors, or when a subsidiary is billed separately, and harder again when one of the five cancels.
Revenue in a second currency
You start selling in euros. Reporting in dollars requires a consistent historical rate policy, and then separating real growth from currency movement.
Without that separation, a quarter that looks like 4% growth might be 1% growth and a weak dollar. The reverse is worse, because you will go hunting a problem that does not exist.
A discount that expires
A customer has 20% off for six months. In month seven the discount lapses and their invoice rises.
Is that expansion revenue? Nobody upgraded and no decision was made, yet the run rate genuinely increased. Whichever way you treat it, treat it the same way every time, including in the historical series.
What actually breaks in a homegrown MRR calculation
Rarely the code. What breaks is the agreement between decisions made at different times.
The dashboard gets built against your billing setup as it exists today. Then you add annual contracts. A second processor arrives with an acquisition. A usage-based component ships. You start selling in a second currency. Nothing errors. The dashboard keeps reporting confidently, using assumptions that stopped being true.
The other recurring failure is identity. The rule that decides whether one company holding five subscriptions counts as one customer or five was written once, by someone reasoning about the customers you had then, and is now quietly wrong for the customers you have.
Why you cannot tell when the number is wrong
This is the part that makes everything above expensive.
Normal software tells you when it breaks. Metrics code does not. A miscategorized reactivation throws no exception, fails no test, and pages nobody. It returns a plausible number that sits in a dashboard and gets read aloud in a board meeting.
Bugs in a checkout flow surface in hours, because customers complain. Bugs in an MRR calculation surface in months, and usually from outside: someone in diligence pulls your billing export, recomputes, and gets a different answer than your deck. At that point the disagreement has stopped being technical. You are defending your methodology in a room where credibility is priced.
The job you just hired yourself for
The weekend of building is the part everyone estimates. The job that starts on Monday is the part nobody does.
The decisions you now own
Every item in that grid is a policy you have adopted, whether or not you noticed adopting it. Owning the code means owning the answers, and being the person who has to defend them when the number is questioned.
An external system's definitions are external. That sounds like a small thing until an investor asks why your NDR is calculated the way it is, and the answer is either "this is how everyone calculates it" or "I decided in March".
Maintenance is really re-verification
The old maintenance argument was that someone has to update the code. That argument is weak now, because AI updates code fine.
The durable version is different. Every change to metric logic raises two questions code cannot answer. Is the new number right, and is it still comparable to the old one? Answering those takes ground truth and institutional memory, so it takes the two people with the least spare time: whoever owns finance, and whoever remembers why the logic was written that way.
When the answer comes back as "the old numbers were wrong", you inherit a restatement. History recomputes, prior reporting stops matching, and someone explains the discontinuity. That is governance, and it lands on people rather than code.
Who else needs to read the numbers
An internal dashboard gets built by one person, for one person's mental model. That works until other people need it.
Finance wants revenue by plan, excluding one enterprise account. CS wants retention for the Q2 cohort. Your CEO wants it on a phone, before a meeting. Each request is small, and each one routes back to whoever wrote the thing: individually trivial, collectively a standing queue nobody scoped.
Self-service is unglamorous. Saved segments, shared dashboards, role-based access, exports finance can reconcile. It is also most of what separates a tool an organization can use from a tool one person can use.
What happens when the person who built it leaves
The code keeps running. What leaves is the reasoning.
Why trials count from conversion date. Why that one enterprise account is excluded. Why the dunning window is 21 days. Their replacement inherits numbers they cannot vouch for and did not choose, and the usual outcome is that nobody touches the logic again, because nobody is confident what a change would break. The dashboard drifts further from how the business actually bills, and the drift is invisible.
What building actually costs
Under $120K ARR, ChartMogul is free, so building cannot save you money there. Past the free tier, Starter is about $708 a year for a single billing system, and Pro starts at $1,188 a year at $500K ARR.
So the real comparison is a weekend, plus the request queue, plus re-verification on every logic change, plus a migration later, against something in the low four figures a year. Sometimes that favours building. Less often than people assume, because the recurring costs are paid in attention rather than invoiced.
If you already have a data team
Above Series A the alternative usually looks different: a warehouse, dbt models, metric logic in version control, and Looker or Metabase on top, owned by people who do this for a living.
That setup deserves credit, and it genuinely fixes some of this. Decisions get documented in code review. Definitions live in git with history. Restatements happen deliberately, with a changelog. If that describes you, the silent-failure problem is largely solved.
What it does not change is either pillar. The billing complexity is identical: dbt does not know whether your expiring discount is expansion, and a reviewer approving the pull request is making the same judgment call an AI assistant made silently. And the job is still yours. The models need maintaining, the definitions still need defending to people outside the company, and your data team's time is now spent rebuilding proration rules that every subscription company has already solved identically.
Which is why the common resolution is neither. Keep a system of record for the revenue definitions, then pull from it into the warehouse and do the interesting work there. ChartMogul syncs both calculated metrics and normalized source data into Snowflake, BigQuery, Redshift, and cloud storage, and exposes the same data through an API, CSV, and a remote MCP server. Your warehouse still gets to be where the analysis happens. It just does not have to be the thing that decides what counts as churn.
When building your own is the right call
Two reasons hold up:
- Your revenue is not subscription-shaped. Marketplace take rates, pure usage billing, transactional revenue. A subscription analytics tool is the wrong instrument, whoever makes it.
- You need a metric nobody models. Something specific to your business, defined your way, that no standard definition covers.
One reason gets cited constantly and should not. Joining revenue to product usage, support load, or inference costs is warehouse work, and the sync above means you can have the standard definitions and the custom joins.
Two more expire. "Our billing is simple" and "we can eyeball the number" are true for most seed companies, and they stop being true. The exit is the cost. A script that works at 40 customers gets replaced around 400, and two years of homegrown history has to be reconciled against whatever you adopt. Import it and the numbers disagree with what you reported. Start fresh and you lose comparability through your most interesting growth period. Either way, someone explains a discontinuity in a board meeting.
Build for a durable reason. Building for a condition that expires is how teams end up paying twice, especially when the tool is free at the stage where that condition holds.
If you want to test the comparison rather than take it on faith, ChartMogul is free up to $10K MRR, and above that there is a 14-day trial with your own billing sources connected.