Shopify QuickBooks Integration Not Syncing? Fix the Ledger

A Shopify QuickBooks integration not syncing is a reconciliation that has stopped: payouts and ledger entries no longer match bank deposits. Once an expired authorisation or a rejected mapping is ruled out, two things break the sync. Events are duplicated or dropped on either side of the middleware, and a per-order sales receipt model cannot reconcile to net payouts once processing fees are deducted. Our view: at volume, reconciling needs an idempotent, payout-driven ledger; a small single-currency store can keep per-order receipts.

Why is your Shopify QuickBooks integration not syncing?

The first failure class is delivery: a webhook drops silently, or a retry posts the same sale twice. Shopify delivers webhooks as HTTPS POST requests with a fixed set of delivery headers. If Shopify receives no response or an error, it retries 8 times over the next 4 hours. After 8 consecutive failures, a subscription created through the GraphQL Admin API is deleted. When the accounting endpoint is slow, those timeouts turn into duplicate payloads. Return a 2xx as soon as the delivery is stored, and do the QuickBooks work from a queue. A receiver that calls QuickBooks inside the request will hit gateway timeouts under load.

Handling retries without deduplication corrupts order balances and invoice totals. Shopify's guidance is to process webhooks idempotently, or to use the X-Shopify-Webhook-Id header to detect and skip duplicates. Check a persistent store for the ID, skip a delivery you have seen, and save the ID of a new one. The cascading failures this prevents are covered in our Shopify webhook retries guide.

Refund events add drift when they are handled as separate ledger adjustments. The refunds/create webhook topic fires when a refund is created for an order. A connector that posts the refund as an isolated credit memo, without checking whether it restocked inventory or returned shipping, leaves the credit memo and the original receipt in disagreement. Our Shopify returns and RMA integration architecture handles the return side of that flow.

Route order creations, updates, cancellations and refunds through one queue rather than one handler per topic. A single queue keeps deduplication in one place and preserves the order of events for each order. The same queue design appears in our Shopify NetSuite integration guide, where ordering per order matters for the same reason.

Test the listener before it reaches staging: send the same payload twice and assert one ledger write, and confirm the 2xx returns before any QuickBooks call starts. Shopify CLI can trigger synthetic events for this, with limits. These triggered webhooks are not retried upon failure, are subject to Partner API rate limits, and cannot be used to validate API webhook subscriptions.

Settlement over invoices: modelling payouts and balance transactions

The second failure class is the model. At volume, posting a sales receipt per storefront order prevents reconciliation, because bank deposits reflect net payout batches, not gross order totals. An integration must read Shopify Payments settlement records to match bank feed amounts. The GraphQL Admin API retrieves a list of payouts associated with the Shopify Payments account.

Each payout combines gross sales, refunds and processing fees into one figure. To audit the components, a GraphQL query fetches the balance transactions for the Shopify Payments account. Building one journal per payout from those balance transactions lets you post processing fees to an expense account while the net amount matches the bank statement line.

A ShopifyPaymentsBalanceTransaction records money movement from charges, refunds, payouts, adjustments or other payment activities, with the gross amount, processing fees and the net amount that affects the balance. Reading the object requires a user with access to payouts, so grant that access before the job runs.

A worked example (hypothetical)

Take a store whose Friday payout bundles the week's card orders, a handful of refunds and one chargeback. A per-order connector posts dozens of receipts, so the deposit matches nothing. A payout-driven job instead reads the balance transactions behind that payout and posts one journal. Gross sales go to revenue, fees to a processing-fee expense account, refunds against revenue and the chargeback to its own account. The net goes to the clearing account the bank feed settles against.

Preventing duplicate records with QuickBooks request tracking

Network timeouts between the middleware and QuickBooks Online can generate duplicate journal entries and sales receipts. When a request drops before a response arrives, the client cannot know whether QuickBooks committed the record. Re-sending the same invoice without an idempotency key creates a second one. If the connector also writes refunds back to Shopify, refundCreate supports idempotency through the @idempotent directive. A retried call then creates no second refund in Shopify; the QuickBooks side still needs its own request ID.

QuickBooks Online handles idempotency through request identifiers. A retry must reuse the same request ID; the identifier exists so that QuickBooks can recognise the repeat rather than post a second transaction. The SDKs generate a random one when none is set, so a retry without an explicit identifier gets a new ID and creates a duplicate.

Identifiers must follow Intuit's rules. The request ID your app specifies must be unique for all requests for a given QuickBooks Online company file (as specified by the realm ID). The request ID can have a maximum of 50 characters for all operations, except for batch operations. In a batch, for each batch item bId, only 10 characters are allowed when the request ID is also specified. An order can carry several refund events, so build the key from the refund ID or the X-Shopify-Webhook-Id plus an event prefix. The payout journal is pulled by query, not delivered by webhook. Key it with the numeric payout ID (the trailing part of the GID, not the full GID) plus the currency code. All three keep keys unique and inside the 50-character ceiling.

How to configure multi-store tracking and sales tax

Tax discrepancies occur when QuickBooks calculates an order's tax differently from the total Shopify collected. Revenue by store also needs explicit configuration.

1. Enable tracking in company settings. Class and location tracking live on the Preferences entity: AccountingInfoPrefs.ClassTrackingPerTxnLine is the class setting and AccountingInfoPrefs.TrackDepartments the location setting.
2. Put the location on each transaction. Transactions that support location tracking carry a DepartmentRef built from the Department object, with Department.Id as its value.
3. Define transaction classes. When creating classification entities, the request body must include the class name, and optionally a parent reference for sub-classes.
4. US company files: let automated sales tax calculate. In a US company file, QuickBooks Online automatically calculates sales tax and returns the amount in TxnTaxDetail.TotalTax; the TxnTaxDetail.TxnTaxCodeRef passed in with the request is honored. If you post sales receipts, compare that total with what Shopify collected and book any difference to a tax variance account. Automated sales tax applies to sales transactions such as invoices and sales receipts; on a payout journal, post the tax Shopify collected straight to the sales tax liability account.
5. UK and other non-US company files: send the tax code per line. Non-US companies use TaxCode objects to specify sales tax at the line level, and QuickBooks returns the total in TxnTaxDetail.TotalTax. On a journal entry, GlobalTaxCalculation is required for non-US companies, as TaxExcluded or TaxInclusive.

Multi-currency and payouts outside Shopify Payments

A store selling in several currencies gets payouts whose balance transaction amounts carry a currency code. The journal must therefore be built per currency. On the QuickBooks side, CurrencyRef is required on a transaction once Preferences.MultiCurrencyEnabled is true. ExchangeRate is the number of home currency units it takes to equal one unit of the transaction currency. Post each payout in its own currency at the payout-date rate.

Orders paid through PayPal, Klarna or another gateway settle outside Shopify Payments on their own schedule, so they need their own settlement source in the ledger. Treat each provider's settlement report as a separate payout source with the same journal shape. The Shopify order record stays the audit trail that ties them together.

Three connector routes compared

The right route depends on transaction volume and the ledger detail you need; the three differ in who owns the mapping and where fees land.

A per-order receipt model is fine while volume is low enough to allocate fees by hand at month end. Once fees, refunds and several currencies are in play, only the payout-driven journal reconciles without manual work.

Troubleshoot first, then choose a route

If the connector has simply stopped, rule out the plain causes first. An expired or revoked QuickBooks authorisation, an app disconnected from the store, or an item, customer or tax mapping that rejects the payload will each halt it. Next, check the QuickBooks company file: confirm that class and location tracking, the locale's tax model and, where needed, multi-currency are all enabled before live events arrive. Then read the webhook listener logs and check that the endpoint acknowledges each delivery quickly and queues the accounting work. With those three checks done, pick the route from the table above that matches your volume and currencies. Our Shopify QuickBooks integration service covers the build or the migration.