Ask five people in your company where pricing lives, and you'll get six answers.

Move to another company, and the answers change again.

Sales says the CRM. Finance says the ERP. Product says the codebase (what?), the CEO says "we'll figure it out next quarter" - and then someone in RevOps maintains a Google Sheet that everyone pretends doesn't exist because it's not shared widely.

This question has three layers, and most companies haven't solved them.

Layer 1: Where does the pricing role sit?

Pricing can report to Sales, Product, Finance, Marketing, or Strategy. I've sat in several of these chairs.

At one company, I owned pricing as a PM. That worked for PLG. I could run experiments on tier limits, test upgrade flows, and ship changes without a committee. Once sales got involved and deal sizes crossed into six figures, pricing moved to the CRO and needed board approval for structural changes. The speed dropped from weeks to quarters overnight.

At a B2C company, pricing was set by marketing and individual country managers. That made sense because willingness to pay varied by market and local teams had the context to adjust.

At another org, there was no pricing function at all. Every deal was bespoke. Sales reps quoted whatever they thought they could close. Finance discovered the margin impact at month-end.

Each of these made sense for the company's stage and motion. The problem is when the motion changes and the ownership doesn't.

Really, it doesn't matter where pricing reports to if no one can make a decision about pricing (I've been there too for a while)…

You need Sales, Product, Finance, and Marketing with defined input roles, and one clear decision maker per pricing change. You use a RAPID or RA(S)CI framework, where you define who has input, who recommends, and who decides. It changes by decision type: a tier limit tweak doesn't need the same governance as a full pricing restructure.

I've also seen a 12 person committee with PMs, PMMs, revenue, sales, and marketing where some people had veto power - and it produced a big mess where nothing changes. I've watched (again, personally) companies run meeting upon meeting where we debate whether to raise the Pro tier by $2/month, or if the price should end in ".99" or ".00" and then table the decision because a PMM wanted to test it out first before committing to anything and half a year later we were at the same place with the same price and the same complaints.

Layer 2: Where does the pricing logic live?

This is the "systems question", and it's where things get a bit unclear.

In the PricingSaaS community I follow, a billing infrastructure expert asked a straightforward question: where does your product catalog live?

But it wasn't super clear what the answer should be and the product catalog is pricing's homeless problem. It couch-surfs (is that still a thing?) between Stripe, Salesforce, NetSuite, your application database, and at least one Google Sheet that someone on the finance team swears by.

You can survive this when you sell one product at one price through one motion. That era ended. Today you're running platform fees + usage + credits + enterprise custom deals, selling both self-serve and sales-led, adding AI features with variable compute costs. Every pricing change touches five systems.

Vercel seems to be shipping about six pricing changes per month - so if you imagine someone trying to do that with the messy systems… Oof.

My experience is that two mistakes create the mess:

1. Hard-coded entitlements. Plan IDs scattered through your codebase in if (planId == Enterprise) blocks. Every pricing change requires a deploy. What starts as a small convenience becomes structural debt that blocks your roadmap.

2. Multiple catalogs with no owner. The CRO looks at the CPQ. The CFO looks at the ERP. The CTO looks at the database. Each has a different version of what the customer bought and what they owe.
   One company I know spent almost 9 months launching a single new tier, where another killed an add-on initiative because the cross-system coordination cost more than the expected revenue.

Pricing logic should live in one place ideally - one catalog, with one set of entitlement rules. One source of truth that sales, finance, product, and engineering all read from. When you change a price, it propagates everywhere without a deploy, without a Linear or Jira ticket, without three teams reconciling their spreadsheets.

That place should also be the billing system.

Layer 3: Where does your pricing strategy live?

This is the layer often neglected, because very few actually understand what pricing strategy is. Someone picks a model (seats, usage, credits), set a price, and revisit it when a competitor forces their hand or a board member asks a question that sends everyone in all directions.

Steven Forth published a framework that makes the problem concrete. He maps pricing along two axes: price elasticity of demand (how sensitive the market is to your price changes) and cross-price elasticity (how much a competitor's price move pulls your customers). Which quadrant you're in determines whether you should optimize, differentiate, defend, or restructure.

Lots of B2B SaaS companies sit in the low-elasticity / low-cross-elasticity quadrant where customers are sticky, switching costs are high, and value-based pricing kinda works. You compete on value, not price. You win by understanding what your product is worth to each customer segment and capturing a fair share of that value.

But AI is moving markets between quadrants because when inference costs are a huge proportion of the delivery cost (I've seen 90% last week) and seats don't capture the value an AI agent produces, the old assumptions are inappropriate.

A company that felt safe on per-seat pricing discovers that a credit-based competitor is capturing value they're leaving on the table. Even worse, if your market shifts into the high cross-price elasticity zone without you noticing, a competitor's price cut can trigger a race to the bottom that destroys value for everyone. The game theory answer (tit for tat with forgiveness) only works if you're tracking the dynamics in the first place.

Credit-based pricing is one response, and it's growing fast (126% YoY growth in credit models per PricingSaaS data). But credits done poorly are worse than seats done well. The design choices matter:

• How do you define the credit unit?

• What happens when an agent run fails mid-execution?

• Do unused credits roll over or become stranded assets that erode trust?

• Can teams pool credits or are they locked to individual users, leaving power users hitting limits while casual users sit on unused balances?

These are pricing architecture decisions. They shape margins, expansion revenue, and customer trust. And they need a home, because they shouldn't be scattered across a Notion doc, a pricing committee's shared drive, and tribal knowledge in the head of your CPO or CRO.

Where they all meet up

The three layers interact, naturally.

If your pricing role reports to Finance but your pricing logic lives in Product's codebase, every change requires a cross-functional negotiation. If your pricing strategy calls for rapid experimentation but your catalog is fragmented across six systems, experimentation is an engineering project, not a business decision.

Companies that move fast on pricing have converged all three. They have a clear owner with a mandate and a decision framework. Their catalog, entitlements, metering, and billing share one schema, so a pricing change is a configuration update, not an engineering project. And they run pricing as a continuous loop: customer data in, hypothesis out, test, learn, adjust.

Pricing is not a number you set once. It's an architecture you build and an organization you staff.

Three questions for your next pricing meeting:

1. Who can change a price without escalating to the CEO?

2. How many systems need to be updated when that price changes?

3. When was the last time you tested a pricing hypothesis and measured the result?

If you don't like those answers, that's where the work starts.