What is quote-to-cash billing?From accepted quote to paid invoice, in one system

Quote-to-cash billing is everything that happens between an accepted quote and a paid, recognized invoice: the order that commits the deal, the fulfillment that delivers it, the invoices generated on the right schedule with the right terms and tax, the payments collected and applied to those invoices, and the hand-off to the ledger where revenue is recognized. It is the back half of quote-to-cash — the half finance owns — and it breaks wherever data has to be re-keyed from one system into another.

The stages from accepted quote to paid invoice

Quote-to-cash has eight stages. The first four — configure, price, quote, approve — are CPQ and belong to the CPQ guide. This guide starts at the yes. The definitive quote-to-cash guide covers all eight in sequence.

The pattern across the last column: every failure is a seam between two systems or two teams. A billing process is only as good as the number of times a human copies a value from one screen to another, and the target is zero.

Orders and fulfillment: from commitment to delivery

The quote is a proposal. An opportunity can carry several, they get versioned and cloned as the deal negotiates, and most of them are never accepted. The order is different in kind. It is created once, from the accepted quote, and it is the record everything downstream runs from. Treat the two differently and the rest of the process gets easier.

An order should carry what fulfillment and billing need and the quote did not: the customer's purchase order number, the billing and shipping contacts, the payment terms, the invoice schedule, the carrier or warehouse for physical goods, and the start and end dates for services. Most of those should default from the account so a rep does not fill them in deal by deal.

The moment that matters is release. Releasing an order is the event that says the deal is real: it locks the lines, and it creates the downstream records — shipments for product lines, delivery schedules for service lines, invoices on the chosen schedule, assets for tracked products and, in a subscription business, the contract, subscriptions and renewal opportunity. Before release an order is editable; after release, changes are amendments. A clean order lifecycle also needs the reverse path: cancel an unreleased order and nothing has happened; un-release a released one and the generated records are reversed, unless an invoice has already been posted to accounting, in which case the door is closed and a credit is the tool.

Fulfillment: shipments, service delivery and assets

Fulfillment is where products and services part ways. A product line ships: a shipment record with a carrier, a tracking number and the lines it contains, tied back to the order lines so partial shipments are visible and a report can show what was ordered but not yet shipped. A service line is delivered over time: a service delivery schedule with a start date, an end date and a unit of term (a month, a quarter, a year) that the invoice schedule will later split.

Both can create assets — the record of what the customer now owns or subscribes to, with dates and a link back to the order line. Assets matter for support, for renewals and for the install base you will one day migrate. Decide at the product level which items create assets and which do not, and let the release do the work.

For businesses that carry stock, inventory awareness at order time prevents the worst fulfillment failure: an order released for something you cannot ship. That is usually an add-on or an ERP integration rather than core billing, and it is the first place the ERP boundary shows up.

Invoicing: schedules, terms, PO numbers and tax

An invoice is a legally binding document, and the discipline that applies to orders applies to it. Invoices should be generated from the order, never typed; they should carry the purchase order number, the payment terms and the due date; and the amounts should tie out to the order lines with tax and any credits shown separately.

The invoice schedule is set per customer or per order and decides how many invoices a term produces. A billing system for B2B needs at least the following, and needs them on the same order when a one-time line sits next to a recurring one.

Payment terms belong on the order and print on the invoice. Net 30 is the B2B default; longer terms are common on enterprise deals, and due dates should be calculated from the term, not typed. An invoice with no PO number, where the customer's accounts payable process requires one, is not rejected — it is parked, which is worse because nothing tells you.

Tax is the other invoice-level requirement that standard CRM objects do not handle. US sales tax is location-based: state, county and city rates, with effective dates so a rate change on the first of the month does not misprice invoices issued the day before. International VAT and GST are by country and rate. Exemptions are an account-level flag. A billing system that cannot do this natively pushes tax to the ERP or to a tax service, which is a legitimate design as long as the invoice the customer sees is the one with the right number on it.

Payment terms, applied payments and the account balance

Collecting is where B2B billing differs most from the card-on-file model most people picture. Business customers pay the way their accounts payable team pays: by ACH or bank transfer, by check, by wire, and by card for smaller amounts or where a stored payment profile exists. The billing system therefore needs two paths that end in the same place. Card and ACH payments run through a connected gateway and come back with a status. Wire and check payments are recorded by hand against the invoice with the check number or reference. Either way, the result is a payment record applied to an invoice.

Applied payments are the operative concept. One payment often covers several invoices, and one invoice is sometimes paid in two parts; the system has to apply amounts, show applied and balance-due on each invoice, and roll the open balance up to the account. That roll-up is what an account owner needs before selling into an account that is sixty days past due, and it is what a credit-hold rule runs on. Refunds and voids go back through the original payment so the records tie out, and credits and additional charges live as lines against the invoice rather than as edits to it. The payments guide covers gateways, card versus ACH economics, stored payment profiles and dunning in depth.

The ERP boundary

Every quote-to-cash implementation has to decide what belongs in the CRM-side billing system and what belongs in the ERP or accounting system. The wrong answer — keying the same invoice into both — is common enough to deserve its own row.

The clean pattern is one direction of flow: invoices and payments post from the billing system to the ledger, marked as posted so the originating order can no longer be un-released, and the ledger is never asked to hold customer-facing detail it does not need. Integration between the two is a real project but a bounded one — a handful of record types moving one way — compared with the alternative of finance rebuilding the invoice from an export.

Revenue recognition sits on the boundary. Under ASC 606 (FASB ASU 2014-09), revenue is recognized as performance obligations are satisfied, not when the invoice is issued or paid: ratably over the service period for a subscription, at delivery for a product. The billing system's job is to produce the schedule from the order or the invoice so the ledger receives it rather than reconstructs it. Whether a given change is recognized prospectively or as a catch-up is a judgment for finance and its auditors, made on accurate inputs.

One-time and recurring revenue in the same process

Most B2B companies sell both. The implementation fee and the subscription go on the same order; the hardware and the support plan go on the same invoice. That is why the billing system has to handle six models at once — flat recurring fees, per-seat pricing, tiered and volume pricing, usage and overage, base-plus-usage, and one-time-plus-recurring — and why the question to ask a vendor is not "which model do you support" but "which of these can go on the same invoice."

Recurring revenue adds three things to the process above: the subscription created from the order, the mid-term amendment that has to be prorated and co-termed, and the renewal that has to exist as a record before anyone remembers to create it. Those belong to the subscription management guide. The billing consequences — a prorated invoice or credit from an amendment, a renewal order that starts the next invoice schedule — belong here, and the B2B subscription billing guide treats them in full, with the subscription billing primer as the shorter introduction.

Metrics that show the process works

Five measures, all computable from order, invoice and payment records if those records are in one place. None has a universal benchmark; establish your own baseline and improve against it.

Choosing where the invoice lives

Three architectures cover the market. A Salesforce-native billing package keeps orders, invoices and payments as records in the org, next to the quote and the opportunity, with gateway connections for card and ACH; Kugamon is one, and Salesforce's own Revenue Cloud Advanced with Revenue Cloud Billing is another, on a separate data model and priced separately. A standalone billing platform such as Zuora or Chargebee owns the invoice on its own platform and syncs a summary into Salesforce; finance-led organizations with very high-volume usage rating often choose this, and the Zuora migration guide covers the trade-off in both directions. Billing in the ERP alone, with sales re-keying orders, is the third and the one most companies are trying to leave. The best CPQ with subscription billing compares six vendors on this axis, and recent consolidation — DealHub's acquisition of Subskribe — is a reminder to ask any vendor for its roadmap in writing.

How Kugamon handles it

Kugamon Quote to Cash is one implementation of the native pattern. The Order is created from the Quote and carries the PO number, contacts, terms and invoice schedule defaulted from the account; releasing it creates Shipments for products, delivery schedules for services, Assets where the product says so, and Invoices on the account's schedule (one-time, yearly, semi-annual, quarterly, monthly, weekly or daily). Invoices carry payment terms, tax from location-based US rates or international VAT/GST with effective dates, and an Age field that fills only when past due. Payments run through Stripe, Authorize.Net, PayPal or eWay for card and ACH, or are recorded for wire and check, and one payment applies across many invoices with the balance rolled up to the Account. Posting an invoice locks the originating order against un-release. All of it is native Salesforce records the standard report builder can see. The Quote to Cash edition is $95 per user per month; Subscription Billing adds contracts, subscriptions and renewals to the same records and is priced at $125. Typical implementation is four to eight weeks.

Keep reading

• What is quote-to-cash? — the eight stages, where they break, and what good looks like.
• B2B subscription billing — invoice-led, contract-led billing on net terms, the six billing models, and the platform options.
• What is subscription billing? — the shorter primer.
• Payment gateways for subscription billing in Salesforce — Stripe, Authorize.Net, PayPal and eWay compared on published fees.
• Best CPQ with subscription billing · Migrating from Zuora · Subskribe acquired by DealHub