Blog

CPQ and Billing: What Each System Should Own in SaaS

Two colleagues in an office arranging colourful sticky notes on a glass wall

Author: Ethan Garonzik, CEO & Founder of Vendori

“It’s just a small change to the contract.”

Add a product halfway through year two. Give it a different start date. Co-term it with the existing agreement. Keep the negotiated ramp and annual uplift intact.

Oh, and the renewal is already created.

Sales wants to know when the quote will be ready. Finance needs to know what to invoice. RevOps is figuring out which records can be changed without breaking something else.

This is where the relationship between CPQ and billing gets tested.

An integration can move data between systems. Your team still needs to decide which system defines the agreement, which applies the charges, and what happens when the customer changes their mind.

Without those decisions, RevOps becomes the person who explains what the customer actually bought.

What is the difference between CPQ and billing?

CPQ helps Sales build, price, approve, and quote a deal. Billing uses the agreed terms to calculate charges, issue invoices, and manage payment activity.

In a SaaS business, CPQ might structure a three-year subscription with different quantities and prices each year. Billing needs to charge the right amount for each period, on the agreed schedule.

The phrase “CPQ billing” generally refers to the connection between these functions or software that provides both. They can share a platform while still having different responsibilities.

Here’s a practical way to divide the work:

Function

CPQ should handle

Billing should handle

What must stay aligned

Product configuration

Products, options, and valid bundles

Billable items and charge types

Product identifiers and bundle components

Deal pricing

Negotiated rates, ramps, and discounts

Charges calculated from agreed pricing

Amounts, units, pricing periods, and dates

Approvals

Pricing and commercial exceptions

Invoice adjustments and credits

Approval history and reasons for changes

Invoicing

Agreed billing terms and schedules

Invoice generation and delivery

What was agreed versus what is charged

Payments

Agreed payment terms

Collection through payment systems

Payment status and outstanding balances

Amendments

Proposed changes and their approval

Resulting charges, credits, and schedule changes

The updated agreement

Usage pricing

Negotiated rates, commitments, and allowances

Usage charges and invoicing

Usage definitions and applicable rates

Renewals

Proposals based on the current agreement

Billing and usage history

Changes that affect the next term

These are responsibilities, rather than requirements for separate products. Some platforms cover several functions. Others use a separate subscription or contract system to maintain the ongoing agreement.

Our Quote-to-Cash Gap article covers the broader process and its common failures. Here, the question is more specific: which system gets to decide what?

Where should pricing logic live?

CPQ should apply or retrieve approved pricing when the deal is built. Billing should calculate charges using the terms the customer accepted.

That doesn’t mean billing cannot calculate prices. Usage charges, prorations, and scheduled increases all require calculation. The important distinction is between applying an agreement and making a new commercial decision.

Suppose a customer negotiates:

  • A $40,000 subscription in year one.

  • A $50,000 subscription in year two.

  • Annual invoicing in advance.

  • A discount that expires after the first year.

Billing needs those periods, amounts, and conditions. A two-year total won’t tell it when the discount ends or which amount belongs on each invoice.

Problems arise when the same agreement gets rebuilt independently in both systems. Someone enters the discount in CPQ. Someone else recreates it in billing. Later, one changes and the other doesn’t.

Now Finance has to determine which version is correct.

Can pricing come from a shared engine?

Yes. Some architectures use a shared pricing service or a billing-native catalog that CPQ also uses. Others manage negotiated pricing in CPQ and pass the accepted terms downstream.

Either approach can work. The requirement is that the same approved rules and versions apply wherever the calculation happens.

The question to ask a vendor is:

“When this price changes, where do we update it, and how do we know every affected system is using the right version?”

Can CPQ and billing use different product catalogs?

Yes, as long as the connection between them is explicit and maintained.

Sales might quote a package containing a platform subscription, premium support, and implementation. Billing may need three separate charge records.

That’s a reasonable difference. The trouble starts when the systems cannot reliably connect those records.

Product identifiers, bundle components, quantities, and charge types need clear mappings. Older products and pricing also need to remain usable for customers who still have them.

A product can be unavailable for new sales and still belong to an active agreement.

If retiring it from the catalog makes that agreement impossible to amend, RevOps inherits another workaround.

During evaluation, ask the vendor to amend a subscription containing a retired product. It’s a better test than building a new quote using the latest catalog.

Which system should own amendments?

The selling process should define and approve the change. The contract or subscription record should retain it. Billing should apply the financial effect.

Depending on the platform, CPQ may support all the commercial steps or send the accepted amendment to a separate subscription system.

What matters is that the change survives beyond the quote.

Editing an invoice may fix the next charge. It does not necessarily update what the customer owns, when it ends, or what should renew.

Likewise, an approved amendment sitting in CPQ has not finished its job if billing continues charging the old amount.

Follow one “small change” through the systems

A customer has a three-year platform agreement with scheduled price increases. They want to add a product halfway through year two, ending on the same date as the existing agreement.

The add-on has its own negotiated price. A renewal proposal is already open.

Here’s what needs to happen.

First, define the change clearly.

The amendment must record the add-on’s quantity, price, start date, and end date. It also needs to establish which existing terms apply.

An annual increase on the platform should not automatically apply to the new product unless that was agreed.

Next, update the ongoing agreement.

Once approved and accepted, the change needs to update the contract or subscription record that future amendments and renewals will use.

If a rep has to create an “expansion” just to change an end date, the workaround may get the quote out. It can also leave someone explaining the transaction later.

Then, apply the billing effect.

Billing calculates the charge for the remaining period using the agreed proration method and invoice timing.

If the effective date falls in a period already invoiced, the process must determine whether the customer needs an additional invoice, a credit, or a future adjustment.

Finally, reconcile the renewal.

The renewal proposal was created before the add-on existed. Does it now include the product? Is the quantity correct? Which price and uplift apply?

The process should update the proposal through controlled rules or flag it for review. An accepted future renewal requires an authorized change process rather than a silent overwrite.

For more on structuring these transactions, see our guide to CPQ amendments and co-terming.

An invoice total cannot explain every commercial change

Finance and RevOps also need to distinguish a price increase from additional products or quantities.

That distinction matters when expansion and uplift receive different treatment in reporting, quota retirement, or commissions.

A higher invoice does not, by itself, explain why the customer is paying more.

Preserve the details of the change so reporting and compensation rules can classify it consistently. Otherwise, teams end up debating the transaction after the deal has closed.

What should a CPQ billing integration exchange?

Send enough structured information for billing to apply the agreement without someone reading the contract and rebuilding it.

The data may pass through CRM, order management, or a subscription platform. Regardless of the route, it should answer four questions.

1. Who is being billed?

Include the customer and billing account identifiers, billing contact, currency, and relevant legal entity.

The company buying the software and the entity receiving the invoice are not always represented by the same record.

2. What did they buy?

Include product identifiers, quantities, units, bundle components, and references to the relevant contract, subscription, order, and amendment.

These references let teams connect an invoice line to the transaction that created it.

3. When do the terms apply?

Include product-level start and end dates, pricing periods, discount expiry dates, and amendment effective dates.

A single contract date is insufficient when products start at different times or prices change during the term.

4. How should they be charged?

Include agreed rates, discounts, scheduled increases, billing frequency, advance or arrears billing, payment terms, and proration treatment.

For usage pricing, include the agreed meters, tiers, allowances, commitments, and overage rules.

A signed PDF documents the agreement. Billing also needs the underlying data in a form it can use.

The integration needs a return path, too

RevOps needs to know whether billing received and applied the transaction.

If an update fails, there should be a visible exception and someone responsible for resolving it. A retry must not create a second charge.

Relevant invoice, credit, payment, and usage information should also be available to the teams managing the customer’s next transaction.

Otherwise, Sales may prepare a renewal without knowing what the customer has actually been charged.

For the surrounding sales-system responsibilities, read our CRM and CPQ guide.

How does usage-based pricing change the picture?

Usage-based pricing separates the agreed pricing structure from the final charge.

CPQ needs to capture what the customer accepted: what is measured, how it is priced, what is included, and what happens above or below the commitment.

A metering system measures consumption. A rating engine, often within billing, applies the agreed rates. Billing invoices the resulting charges.

For a hybrid subscription, that may mean a recurring platform fee plus usage charges with customer-specific tiers.

“Usage billed monthly” is not enough detail if the agreement includes an annual allowance, a minimum commitment, or different rates during different periods.

This is another place to test a change rather than just an initial sale:

  • What happens if the usage rate changes halfway through a month?

  • Which rate applies to usage reported late?

  • How does a correction appear on the next invoice?

  • Does the included allowance reset monthly or annually?

Also distinguish an estimated usage total from a guaranteed contractual amount. A projection should not become a fixed obligation unless that is what the customer agreed to.

Do you need separate CPQ and subscription billing software?

You may need both functions without needing two separate products.

A company selling standardized, self-service plans may be well served by a billing platform’s quoting capabilities. A company negotiating custom bundles, multi-year ramps, approval exceptions, and frequent amendments may need more extensive CPQ and subscription capabilities.

Some platforms combine these functions. Others connect specialist systems.

Evaluate the work your team needs to perform. Ask vendors to distinguish between capabilities that are built in, handled through an integration, or completed manually.

Be especially specific about invoicing. Capturing payment terms, creating invoice schedules, issuing invoices, and collecting payments are different functions. “We support billing” does not tell you which ones are included.

What about Salesforce CPQ and Salesforce Billing?

In Salesforce’s managed-package model, CPQ supports configuration, pricing, contracts, and orders. Salesforce Billing uses order information for invoicing and related financial activity.

If you are replacing Salesforce CPQ, identify what downstream billing depends on before changing the records or workflows that supply it.

Our Salesforce CPQ migration checklist explains how to account for those dependencies.

How to evaluate CPQ and billing together

Bring Sales, RevOps, and Finance into the same demonstration. Choose a transaction your team regularly struggles with and follow it through the systems.

Ask the vendor to show:

  1. The original deal. Where are products, dates, negotiated prices, and approvals recorded?

  2. The amendment. Can a rep make the change without creating misleading transactions or requiring backend repairs?

  3. The updated agreement. Can everyone see what the customer owns now and what changes later?

  4. The billing result. Are charges, credits, and schedules consistent with the accepted terms?

  5. The renewal. Does it reflect the amendment, correct quantities, and applicable pricing?

  6. The exception. If the billing update fails, who sees it, and how is it fixed without duplication?

Pay attention to the steps between screens. If the demonstration requires someone to explain how the records will eventually be cleaned up, ask to see that work too.

When evaluating CPQ software for SaaS, the quote is only one part of the test.

Don’t stop the demo when it is signed. Add a product. Change a date. Apply the amendment. Open the renewal.

Then ask Finance whether they could invoice it without calling RevOps.

Bring those questions into your CPQ evaluation

Vendori’s free CPQ RFP Toolkit helps SaaS, AI, and technology teams organize requirements and compare vendors. It includes an RFP template, feature checklist, vendor scorecard, and evaluation guide.

Use it to evaluate how each platform supports the deal your team actually needs to sell, and everything that happens after.

>> Get the CPQ RFP Toolkit.

Get Started Today

Put control and velocity
into your sales process

Schedule a call with one of our team members today!

Get Started Today

Put control and velocity
into your sales process

Schedule a call with one of our team members today!

Get Started Today

Put Control and Velocity into your
sales process

Schedule a call with one of our team members today!