Your PLG motion is working, self-serve customers convert through Stripe, pay monthly, upgrade when they're ready. Billing is automated. Nobody thinks about it. Everything humming along.

Then, one day a sales rep shows up with a $200K annual deal. Custom credit pricing with committed spend with overage. Mid-quarter start date. Net-60 payment terms. Volume discount that tiers across the customer's organization.

This is a normal enterprise deal structure, but your billing system supports none of it.

I've been there myself, and I've watched this play out at a dozen AI companies in 2025 alone. The deal closes anyway (champagne emoji in Slack, a nice commission) - but billing and finance is stuck with the manual work. The billing team configures the custom pricing, finance builds the invoice and manual revrec in a spreadsheet. Someone calculates proration by hand. The customer's first invoice arrives, hopefully correct but very likely late.

This is the checklist I wish those companies had run before the deal closed.

If you're an AI company moving into enterprise sales, your billing system needs to handle five things before you sign the deal.

1. Custom pricing that doesn't require engineering

Your first enterprise customer won't want your standard pricing page rates. They'll want a negotiated rate card: different per-unit pricing, a committed spend discount, maybe a blended rate across multiple products.

At most AI companies, configuring this means an engineering ticket. Someone edits a config file or database entry. Half a day. No big deal.

When you hit 10 enterprise customers it starts hurting. 20 hurts more, and then at 30 it really really hurts. Each customer has their own negotiated rates. Each generating a 3-hour ticket when something changes. That's getting close to a full-time engineer doing pricing configuration instead of building product.

At the audiobook company where I worked before Solvimon, this is how the billing team grew to 14 engineers. It wasn't just one decision, but a series of small tasks that we needed to enable and support.

What "ready" looks like: A rate card engine where revenue ops can configure per-customer pricing without engineering. Negotiated rates, volume discounts, committed spend, all as configuration. The rep closes the deal, the commercial terms go live the same day.

At Solvimon, rate cards are configuration. Your commercial team manages them through the API or UI. Engineering builds the integration once. After that, custom pricing is an ops task.

2. Self-serve and enterprise billing in one ledger

This one sneaks up on you. It happened to me, and it'll happen TO YOU.

PLG billing is in Stripe. Automated, works, everyone's happy. Your first few enterprise deals get invoiced by hand because the terms don't fit Stripe's subscription model. Finance builds invoices in a spreadsheet or PDF template.

Now you have two billing stacks. Self-serve in Stripe, enterprise in Excel. Two data models. Two revenue streams. One finance team reconciling between them at month-end. The CRM says one thing, billing says another, the spreadsheet says a third.

By your 10th enterprise deal, this is a structural problem. It doubles your close cycle and creates reconciliation errors every month.

It gets worse when a self-serve customer wants enterprise terms. In most setups, you migrate them between billing flows by hand. Different system, different customer record, different data. That migration is where invoices get lost and customers get frustrated.

What "ready" looks like: One ledger for both motions. Self-serve through hosted checkout, enterprise with custom rate cards and committed spend. Same system, same customer record. A self-serve customer upgrades? Configuration change. Update the terms, apply the rate card. No data migration.

Solvimon was built this way. Kim and Etienne (our CEO and CTO) built Adyen's internal billing engine, handling merchants from single-store to global enterprise on one platform. The PLG-to-SLG path isn't a feature bolted on later. It's the architecture.

3. Mid-cycle amendments without a spreadsheet

I remember when our first really big enterprise customer signed a $200K annual deal. It took 2 months of negotiations, but then by the 3rd month they want to add a new product to the offering, increase their committed spend, and move 300 of their 5000 users to a higher tier.

It should've been an instant thing, but instead we got a whole cascade of issues:

• Prorate the existing plan for the remainder of the period

• Layer the new committed spend without resetting the billing cycle

• Credit the old terms and charge the new ones on the next invoice

• Adjust revenue recognition without breaking the rules

Our billing system struggled with mid-cycle amendments that didn't completely break the entitlements. If the billing system can't handle mid-cycle changes natively, each step is manual. Finance builds a spreadsheet. Engineering patches the subscription record. Eventually we did have to generate a set of corrective invoices to get the rev rec adjustments just right.

I've seen amendments that should take a day take three weeks. Not because anyone was slow. Because the system forced every change through a manual workflow.

What "ready" looks like: Amendments are an atomic/native operation. Proration calculated automatically based on your preferences, and revenue recognition adjusts itself. The system generates the amended invoice, not a person in Excel.

In Solvimon, mid-cycle amendments are configuration changes. Upgrade, downgrade, add products, change committed spend. The system recalculates. Finance reviews the output instead of building it.

4. Committed spend that works

"Committed spend with overage" is the most common enterprise deal structure in AI and for good reason!
It was also common in SaaS, but with AI you have even more reason to implement it. When a customer commits to $200K/year in usage and then go over - they pay overage at a negotiated rate. Go under, you keep the commitment. Everyone wins.

Simple to explain. Hard for most billing systems to implement.

I had to hack around it in Stripe multiple times, because the committed amount needs to draw down against actual usage. The drawdown rate might differ by product or model. Overage kicks in when the commitment is exhausted. The true-up at period end has to account for what was consumed, what was committed, and what was billed along the way.

Lots of billing systems model committed spend as a "feature flag" or entitlement on a subscription, or as a prepaid credit balance. Neither works long term. The feature flag doesn't track drawdown and the credit balance doesn't handle overage pricing that differs from the committed rate.

What "ready" looks like: Committed spend as a first-class billing concept. Committed amount, drawdown tracking, overage pricing, and true-up all part of the same billing relationship. Finance sees in real-time where a customer stands against their commitment. No tracking spreadsheet.

This connects to credit architecture. Your AI product uses credits with different burn rates across models (Gemini Pro 3 vs. Nano Banana 2 vs. ElevenLabs Scribe v2). Committed spend needs to track drawdown in credit terms, not dollars. That's a ledger design problem. Solvimon treats credits and committed spend as composable primitives, not bolted-on features.

5. Discount structures the data model supports

Your sales team will want to offer volume discounts that tier across an organization, annual commitment discounts with monthly billing, time-limited promotional pricing that reverts on its own, partner-specific margins, and bundle discounts across multiple products.

Standard commercial structures. Each runs into the same wall if the billing system was designed for flat-rate subscriptions.

The workarounds accumulate. Some discounts live in the billing system. Some get applied by hand at invoice time. Some exist only in the contract PDF, and someone has to remember to apply them monthly. Some are coded as one-time credits instead of pricing changes.

After a while, your sales team learns the system's limitations and designs deals around what billing can handle instead of what the customer needs. That's when you start leaving revenue on the table without knowing it.

What "ready" looks like: Discount structures in the billing system's data model, not in workarounds. Volume tiers, commitment discounts, time-limited promotions, partner margins, all configurable. A discount expires? It expires on its own. A customer hits a volume tier? The rate adjusts. Nobody has to remember anything.

The seat-based trap - they're a relic!

This is a bit of a a side note for AI companies, because if you're still on seat-based pricing, you have an additional problem.

Seat-based made sense when humans pushed buttons. One user, one unit of value. AI changes that. One person with AI agents can generate 50x the usage of a regular seat. An enterprise customer with 5 seats might consume more than a mid-market account with 50.

The commercial pressure to move to usage, credits, or hybrid pricing is real. Most AI companies will make this shift in the next 18 months.

The hard part is migrating your contracts is 10x harder than migrating your software. While your billing system might support usage-based pricing tomorrow, your existing customers are on seat-based contracts with annual terms.

Migrating them means renegotiating every deal - or at least communicating it well ahead. Customers on favorable per-seat rates won't want to switch. The ones being overcharged will.

You'll need both models running at the same time, in the same system, for the same customers, for years. If your billing infrastructure can't handle that, the pricing migration is blocked by billing.

Solvimon handles both in the same customer relationship. You transition customers gradually without parallel billing systems.

When to do this work?

The tempting answer is "later". I pushed this myself for about a year, but it only made things harder.

Two enterprise deals in the pipeline. Handle them by hand. Why invest now?

Because each manual deal raises the cost of fixing it later. Custom configs. Spreadsheet invoices. Manual reconciliation. Each becomes a dependency that's harder to unwind.

Your sales team is watching, too. Every deal that takes 6 weeks to invoice instead of 1 day teaches them to sell smaller, simpler deals. You're training your go-to-market team to avoid the deals that grow your business.

The best time to get billing ready for enterprise is before the first $200K deal. The second best time is before the tenth.

→ Building your enterprise sales motion and want help diagnosing? Reach out, I can share lots of anecdotes.