Most of the guides on this site take one connector apart. This one goes the other way, because after enough of them a pattern becomes impossible to ignore: the same three or four joins keep breaking, in the same order, regardless of which vendors are on either side. The name for the path those joins sit on is quote to cash, and describing the whole path is the only way to see that the failures are not a run of unrelated vendor shortcomings.
The category description is stable across vendor glossaries and runs to roughly seven stages. Configure, price and quote. Proposal and negotiation. Contract execution and signature. Fulfilment or provisioning. Invoicing. Payment collection and cash application. Revenue recognition.
What has changed recently, and what makes this worth writing now, is that HubSpot covers about six of those. It has a real CPQ product, in its own words a tool to create, manage and approve quotes inside HubSpot. It has approvals, e-signatures, payment links, invoices, subscriptions and payment processing. Ten years ago the answer to "can the CRM run quote to cash" was obviously no. Today it is mostly yes, and the seams have not disappeared. They have moved somewhere more interesting: inside HubSpot's own product ladder, and inside HubSpot's own integrations, where in one documented case connecting your accounting system removes a feature from your CRM.
This guide walks the seven stages, marks where each one actually lives, and points at the joins. It is the process-level companion to the individual connector guides, which are linked at each stage, and it sits alongside the broader guide to HubSpot integrations.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What Quote to Cash Actually Means
The term gets used loosely, usually by vendors who cover two stages and would like you to believe that is the set. It is worth being precise, because the precision is what makes the gaps visible.
Two narrower terms sit inside it and are constantly confused with it. CPQ is configure, price, quote, which is stage one alone. Billing is roughly stages five and six. Quote to cash is the whole path, and it is the only frame in which a question like "why does the renewal price not match the contract" has a findable answer.
- 1
Configure, price, quote
Turning an intent into a priced offer. Product catalogue, price book, discounting rules, term length, tiered or volume pricing. This is where the numbers are decided, which makes it the origin of every downstream disagreement.
- 2
Proposal and negotiation
The offer meets a buyer who wants it changed. Redlines, approval thresholds, non-standard terms. This stage is mostly conversation, which is exactly why the systems handle it worst.
- 3
Contract execution and signature
The agreed version becomes an executed document. This is the stage that most obviously produces a new artefact, and the stage where the artefact and the CRM record most reliably stop matching.
- 4
Fulfilment or provisioning
Somebody has to deliver the thing. Onboarding, project kickoff, licence provisioning, shipment. Usually a different system and often a different department.
- 5
Invoicing
The agreement becomes a demand for money, with the correct amounts, the correct tax treatment and the correct billing entity. Small errors here are expensive because they are customer-facing.
- 6
Payment collection and cash application
Money arrives and is matched to what it was for. Partial payments, multiple currencies, failed cards, dunning.
- 7
Revenue recognition
The finance system decides when that money counts as revenue, which for anything recurring is not when it arrived. This is an accounting judgement, not a CRM feature.
Every stage above is well served by good software. Nothing in the list is hard. What nobody sells is the join, and the join is where the money goes missing.
What HubSpot Covers, and What It Charges For
Here is the part that surprises people who last looked at this a few years ago, and the part worth checking before anybody scopes a project. HubSpot's coverage is broad, and its pricing ladder runs in the opposite direction to intuition.
Now the ladder. You would expect a CRM to give away quoting, since quoting sells the CRM, and to charge for taking money. It is the other way round.
| Tool | Subscription required |
|---|---|
| Invoices | Any subscription |
| Payment links | Any subscription |
| Subscriptions (recurring) | Any subscription |
| Legacy quotes | Any subscription |
| Quotes (current CPQ) | A Revenue Hub subscription, plus an assigned Revenue Hub seat to create or edit |
| Quote approvals | Revenue Hub Professional or Enterprise |
| Advanced approvals | Revenue Hub Enterprise |
| Tiered pricing and price books | A Revenue Hub subscription and a seat |
| E-signature on quotes | Revenue Hub Professional or Enterprise, plus an assigned seat |
| Payment processing | Starter and above on the other Hubs, or Revenue Hub Professional or Enterprise |
Read the top and bottom of that table together. Invoicing and collecting are free on any plan. Quoting properly is the paid part. That is a coherent commercial strategy, because getting money into HubSpot makes HubSpot stickier, but it inverts how most teams plan a rollout. Teams routinely budget for the collection end and discover the gate is at the quoting end.
The approvals detail worth knowing before stage two
Approvals are stage two of the process, and HubSpot's implementation has three documented constraints that decide whether it fits a real deal desk. You can assign up to 10 approvers against configured filters and choose whether one or all must approve. Advanced approvals add triggering on quote and line item properties, and sequential approvals ranked by priority.
Then the constraints. You cannot turn on standard and advanced approvals simultaneously, so a portal with two genuinely different approval shapes has to pick one. If a designated approver creates a quote and they are the only approver, the quote will not require approval, which is either sensible or a control gap depending on who your approvers are. And advanced approvals run on a workflow HubSpot creates, where the documentation states you must use the created workflow and cannot duplicate it or create a new one. Approval logic in HubSpot lives in exactly one place and that place is not yours to fork.
Where the Chain Actually Breaks
This is the substance of the guide. Everything below is documented behaviour rather than a bug, which is precisely why no amount of configuration removes it.
The documented seams, stage by stage
Installing an accounting connector removes tax from invoices. HubSpot states that if you have installed the QuickBooks Online data sync app, it is not possible to add taxes to invoices. This is the most instructive sentence in the whole process. Nothing failed, no limit was hit, and no feature is missing. Two systems both wanted to own tax and one had to be switched off. The detail is in the HubSpot QuickBooks integration guide.
HubSpot invoices do not exist in Stripe. HubSpot documents that if you use Stripe as a payment processing option, when creating invoices in HubSpot, invoices won't be created in Stripe. The payment is processed and the document lives on one side only, which surfaces the first time finance reconciles the processor against the ledger. The detail is in the HubSpot Stripe integration guide.
Partial payments do not associate line items. When a partial payment is made on an invoice, HubSpot states that line items will not automatically associate with the payment. So the moment a customer pays half, the question "which of these things has been paid for" has no answer in the record, which is the question revenue recognition needs answered.
Online payment requires whole-number quantities. Documented plainly: for online payments, line item quantities must be whole numbers. Anything billed in hours, partial licences, fractional units or metered consumption cannot be collected online as-is, which pushes usage-based pricing off the native path immediately.
Payments is a three-country feature. HubSpot payments is only available to businesses and organizations located and operating in the United States, the United Kingdom and Canada, with a bank account in one of those three, subject to two to three business days of underwriting and to high-risk industry ineligibility that points at Stripe's restricted businesses list. Elsewhere, the documentation notes you can record manual payments against the invoice, which is a polite way of saying somebody types it in.
Signed values do not come back from the signature stage. This is the join that produces the most silent damage, and both major vendors document it. Docusign's HubSpot app is, in HubSpot's own words, not a data sync app: envelope status returns and no field value does. PandaDoc does return values, but only Text, Date, Dropdown, Checkbox and Radio Button types, which excludes number and currency, so a negotiated figure cannot come back as a figure. See the Docusign and PandaDoc guides.
Recurring pricing flattens when it crosses a boundary. PandaDoc's documentation notes recurring products become one-time in pricing tables and that taxes do not transfer. A subscription that arrives downstream as a single charge is not a rounding error, it is the difference between ARR and a one-off.
Nothing reconciles the two ends. The structural one, and the same finding as every connector guide on this site. No pass ever compares what was signed against what was invoiced against what was recognised and reports the difference. Each hop is event-driven, so a value that fails to cross fails silently and permanently.
A feature gap can be closed by buying the feature. An ownership conflict cannot, because both systems are working correctly and they disagree. Almost everything that breaks in quote to cash is the second kind.
Stage Seven Does Not Exist
It is worth stating this cleanly rather than treating it as an omission, because HubSpot is right not to build it.
Revenue recognition is an accounting judgement made under a standard. For anything recurring, ratable or milestone-based, the moment money arrives and the moment it becomes revenue are different moments, sometimes by many months. That determination belongs in a general ledger with an audit trail, not in a CRM.
Which means the last join in the chain is the one that always has to be built or bought, and it is the one where the receiving system is least tolerant of mess. The HubSpot ERP integration guide covers the landscape, and the NetSuite guide covers the one native connector that crosses from records into process, with a deal-based workflow that creates a real sales order. That crossing is rare precisely because it is the hard one.
For teams whose finance system is a smaller accounting tool rather than an ERP, the Xero and QuickBooks guides cover where those connectors stop, and the answer in both cases is short of revenue recognition.
The Handoffs, One at a Time
Mapping the stages onto systems is the exercise worth doing on a whiteboard before anybody writes code, because it makes the count of boundaries obvious. A typical B2B stack crosses four to six of them.
| Stage | Where it usually lives | The join that breaks |
|---|---|---|
| Configure, price, quote | HubSpot CPQ, or a dedicated CPQ | Price book drift between catalogue and quote |
| Proposal and negotiation | HubSpot approvals, email, a document tool | Approval logic split across two systems |
| Contract execution | Docusign, PandaDoc | Signed values never reach CRM properties |
| Fulfilment or provisioning | ClickUp, Asana, an internal tool | Created once, never updated again |
| Invoicing | HubSpot invoices, QuickBooks, Xero | Tax ownership, and the invoice existing in one place |
| Payment and cash application | Stripe, HubSpot payments | Partial payments with no line item association |
| Revenue recognition | NetSuite, an ERP | Nothing native reaches it |
Count the rows where the system changes. That number, not the number of tools, is the size of your integration problem.
Quote to Cash: Native vs iPaaS vs Custom
Three routes, and they stack. If the middle term needs defining, the guide to iPaaS covers the category.
Genuinely capable and partly free. Quotes with approvals, e-signature, invoices, payment links and subscriptions in one place, with no integration to maintain because there is no boundary to cross. If your pricing is simple, your quantities are whole numbers and your accountant is happy reconciling by hand once a month, configure this and build nothing.
A scenario listening for a signature event and writing a few values back, or pushing an invoice into the accounting system. This closes individual gaps cheaply and is the right answer for a small number of them. It does not add reconciliation, it prices per operation so it scales with deal volume, and every scenario is a separate thing to remember exists.
Built against the vendor APIs and the HubSpot API directly, with a declared owner for every field, so a signed figure lands on the property that owns it, a recurring product stays recurring, tax is calculated in exactly one system on purpose, a failed write retries, and a nightly reconciliation compares what was signed against what was invoiced and reports the difference to a person rather than to nobody.
When to Build Across the Quote to Cash Chain
Configure the native path first. It is better than its reputation and some of it costs nothing. The signal to build is not a missing feature, it is a person doing reconciliation as a job.
Signs the chain needs owning
Somebody reads executed contracts and types values into HubSpot. The single most common symptom, and a direct consequence of a signature stage that returns status and not values. It looks like an admin task, which is why it survives for years and why nobody costs it.
Your pricing is recurring, tiered or metered. Whole-number quantities for online payment, recurring products flattening to one-time across a vendor boundary, and tiered pricing gated behind a Revenue Hub seat all point the same way. Usage-based pricing leaves the native path at stage one.
You operate outside the US, UK and Canada. Payments is unavailable, so collection is somebody else's system by definition and the invoice-to-payment join has to be built. This is not a limitation to work around, it is a design input.
Tax is calculated in two places. If installing an accounting connector took a capability away from your invoices, you have an ownership conflict that configuration resolved by disabling something. That is a decision worth making deliberately rather than inheriting.
Finance closes the month from spreadsheets. Partial payments that do not associate line items, invoices that exist on one side of the processor boundary, and no native path to revenue recognition all produce the same artefact: a spreadsheet that reconciles two systems, maintained by the person who understands both.
The renewal conversation requires opening a PDF. The cleanest test there is. If nobody can answer what this customer agreed to without finding the document, the CRM is not the system of record for the commercial relationship, whatever the org chart says.
What to know before you scope a build
The technical ceilings across this chain are generous and the commercial ones are not, which is the consistent finding across every guide on this site.
The practical consequence is that quote to cash is almost never an engineering throughput problem. It is a problem of deciding, in writing, which system owns each field at each stage, and then enforcing that decision in code with something that notices when it is violated. Ask anyone quoting for this work to name the system of record for the contract value. If they do not have an immediate answer, they have not shipped one.
What Owning the Chain Costs
The honest comparison is not build versus free, because the native tools stay configured either way and should. It is build versus the running cost of not building: the iPaaS subscription that scales with deal volume, the Revenue Hub seats bought to unlock a stage, and the standing monthly hours somebody spends reconciling documents against records against the ledger.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Closing one join is a small build. Owning the chain from quote through signature into invoicing and out to the ledger, with retries and a nightly reconciliation, is a larger one. The cost teams underestimate is never the build. It is maintenance, because pricing changes every quarter, legal revises the template, ops renames a property, and an unowned chain drifts until finance stops trusting the CRM and starts keeping its own version.
The cheapest moment to capture what was agreed is the moment it is agreed. The most expensive is the renewal, when three systems each hold a different number and the customer holds the PDF.
That is why we productized it. StackTie builds the connections across this chain against the vendor APIs and the HubSpot API directly for a fixed fee, then maintains them on a flat monthly retainer, so what was quoted, what was signed, what was invoiced and what was recognised stay the same number. The build fee and retainer are published on the pricing page rather than quoted per call.
Four systems, one number. Do they agree?
When a negotiated figure never reaches the deal, when a recurring product arrives downstream as a one-off, when installing an accounting connector quietly removed tax from your invoices, or when finance closes the month from a spreadsheet that reconciles two systems by hand, that is a build. StackTie builds custom HubSpot integrations across the quote to cash chain for a fixed fee and maintains them on a flat monthly retainer. Live in 14 days or your money back. Book a free audit and we'll map every join in your chain and show you which ones leak.
The Bottom Line
Quote to cash used to be a story about a CRM that could not price or collect. That story is out of date. HubSpot has real CPQ, real approvals, invoices, subscriptions and payment processing, and it gives away the collection end while charging for the quoting end, which is the opposite of what most rollout plans assume.
The seams moved rather than closed. They sit inside the product ladder, where two quote products coexist and approval logic lives in exactly one workflow you cannot fork. They sit inside the integrations, where connecting QuickBooks makes it impossible to add tax to an invoice and where a HubSpot invoice does not exist in Stripe. They sit at the signature join, where neither major vendor returns a negotiated number as a number. And they stop entirely at stage seven, which HubSpot correctly does not attempt.
The line is easy to state. Every stage of quote to cash can be bought. The joins between them cannot, and the joins are where the number changes.
