Tell me if this is familiar:

Your self-serve motion is humming and Stripe is doing its job. PLG revenue is growing.

Then the board says: "Go upmarket".

So you hire a CRO (or you are one!), and with that come enterprise reps. They start working six-figure deals. And within 90 days, the best closer on the team is spending more time fighting the billing system than closing prospects.

I've seen this at SaaS companies myself - and I don't think it is a sales execution problem. It's what happens when you run two revenue motions on two separate billing stacks and we keep pretending a spreadsheet in the middle is "good enough"

A CRO's monthly reality

Say a prospect comes inbound through the PLG motion. They've been on a self-serve plan for three months. Usage is growing. The account exec qualifies them for enterprise. Great - this is exactly the motion you designed!

Then the quoting starts.

The enterprise deal needs annual commits, team-level credit pooling, custom overage rates, and net-60 terms.

None of that exists in Stripe (and you're very welcome to double-check me).

So the AE opens a ticket with finance to manually "fix" the account with credit notes or with a bypass. You sort out the entitlements and maybe how credits will work across the org with some engineers.

Two weeks pass. The champion goes cold. The deal slips.

Meanwhile, the CRO is looking at a pipeline report that says "closed lost: went dark".

This happens because the PLG billing stack and the SLG billing stack don't talk to each other. And for the CRO, that gap isn't an annual audit problem, but a monthly quota problem.

The split stack

Most companies that add enterprise sales on top of a PLG motion end up with something like this:

1. PLG runs on Stripe (or a similar self-serve billing tool). It handles sign-ups, usage metering, credit card charges. It works well for what it was built for.

2. SLG runs on HubSpot (or Salesforce CPQ), or more realistically, a combination of CRM fields, Google Sheets, and Slack threads.
   Custom contracts get quoted manually. Pricing logic lives in someone's head or worse, in a spreadsheet that 3-5 people maintain.

Then, finance lives in the gap between both. They manually reconcile self-serve revenue (from Stripe) with enterprise revenue (from invoices they built by hand).

The PLG-to-enterprise upgrade path (the one the board wanted you to build) quietly dies.

Fix it with more people, why don't you

The instinct is to fix it with process and throwing more people at the problem. Hire a deal desk. Add a RevOps person. Build better templates. And that helps for a while. But it's treating the symptom.

The root cause is architectural. When you launched PLG, you built billing v1: Stripe, a product database, a self-serve portal. It was the right call. Simple pricing, credit card payments, instant activation. Perfect for that stage.

But enterprise billing has different requirements. Commits. Multi-year terms. Credit pooling across seats. Overage thresholds. Rate cards that vary by customer. Net terms. None of these are "features" you can bolt onto a self-serve billing stack without significant engineering work.

So companies build a second system alongside the first. Or they adopt a CPQ tool that doesn't connect to the product. Or they hire engineers to write custom orchestration code that bridges both worlds.

This is the orchestration tax. Whether you built self-serve on Stripe or homegrown, the moment you add an enterprise motion, you're writing glue code. And that glue code becomes the most fragile, most expensive, least documented system in your entire stack.

A pattern we've seen repeatedly:

• 80% of billing complexity ends up maintained by engineers.

• The remaining 20% falls to financial controllers handling edge cases manually.

But when you mix PLG and SLG, that ratio flips for the sales team. Suddenly the majority of their deals have some non-standard element which is a committed spend, a custom discount, a credit rollover from the self-serve plan. And every one of those requires manual intervention.

What "one ledger, two motions" actually means

The companies that run PLG and SLG without the split stack pain have one thing in common: pricing logic lives in one place.

Self-serve customers and enterprise customers hit the same ledger. The experience is different, as one gets instant checkout while the other gets a negotiated contract.

Yep, the underlying infrastructure is shared! Credits purchased through self-serve and credits allocated through an enterprise commit draw from the same wallet system. Usage metering feeds one source of truth. Rate cards are configuration, not code.

This matters practically in three ways:

1. The upgrade path works. When a PLG customer is ready for enterprise, you don't migrate them between systems. You change their contract terms in the same ledger. Their usage history, credit balance, and billing relationship carry over. The AE can quote in minutes because the pricing engine already knows the customer.

2. Finance closes faster. One system, one revenue number. No reconciliation between Stripe exports and manual invoices. No "which spreadsheet has the real number" conversations at month-end.

3. The CRO's team sells instead of filing tickets. Custom pricing becomes a configuration change, not an engineering project. The AE adjusts a rate card, applies a commit, sets net terms all without waiting for someone to build it.

Credits are the architectural bridge here. In a unified system, credits aren't a pricing gimmick. They're a ledger primitive. Self-serve customers buy credits on-demand. Enterprise customers get committed credit pools. The product consumes credits the same way regardless of how they were purchased. Upsell from PLG to SLG is a commercial conversation, not a technical migration.

The cost of waiting

Companies tend to tolerate the split stack until something forces the issue. An enterprise deal big enough to justify the pain. An audit that exposes the reconciliation gap. A CFO who realizes they can't report blended margins because PLG and SLG revenue live in different systems.

By then, the orchestration code is deeply embedded. Two or three engineers are maintaining it. Deal velocity has slowed so gradually that nobody can pinpoint when it happened. The CRO has hired a deal desk to manage the manual quoting process and accepted it as "how enterprise sales works."

It doesn't have to.

Yapily had 200+ bespoke pricing plans and was drowning in manual invoicing. After unifying their billing infrastructure, manual invoicing dropped 98%. SEON managed 700 pricing plans in a single spreadsheet. In the first month after migration, finance identified 10% revenue leakage that had been invisible in the gap between systems.

The pattern is consistent: companies that unify PLG and SLG billing close faster, leak less revenue, and most importantly actually convert self-serve customers into enterprise contracts.

Your CRO's pipeline isn't the problem.

The spreadsheet between your two billing stacks is.