Aanchal Parmar
Product Marketing Manager, Flexprice
Ask 10 SaaS founders who own billing in your company and you'll get 10 different answers. Engineering says they built it. Finance says they need to trust it. RevOps says it touches their territory. The product says pricing decisions are theirs. Nobody says "I own it, here's the scope, here's what I'm accountable for."
That vacuum is the problem. Not the billing system or the pricing model. But the fact that nobody is the owner.
The companies we work with run into this constantly. A pricing change that should take a few days sits in a backlog for six weeks because the engineer who built the billing integration is on another project and nobody else has access to change the configuration.
A custom contract for an enterprise deal stalls because sales can't get a clear answer from either engineering or finance on what's actually possible. An invoice comes out wrong and the support ticket gets bounced between two teams for a week. Same pattern, every time.
The question of who owns billing sounds boring, I get it.
But it’s a fact that it determines how fast you can change pricing, how clean your revenue data is when the auditors show up, and whether enterprise deals close or stall on contract structure.
Why the question stays unanswered
Both engineering and finance have legitimate claims, and those claims conflict.
Engineering owns the technical integration. The event pipeline, webhook handlers, API connections. If something breaks, engineering is on-call. It's their infrastructure.
Finance owns the business outcomes. Revenue recognition, audit trails, invoice accuracy, tax compliance. When the CFO signs off on financials, she needs to trust that what the billing system recorded is what actually happened.
Neither can fully own it alone. Engineering doesn't have the business context to configure pricing correctly. Finance can't debug a webhook failure. So the default outcome is that neither team owns it fully, which means every team owns it badly.
That's the limbo state. Most SaaS companies are in it, usually without realizing it until something breaks badly enough to force the conversation.
What engineering actually needs from billing
Engineering's position isn't that they want to own billing. It's that they got stuck with it.
When billing was first built, it was an engineering project. Integrate Stripe, write the subscription logic, wire up the webhooks. That code lives in the codebase. So every billing question routes back to engineering, because that's where the system lives.
What engineering actually wants is a clean handoff. A billing system where pricing rules, plan definitions, promotional credits, and dunning sequences can be configured without a pull request.
Reliable infrastructure with idempotent event pipelines and dead-letter queues that surface problems before month-end reconciliation, not during it.
And a real contract: once a pricing model is live, changes to it come through a defined process, not a Slack ping on a Friday.
The complaint "billing takes too much engineering time" is almost never about the billing infrastructure itself. It's about not having a configuration layer that lets the business side make changes without opening a code review.
Every pricing experiment, every promotional credit, every plan rename routes back to engineering not because engineering built it wrong, but because the system was never designed to be operated by anyone else.
What finance actually needs from billing
Finance's position is equally legitimate and equally frustrated, just from a different angle.
They need to trust the numbers. Revenue recognition depends on the billing system correctly distinguishing recognized revenue from deferred revenue.
A customer who pays $24,000 annually in January and cancels in June needs to be recorded correctly.
This is not complicated in theory. It breaks constantly in practice when billing logic is split between code, Stripe configuration, and a spreadsheet someone built two years ago.
They need full audit trails. Every pricing change, every credit issued, every invoice adjustment needs a timestamp and the name of who made the change.
A system where anyone can make changes without logging them is a compliance problem waiting to surface at the worst possible time.
They need to move without filing tickets. When finance wants to run a promotion or set up a custom enterprise contract, the current state at most companies looks like this: write a spec, file a ticket, wait for sprint planning, review the implementation, find an error, iterate. Weeks pass.
Finance doesn't want to own the codebase. They want to configure business logic themselves without asking engineering for permission every time.
This is what finance autonomy actually means in practice: changing what customers are charged without touching code. Most billing systems aren't built for it. Which is why most finance teams are still filing tickets.
The 3 ways this usually goes wrong
Engineering owning everything works at Series A when the founding engineer who built billing knows all the pricing context in his head.
It breaks at Series B when that engineer moves to a different team and billing becomes a support burden with no clear owner.
Every pricing question ends up back in engineering's inbox. Every audit request too. Engineering resents it, the backlog fills up, and changes that should take two days take three weeks.
Companies are often surprised when they actually measure how much engineering time billing consumes, because nobody was tracking it. It's not a small number.
Finance owning everything works for pure subscription businesses where pricing rarely changes. It breaks the moment you add usage-based components or metered billing. Finance doesn't have the technical depth to manage that infrastructure.
They make configuration changes that break things they didn't know were connected, and the first sign is usually a customer calling about a wrong invoice.
The limbo state is the most common. Engineering nominally owns the technical layer. Finance nominally owns the business layer. Nobody owns the middle.
Every cross-functional billing question becomes a meeting to figure out who's responsible. Invoice discrepancies sit unresolved because neither team has clear accountability.
The middle is where most billing problems live, and in limbo, nobody's job is to fix the middle. The frustrating part is that both teams usually know something is wrong. They just can't agree on whose problem it is to fix.
The job that actually solves this
The function is called billing operations, and most SaaS companies don't build it deliberately. They go back to it when the pain gets bad enough.
GitLab's public job ladder documents a Billing Operations function inside their Revenue Accounting group. The roles run from Billing Operations Intern through Associate, Analyst, and Manager, up to a Global Process Owner function.
The scope is explicit, own the billing system configuration, own the reconciliation process, own the audit trail, own the relationship between what the billing system says and what the financial statements say.
This is the missing piece. Billing ops owns the middle layer: configuration, reconciliation, contract setup, dunning rules, credit grants. Engineering still owns the infrastructure. Finance still owns the financial outputs. Billing ops owns the space between them where most billing problems actually live.
When this function exists, pricing changes route through billing ops, who have the access and the context to implement them correctly.
Audit requests route through billing ops, who have the trail and the documentation. Engineering gets a clean contract: the billing system infrastructure is yours, the business logic configuration is not your problem.
"Billing operations manager" gets about 150 monthly Google searches with almost no ranking competition. Nobody's writing about this function because companies figure it out by accident. By the time they formalize it, the damage from the limbo state is already done.
What this looks like at each stage
Pre-seed and seed: founders handle billing. This is fine. There's nothing material to manage.
Series A, roughly $1M to $5M ARR: you don't need a dedicated billing ops hire yet, but you need explicit ownership. Usually one person, often a RevOps generalist, whose scope includes making sure billing is clean and finance can trust the numbers. The mistake is leaving it as shared responsibility between engineering and finance with no single person accountable.
Series B, $5M to $20M ARR: this is where the limbo state starts costing real money. You have enough customers that billing errors are material. You have enough pricing complexity that engineering is spending meaningful time on billing support. The right hire is a dedicated Billing Operations Manager. Not RevOps who also handles billing. Someone whose primary job is billing system ownership.
Series C and beyond: a team. GitLab's model is the reference here. Multiple analysts, a manager, a Global Process Owner function that sets standards across the company. At this scale, billing ops interact with sales ops, legal, finance, and product regularly. It's a function with a headcount, not a hat someone wears.
Most companies delay the Series B hire until Series C. By then the technical debt is real, the limbo patterns are baked in, and migrating to a billing system that actually supports billing ops ownership is a multi-quarter project. It's not impossible. It's just a lot more expensive than it would have been a year earlier.
If you're already in limbo
The sequence matters here because there's a failure pattern worth knowing about.
1. Don't hire a billing ops person before your billing system can support them.
If the system has no configuration layer, the new hire ends up doing what finance has always done: filing tickets with engineering. You've added headcount without changing anything structural. The same problems recur, now with an additional person frustrated about it.
2. Start with an audit
Two weeks to understand where billing actually lives today: what's in code, what's in configuration, where the audit trail has gaps, where reconciliation breaks.
Teams that skip this step hire a billing ops manager and then spend the first three months discovering what should have been documented before the hire.
3. Write down the handoff contract
What does billing ops own without engineering involvement? What changes require engineering? If this isn't written down, the ambiguity that created the limbo state in the first place just moves to a different level.
4. Then get the right billing infrastructure in place
Finance autonomy requires a system built around configuration layers, not code changes.
If updating a pricing rule in your current system requires a pull request, the billing ops model won't work regardless of who you hire. The infrastructure has to match the operating model.
Then make the hire. In that order.
The cost that doesn't appear anywhere
The visible costs are the ones that make it into post-mortems: the failed audit, the pricing change that took three months, the enterprise deal that stalled on contract structure.
The invisible cost is what never gets proposed. The pricing experiment nobody raised because everyone knew it would take months.
The enterprise deal structure sales didn't offer because they knew the billing system couldn't support it. The usage-based tier that stayed on the roadmap for two years.
Those don't show up as failures. There's no post-mortem for revenue that was never proposed. It just doesn't exist.
We're at $2M ARR. Do we actually need a billing ops function?
Our engineering team says billing changes take two weeks. Is that normal?
What's the difference between RevOps and billing ops?
How do we know if our billing system can actually support a billing ops model?
What goes in the handoff contract between engineering and billing ops?
