You Can Vibe Code Billing Features. You Can't Vibe Code Billing.
How healthy is your quote-to-cash?
12 questions on pricing, renewals, billing and reporting. Takes two minutes.
Take the assessmentAI has made writing billing code nearly free. It has not made being wrong about revenue any cheaper.
A team with a good coding assistant can build a working checkout, a plan table, a Stripe webhook and an MRR chart in a weekend. That part is real, and this post doesn’t argue otherwise. The argument is about what comes after: billing for B2B SaaS is not a handful of features but more than twenty-five capabilities that all act on the same contracts, and the cost lives in how they interact.
The expensive parts of billing were never typing the code. They are knowing what the code has to do, proving it is right, and keeping it right as pricing, contracts and rules change. Vibe coding removes the first cost and leaves the other three with your team, permanently.
What vibe coding gets right
Day-one billing is genuinely easy to build. If every customer picks a public plan, pays by card and never negotiates, the whole system is a lookup: which plan is this customer on? A coding assistant will produce that quickly and it will work.
The trouble starts with the second quote. The upsell six months in, the mid-term tier change, the renewal with a price increase and two add-ons bought at different times. None of those are built from a blank page. They are built on top of everything the customer already has and everything that has happened to it since the first signature.
That history is the product. A prompt can describe the first invoice. It can’t describe requirements you haven’t discovered yet, and in billing you discover them one contract at a time.
The real scope: twenty-six capabilities, not one
Every capability below looks like a weekend task when described in one line. The right-hand column is what it has to handle once real B2B contracts arrive.
| Capability | What the prompt says | What it actually has to handle |
|---|---|---|
| Custom pricing | Let sales set a price | Per-subscription prices on top of a governed catalog, so a negotiated deal doesn’t create a one-off product that pollutes the catalog and every report built on it |
| Discounts | Apply a percentage | Line-level vs. deal-level, fixed vs. percentage, time-limited discounts that expire at renewal, approval thresholds by size, and correct allocation in rev rec |
| Add-ons | An extra line item | Own term or co-termed to the plan, dependencies on the base plan, what happens when the base plan changes or is retired |
| Ramps | Different price in year two | Step-ups on schedule across multi-year terms, ramps on individual line items, amendments mid-ramp, contracted ARR vs. current MRR on the same day |
| Usage-based charges | Multiply quantity by price | Event ingestion and deduplication, tiered and volume pricing, minimums and commitments, prepaid credits, overage, late events after an invoice is final |
| Multi-currency | Store a currency code | Price books per currency, which exchange rate and when, credit notes and refunds in the original currency, reporting MRR in one currency |
| Quoting | Pick products, send for signature | Only catalog products, approval workflows, e-signature, quotes for existing customers built from the live subscription, the signed quote becoming the subscription with no re-keying |
| Self-service | An upgrade button | The same pricing, proration and approval rules as sales-led changes, enforced without a human in the loop |
| Amendments | Change the subscription | Effective dating (including backdated and future-dated), connection to the original contract, pending changes, history that later quotes depend on |
| Proration | Charge for the partial period | Day vs. month basis, upgrades vs. downgrades, several charges changing at once, usage tiers mid-period, rounding on money, and a quoted amount that matches the invoice to the cent |
| Renewals | Extend the end date | Notice windows, contractual uplifts and CPI, expiring discounts, grandfathered prices, co-terming add-ons bought at different times, renewing onto a plan you no longer sell |
| Credit notes | Reduce an invoice | Which lines, applied forward vs. refunded, tax reversal, sequential numbering per legal entity |
| Refunds | Return money | Partial vs. full, to which payment method, effect on rev rec and metrics, refunds touching a closed period |
| Revenue recognition | Spread revenue over the term | ASC 606 / IFRS 15 allocation across bundled items, ramps, usage, amendments that re-allocate, credits and refunds in closed periods |
| SaaS metrics | Sum active subscriptions | Classifying every change as new, expansion, contraction, churn or reactivation; MRR/ARR bridges; NRR and GRR that reflect what actually happened, not what the data model assumed |
And the ones teams forget to scope
These rarely make it into the first prompt. They are often harder than anything above.
| Capability | What the prompt says | What it actually has to handle |
|---|---|---|
| Tax | Add sales tax | Nexus by jurisdiction, VAT/GST and reverse charge, exemptions, tax on discounts, credit notes and refunds, rates that change mid-term |
| Invoicing and payment terms | Email a PDF | Net 30/60, purchase order numbers, a paying entity separate from the invoice recipient, consolidated invoices across subscriptions, sequential numbering per legal entity |
| Account hierarchies | A customer record | Parent and child accounts, who gets billed vs. who uses the product, rolling metrics up the tree, co-terming across subsidiaries |
| Multiple legal entities | One company | Your own entities in different countries, each with its own currency, tax registration, invoice numbering and books |
| Dunning and failed payments | Retry the card | Retry schedules, notification cadence, grace periods, suspension and reinstatement, involuntary churn vs. voluntary churn in metrics |
| Entitlements and provisioning | Unlock the feature | Access that changes the moment a contract is signed or amended, usage limits, and drift between what is contracted, billed and actually provisioned |
| Catalog versioning and price changes | Edit the price | Grandfathering, old plans that existing customers stay on, rolling new pricing across the installed base at each renewal |
| Cancellations and terminations | Set status to cancelled | End of term vs. immediate, early termination fees, notice periods, partial cancellation of add-ons, correct churn classification |
| Trials and conversions | Free for 14 days | Paid pilots, trial-to-paid conversion mid-period, extending trials, whether a conversion counts as new business |
| CRM sync | Push deals to billing | Which system owns which field, closed-won creating the subscription, amendments flowing back, never overwriting what finance set on purpose |
| Audit trail | Log changes | Who changed what, when and why, on every price, discount, approval and amendment, in a form an auditor accepts |
The complexity is in the interactions
Twenty-six capabilities are not twenty-six problems. They are twenty-six problems plus every combination of them, because they all act on the same contract.
A system built one prompt at a time tends to get each capability right in isolation and the combinations wrong, because nobody prompted for the combination.
A normal year for one customer
A customer signs on January 1: a Pro platform fee at $24,000 a year plus 50 seats, billed annually. In March they add 10 seats, co-termed. In April you raise list seat prices and grandfather existing customers. In May you launch an Enterprise tier at $36,000 a year.
On August 1 they move to Enterprise and add 25 seats. The quote has to credit five unused months of Pro ($10,000), charge five months of Enterprise ($15,000), decide whether the 60 existing seats keep the grandfathered price through a tier change, price the 25 new seats, and co-term everything to December 31. Then the renewal four months later has to know all of it.
None of this is exotic. It touches custom pricing, add-ons, amendments, proration, quoting, renewals, rev rec and metrics at once.
Combinations that show up every week
| Scenario | Capabilities involved | What has to agree |
|---|---|---|
| Mid-term upgrade in EUR with a co-termed add-on, on a contract with a renewal uplift | Amendments, proration, multi-currency, add-ons, renewals | The quote, the invoice, the rev rec schedule, and whether MRR records expansion |
| Self-service downgrade on a ramped contract | Self-service, ramps, proration, refunds or credit notes, rev rec | Whether the customer gets a refund or a credit, and whether revenue already recognized in a closed month is reversed |
| Renewal of a customer on a retired plan with a grandfathered price in AUD | Renewals, custom pricing, multi-currency, quoting | What the catalog says they renew onto, at what price, and how the change is classified |
| Usage overage on a contract with a time-limited discount and prepaid credits | Usage-based charges, discounts, credits, invoicing, rev rec | Which credits are consumed first, whether the discount applies to overage, and when revenue is recognized |
| Billing dispute settled with a credit note on a multi-year deal | Credit notes, ramps, rev rec, metrics | Which year’s revenue is reduced and whether NRR shows contraction |
Each row is routine for a sales-led SaaS company. Each one has to be correct in every system that reads the contract, at the same time.
Why billing is different from other software you might build
Plenty of internal tools are fine to vibe code. Billing has five properties that make it a poor candidate.
1. Billing errors are silent
Most software fails loudly: a crash, a broken page, a ticket. Billing fails quietly. A customer who is undercharged never reports it. A misclassified upgrade shows up as churn plus new business, and NRR is wrong for quarters before anyone notices. Vibe-coded systems tend to be validated by checking that output looks right, which is exactly the test billing errors pass.
2. The numbers get audited
Revenue recognition, investor reporting, fundraising diligence and an acquirer’s quality-of-earnings review all depend on billing data. Auditors expect consistent, explainable treatment across every contract. Revenue data you can’t defend costs most at the moment it matters most: when someone is deciding what your company is worth.
3. The hard parts are correctness properties, not features
Idempotency when a request is retried. Two usage events spending the same balance at once. Rounding on money. Period boundaries and time zones. Events that arrive after an invoice is final. An immutable ledger that replays to the same balance. A quoted amount that matches the invoiced amount. None of these appear in a feature description, so none of them appear in a prompt unless someone who has been burned by them writes it.
4. Billing is never finished
Every pricing change, new product, tax rule, CRM field and new contract term touches billing. Pricing changes hurt most, because every subscription created under old pricing still has to quote, amend and renew correctly. Building billing means signing up to maintain it for as long as you sell anything. It also raises a practical question: who owns it when the person who prompted it leaves?
5. It’s many systems that have to agree
Catalog, quoting, approvals, subscriptions, invoicing, payments, tax, rev rec, metrics, customer portal, CRM. Every seam between them is a place where the contract and the invoice can drift apart. Systems built incrementally tend to grow seams faster than they close them.
What AI changes, and what it doesn’t
When code gets cheap, value moves to the things code generation doesn’t produce: the specification, the test suite, and the accumulated edge cases.
We use AI to build Bunny too. The difference isn’t who types the code. It’s what sits around it:
- A specification shaped by real contracts. Years of amendments, renewals and rev rec edge cases that broke something, each now a rule the system follows.
- Dedicated testing for billing correctness. Bunny has test engineers whose whole job is proving that quotes, invoices, rev rec and metrics agree. A homegrown system usually has whoever has time this sprint.
- Fixes that compound. When an edge case surfaces for one Bunny customer, it is fixed once for every customer. In a homegrown system, each company discovers each edge case on its own, usually in its own revenue.
The same logic applies to teams building software with AI agents end to end. An agent assembling a SaaS product shouldn’t generate its own database or payment processor, and it shouldn’t generate its own billing either. It should choose a component that has already been proven against real contracts.
There is one more reason that matters now. AI features on top of billing, such as renewal-risk scoring, discount anomaly detection and forecasting, are only as good as the data underneath. A billing system that grew one prompt at a time rarely produces data clean enough to trust them.
When building your own is fine
If your pricing is uniform, self-serve and card-based, and nobody negotiates, you don’t need a dedicated B2B billing platform or a homegrown one. A general-purpose tool like Stripe Billing handles that well.
The argument in this post applies once any of these are true:
- Sales negotiates price, terms or bundles.
- Contracts run longer than a year, ramp, or get amended mid-term.
- Customers pay by invoice on net terms rather than by card.
- You mix recurring and usage-based charges.
- Revenue recognition or board metrics have to stand up to an auditor or investor.
At that point the question isn’t whether you can build billing. It’s whether you want to become a billing company alongside the company you’re already building.
Questions to answer before you build
If your team can answer these with confidence, and has the capacity to keep answering them as pricing changes, building may be reasonable. If not, the work is still coming; it just arrives later and costs more.
- How does your system quote a mid-term tier change on a grandfathered price, and does the quote match the invoice to the cent?
- Is an upgrade onto custom terms recorded as expansion, or as churn plus new business?
- What happens when two usage events spend the same balance at the same moment?
- How is a credit note on a ramped, multi-year deal reflected in rev rec and NRR?
- How do you renew a customer onto a plan you no longer sell, in a currency other than your reporting currency?
- Can you show an auditor why every contract was recognized the way it was?
- When you change pricing next year, what has to change in quoting, renewals and metrics, and who does it?
- Who owns billing when the engineer who built it leaves?
About Bunny
Bunny is billing and quoting built only for B2B SaaS. Catalog, quoting, approvals, subscriptions, amendments, renewals, usage-based billing, revenue recognition and SaaS metrics all work from the same contract data, so the interactions described above are handled by one system rather than stitched together.
If you run Stripe Billing today and want to see how your own subscriptions, renewals and metrics would look through that lens, Sidecar connects to your Stripe account read-only and shows you before you change anything.
Billing that handles your pricing model
Recurring, usage-based, tiered, banded or hybrid — Bunny bills it without a rebuild, and recognises the revenue automatically.
