Connect QuickBooks Online to Neblex CPQ

Sales quotes in Neblex CPQ. Finance books revenue in QuickBooks Online. Without a link between them, somebody re-types every approved quote as an invoice, the customer name is spelled three ways across the two systems, and a rep has to ask finance whether a customer has paid before the next conversation. Small teams absorb this for a while. Growing teams stop trusting the numbers.

Neblex CPQ has no accounting connector of its own, by design. What it has is a documented API and a pull-based event feed that records every meaningful change to a quote, a customer, an address, or payment terms. Neblex Integration Fabric supplies the QuickBooks Online connector and the flow that sits between the two, so the link is assembled from parts you can inspect rather than coded and forgotten. The result is one path from an approved quote to a posted invoice, with a person in the loop where you want one, and the paid status back on the quote so sales sees it without asking.

On the CPQ side, the API and the event feed. Every operation a rep can perform on a quote or a customer is available as an API call, behind four mandatory access layers: an environment header, a mutual TLS client certificate, a bearer service token, and an optional IP allowance. The flow authenticates as a service account, which is not a user and holds only the scopes you grant it. Changes reach the flow through an event listener: CPQ queues events, the flow fetches a batch on its own schedule, processes it, and acknowledges what it consumed. Delivery is at least once until acknowledged, and CPQ sends no push webhooks, so nothing is lost if the flow is down for an hour.

QUOTE_STATUS_CHANGED starts the invoice. Its payload carries the quote id, the quote number, and the status the quote moved from and to, so the flow acts only when the new status is the stage you treat as approved or won. QUOTE_APPROVED and QUOTE_APPROVAL_REQUESTED are also in the feed. For customers, CUSTOMER_CREATED is an ordered event, while CUSTOMER_UPDATED, CUSTOMER_ADDRESS_UPDATED, and CUSTOMER_TERMS_UPDATED are coalesced: the listener sees only the latest state of each record.

On the Fabric side, the QuickBooks Online connector. The connector authenticates with OAuth2 against one QuickBooks company file and exposes 50 operations, each with a typed output, so the fields available at every step are known before you map them. This flow uses query, getCustomer, createCustomer, updateCustomer, getItem, createInvoice, sendInvoice, getInvoice, getPayment, and changeDataCapture. createCreditMemo and voidInvoice cover the exceptions.

The connector declares no triggers of its own. A change on the QuickBooks side, such as a payment landing against an invoice, is picked up either by a Poll for changes trigger that calls changeDataCapture on the schedule you set, or by QuickBooks's own webhooks calling a Neblex webhook endpoint. Either way the flow runs when the change arrives, not the moment it happens.

In between, the flow. A visual flow maps the fields, resolves the customer and the items, pauses for approval when a rule says so, creates the invoice, and writes the result back to the quote through the CPQ API. Every run is recorded step by step.

Triggered on the status change, idempotent on the quote id.

1. 1A quote reaches the approved stage in CPQ. The feed records QUOTE_STATUS_CHANGED with the quote id and the new status, and the listener fetches it on its next poll.
2. 2The flow reads the full quote. Using the id from the event, it calls the CPQ API for the header, line items, customer, billing address, and payment terms.
3. 3The flow resolves the QuickBooks customer. It runs query for a customer whose DisplayName equals the CPQ customer name. If none exists, createCustomer creates one with the CPQ billing address and the payment terms resolved through a lookup you maintain in the flow.
4. 4Idempotency check. The flow runs query for an invoice whose PrivateNote contains the CPQ quote id. If one exists, the run stops, so a repeated event or a manual re-run never double-invoices.
5. 5Lines are mapped. For each quote line, query resolves the QuickBooks item by the CPQ part number, and the flow carries the quantity, the quoted unit selling price, and the description. A part with no QuickBooks item falls back to a generic item and the run is flagged for review.
6. 6Approval, if your rule says so. If the quote total is over a threshold, or the footer discount exceeds a limit, the flow pauses for a named approver in finance.
7. 7The invoice is created and sent. createInvoice posts the invoice with the customer, lines, currency, terms, and the quote id in the private note; sendInvoice emails it if you choose. The flow then writes the QuickBooks invoice number into the quote's custom field values through the CPQ API.
8. 8Payment comes back. When a Poll for changes trigger or a QuickBooks webhook reports a payment, the flow calls getPayment and getInvoice, reads the balance, and updates the quote's custom field values to paid, partially paid, or overdue.

The starting map for the quote-to-invoice step. Adjust the QuickBooks side to your company file.

Neblex CPQ to QuickBooks Online

• Customers. CUSTOMER_CREATED creates the QuickBooks customer; a coalesced CUSTOMER_UPDATED, CUSTOMER_ADDRESS_UPDATED, or CUSTOMER_TERMS_UPDATED updates it with updateCustomer.
• Invoices. A quote reaching your approved or won stage creates an invoice with mapped items, quantities, prices, currency, and terms.
• Credit memos. A quote restored or re-versioned after invoicing can raise a createCreditMemo step for finance to confirm, rather than silently editing a posted invoice.

QuickBooks Online to Neblex CPQ

• Payment status. Payments update the quote's custom field values with the invoice number, balance, and paid state.
• Invoice state. A voided invoice clears the invoice reference on the quote and flags the run for review.

• Scoped service account. The flow's CPQ token starts with every scope disabled. This flow needs read on quotes and customers, update on quotes for the write-back, and nothing else. On the QuickBooks side, the OAuth2 grant is to one company file.
• Event acknowledgment. The listener acknowledges only what it processed. If the flow fails mid-batch, the unacknowledged events come back on the next poll, and the idempotency check keeps a retry from posting twice.
• Approvals in the flow. An invoice over a threshold, or with a non-standard discount, pauses for a named approver before it posts, on top of the quote approval already enforced inside CPQ.
• Run history. Every run records the event it started from, the quote, the resolved customer, the mapped lines, and the QuickBooks response, step by step. A failed run can be replayed from the failed step.
• Audit log. The service account's calls into CPQ appear in the CPQ audit log under its name, and every token records its last use, so a dormant credential is easy to spot and revoke.