The B2B quote-to-cash integration guide

What quote-to-cash covers

Quote-to-cash is every step between a sales rep deciding what to offer and the money arriving in your bank account:

1. Opportunity. A deal in the CRM with the customer, the contacts and an expected value.

2. Configure. Choosing products, quantities, options and terms that are valid together.

3. Price. Applying list prices, discounts, currencies and any customer-specific pricing.

4. Quote and approve. Producing the quote document, and routing discounts or unusual terms for approval.

5. Sign. The customer accepts the quote or signs the contract.

6. Order. The accepted quote becomes a sales order in the system that runs fulfilment and finance.

7. Invoice. The order is billed, once or on a schedule.

8. Collect. Payment is received and applied, and revenue is recognised.

Each step usually happens in a different system, owned by a different team. Quote-to-cash integration is the work of making those systems hand data to each other correctly, so nobody types the same deal twice.

Where each system fits

The CRM is where a deal is born, and where sales and leadership look for status. The CPQ sits between the deal and the order: it decides what can be sold together, at what price, and who has to approve exceptions. The ERP is the system of record for anything finance needs: the legal customer, the items, the order and the invoice. Invoices and payments usually live in the ERP, with their status sent back to the CRM so sales can see whether a customer has paid.

Smaller companies often run quoting inside the CRM and invoicing in an accounting tool. That works until product rules, approvals or recurring billing outgrow it, which is usually when a dedicated CPQ and an ERP come in.

Decide who owns each piece of data

Most quote-to-cash problems are ownership problems. Before connecting anything, write down which system is the source of truth for each object, and in which direction data flows.

Two rules prevent most of the damage:

• One owner per field. If the CRM and the ERP can both edit a customer's billing address, they will disagree within a month.

• Store each system's ID in the others. Keep the ERP customer ID on the CRM company, and the CRM deal ID on the ERP order. Matching on names breaks the first time someone adds "Inc." to one of them.

Common architecture patterns

CRM-native quoting. Quotes are built in the CRM, for example with HubSpot quotes and products, and an accounting tool invoices from them. Simple and cheap, and right for a short product list with few approval rules.

CRM + CPQ + ERP, connected directly. A CPQ such as DealHub plugs into the CRM through its native integration, and a connector or custom integration turns accepted quotes into ERP orders. The most common setup for B2B companies with real pricing rules.

Middleware in the middle. An integration platform (iPaaS) sits between the systems, with one connection per system and the mapping logic in one place. Useful when there are many systems, or many teams changing them.

A custom integration layer. Small, purpose-built services, for example Azure Functions or a Node.js service, that listen for events (a quote accepted, an invoice paid), transform the data and call each system's API, with logging, retries and alerts. Best when the rules are specific to your business or no connector handles them well.

Most companies end up with a mix: native integrations where they exist and do the job, and custom code for the steps that are specific to how you sell.

Where integrations fail

Integrations rarely fail in an obvious way. They fail by quietly creating bad data:

• Duplicate customers. A new ERP customer is created for every order because the integration can't find the existing one.

• Product catalog drift. An item is renamed or repriced in one system and not the other, so orders fail or go through at the wrong price.

• Partial syncs. The order is created but its lines aren't, or the invoice syncs but the payment doesn't.

• Silent failures. An error is logged where nobody looks, and the problem surfaces weeks later in a month-end reconciliation.

• Edge cases nobody mapped. Multiple currencies, subsidiaries, tax rules, amendments, renewals and cancellations.

• Changes that break the mapping. Someone adds a required field in the ERP, and every sync after that fails.

Build every integration to fail loudly: log each run, retry what can safely be retried, and alert a named person when something can't sync, with enough detail to fix it. An integration that stops and tells you is far cheaper than one that keeps going and corrupts your data.

Custom integration or middleware?

Whatever you choose, it should live in your own accounts, be documented, and be understandable by someone other than the person who built it.

How to measure improvement

Pick measures before the project starts, record where they are today, and check them again afterwards:

• Time from a deal being won to the order existing in the ERP.

• Time from order to invoice.

• How many fields people retype between systems, per deal.

• Invoices that need correcting, and credit notes issued because of order errors.

• Sync errors per week, and how long each one takes to notice and fix.

• Hours spent on month-end reconciliation between the CRM and the ERP.

If the numbers don't move, the integration isn't done, however well it's built.

Go deeper

• How HubSpot and DealHub fit together for CPQ inside HubSpot.

• How to connect HubSpot and NetSuite for the CRM-to-ERP step.

• HubSpot vs Salesforce for B2B companies if the CRM itself is still undecided.

This is the work our quote-to-cash service covers, from the data model to the integrations and the reporting on top.