Connect Stripe with QuickBooks

Overview: Connecting Stripe and QuickBooks

Stripe is the transactional truth for payment-first SaaS and e-commerce businesses—it is where revenue actually moves. QuickBooks Online is the accounting system-of-record where that revenue must be classified, categorized, reconciled, and reported for tax and audit purposes. Without an automated integration between these two platforms, finance teams spend significant time each month manually exporting Stripe payment data, matching it to invoices, creating corresponding transactions in QuickBooks, and reconciling the bank deposit feed. This manual process introduces transcription errors, creates multi-day delays in the financial close, and makes it nearly impossible to maintain real-time visibility into cash flow and revenue recognition.

The Stripe-to-QuickBooks integration automates this reconciliation pipeline by translating Stripe's payment events—PaymentIntent successes, Invoice payments, Subscription renewals, Refunds—into the corresponding QuickBooks transactions: Sales Receipts, Payments against Invoices, Journal Entries, and Credit Memos. The integration must handle not just the happy path but also edge cases that are endemic to subscription billing: prorations, partial refunds, disputed charges, and the tax jurisdiction complexity that arises when processing payments from customers in different states or countries.

Core Prerequisites

On the Stripe side, you must configure one or more webhook endpoints in the Stripe Dashboard under Developers > Webhooks, or via the Stripe CLI for local development. Each webhook endpoint has a signing secret (prefixed whsec_) that your integration must use to verify the Stripe-Signature header on every incoming request—this is a security requirement, not optional. The events you must subscribe to are: payment_intent.succeeded for one-time payments captured via PaymentIntents, invoice.paid for subscription and invoice-based charges, invoice.created for pre-payment invoice creation (if you sync invoices before payment collection), charge.refunded for all refund events, and customer.created for new customer record synchronization. Stripe's API is versioned; pin your webhook endpoint to a specific API version in the Stripe Dashboard (e.g., 2023-10-16) to prevent upstream API changes from breaking your payload parsing.

On the QuickBooks Online side, you must register an app at developer.intuit.com and complete the OAuth 2.0 authorization flow using Intuit's authorization server. The required OAuth 2.0 scopes are com.intuit.quickbooks.accounting for full read/write access to the QBO Accounting API. After authorization, you will receive an access token (valid for 60 minutes) and a refresh token (valid for 100 days, extendable). Critically, you must store and refresh these tokens proactively—a lapsed refresh token requires the QBO administrator to re-authorize the integration manually. The realmId parameter returned during the authorization flow is the QuickBooks company ID and must be included as a path parameter in every API request: https://quickbooks.api.intuit.com/v3/company/{realmId}/.

Before any transactions can be created, your integration must complete a one-time Chart of Accounts mapping step. Query your QBO company's account list (GET /v3/company/{realmId}/query?query=SELECT * FROM Account) and identify the Income Account IDs for each of your Stripe product lines, the Bank Account or Undeposited Funds account where Stripe payouts land, the Accounts Receivable account for invoice-based transactions, and the liability accounts for sales tax by jurisdiction. Store these ID mappings in your integration configuration—QuickBooks references accounts by their internal integer IDs, not by name.

Top Enterprise Use Cases

The highest-frequency use case is automated Sales Receipt creation for successful one-time charges. Every time Stripe fires a payment_intent.succeeded event, the integration creates a corresponding QuickBooks Sales Receipt against the customer's QBO record, correctly associating the line items with the appropriate income accounts and capturing the payment method (card, bank transfer, etc.) for reconciliation. This eliminates manual data entry and ensures that every Stripe transaction has a corresponding accounting record within seconds of the charge completing.

The second critical use case is subscription renewal accounting. Stripe's subscription billing fires invoice.paid events on every renewal cycle. The integration translates each invoice.paid event into a QuickBooks Sales Receipt or Payments Against Invoice entry, depending on whether your billing model uses pre-billing (invoices issued before charge) or post-billing (charges collected first). For annual subscriptions with monthly revenue recognition requirements, the integration may need to create Journal Entries to defer revenue across accounting periods rather than recognizing the full annual amount at time of payment.

Refund tracking is the third essential use case. Every charge.refunded event from Stripe must be matched to its original Sales Receipt in QuickBooks and create a Credit Memo against the same customer and income accounts. Partial refunds—where Stripe returns only a portion of the original charge—are particularly important to handle correctly because they require the Credit Memo to reflect only the refunded amount, not the full original transaction amount.

A fourth use case relevant to companies with sales tax obligations is automated tax line synchronization. Stripe Tax generates per-transaction tax breakdowns by jurisdiction. The integration should parse the tax_amounts array from the Stripe invoice object and create matching tax line items in QuickBooks against the correct tax code for each jurisdiction, enabling accurate sales tax reporting and remittance.

Step-by-Step Implementation Guide

The integration begins with your Stripe webhook consumer endpoint. When Stripe delivers a payment_intent.succeeded event, you must first validate the request by computing an HMAC-SHA256 signature of the raw request body using your whsec_ signing secret and comparing it against the Stripe-Signature header value. Stripe's official SDKs provide stripe.webhooks.constructEvent() to perform this check. Never skip signature verification—processing unsigned webhook payloads exposes your accounting system to injection attacks. A representative payment_intent.succeeded payload relevant to your QBO mapping looks like this:

{
  "id": "evt_3OHxxxxxx",
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3OHxxxxxx",
      "amount": 9900,
      "currency": "usd",
      "customer": "cus_Pxxxxxx",
      "description": "Professional Plan - Monthly",
      "metadata": {
        "product_id": "prod_xxxxxx",
        "invoice_id": "in_xxxxxx"
      },
      "charges": {
        "data": [{
          "payment_method_details": {
            "type": "card"
          },
          "receipt_email": "[email protected]"
        }]
      }
    }
  }
}

Upon receiving this event, your middleware resolves the Stripe customer to a QuickBooks Customer record. Perform a QBO query: SELECT * FROM Customer WHERE PrimaryEmailAddr = '[email protected]'. If no matching customer exists, create one via POST /v3/company/{realmId}/customer before proceeding. With the QBO Customer ID resolved, construct the Sales Receipt request body:

{
  "CustomerRef": { "value": "42" },
  "PaymentMethodRef": { "value": "1" },
  "DepositToAccountRef": { "value": "35" },
  "Line": [
    {
      "Amount": 99.00,
      "DetailType": "SalesItemLineDetail",
      "SalesItemLineDetail": {
        "ItemRef": { "value": "20" },
        "UnitPrice": 99.00,
        "Qty": 1
      }
    }
  ],
  "TxnDate": "2025-09-15",
  "PrivateNote": "Stripe PaymentIntent: pi_3OHxxxxxx"
}

The DepositToAccountRef value must reference the QuickBooks account that corresponds to your Stripe payout destination—typically an "Undeposited Funds" account or a dedicated "Stripe Clearing" bank account. The PrivateNote field should always contain the Stripe Payment Intent ID to enable manual reconciliation lookups in QBO. POST this payload to https://quickbooks.api.intuit.com/v3/company/{realmId}/salesreceipt.

For Zapier, use the Stripe "New Successful Charge" trigger. The trigger provides the charge amount, customer email, and payment method. Chain a QuickBooks "Find Customer" step using the customer email; add a QuickBooks "Create Customer" step on a path that only executes if the Find step returns no results. Then add a QuickBooks "Create Sales Receipt" step mapping the Stripe amount (note: Stripe amounts are in the currency's smallest unit—divide by 100 for USD), the resolved Customer ID, and the appropriate income account and item from your pre-configured QBO chart of accounts mapping.

For Make, the scenario uses the Stripe "Watch Events" module with the event type filter set to payment_intent.succeeded. Because Make's Stripe module provides parsed event data, you can directly access data.object.customer for the Stripe customer ID. Use a Stripe "Retrieve a Customer" module to get the customer's email, then a QuickBooks "Search for Customer Records" module to find or create the QBO customer. The QuickBooks "Create a Sales Receipt" module downstream should have the Line items array populated via Make's Array Aggregator module if the PaymentIntent includes multiple line items from the Stripe metadata.

For invoice-based subscriptions, subscribe to invoice.paid instead of payment_intent.succeeded. The invoice.paid event provides a lines.data array with individual line items for each subscription plan, add-on, or proration, making it the correct event for accurately reflecting subscription components as individual QBO Sales Receipt lines rather than a single aggregate charge.

Common Pitfalls & Troubleshooting

A 401 Unauthorized from the QuickBooks API almost always indicates an expired OAuth 2.0 access token. QBO access tokens expire after exactly 60 minutes and must be refreshed using the refresh token grant: POST to https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer with grant_type=refresh_token. If the refresh token itself has expired (after 100 days of non-use), the QBO administrator must re-authorize through the OAuth consent screen. Implement proactive token refresh—check the token's expiration timestamp before each API call and refresh if fewer than 5 minutes remain, rather than waiting for a 401 to trigger the refresh.

A 400 Bad Request from QBO typically indicates a malformed request body. The most frequent cause in Stripe integrations is a unit amount mismatch: Stripe stores all amounts in the currency's smallest denomination (cents for USD, pence for GBP), and if you pass the raw Stripe integer value directly to QuickBooks without dividing by 100, you will create Sales Receipts for one hundred times the actual transaction amount. Always normalize Stripe amounts by dividing by the currency's decimal precision before constructing QBO payloads. A secondary cause of 400 errors is referencing an inactive account, item, or customer in QBO—soft-deleted entities in QBO return Active: false in list queries but their IDs may persist in your integration's local cache; refresh your entity cache periodically and handle inactive entity references gracefully.

Duplicate transaction detection is an ongoing operational concern. Stripe webhooks are delivered at least once, meaning the same event may arrive at your endpoint multiple times—particularly during retries triggered by your endpoint returning a non-200 status. Implement idempotency at the persistence layer by storing the Stripe event ID (evt_ prefixed) in a processed events table and checking for it before creating a QBO transaction. If the event ID is already present, return HTTP 200 immediately without creating a duplicate Sales Receipt.

Tax jurisdiction mismatches occur when your Stripe Tax configuration and your QuickBooks tax agency setup are not aligned. If Stripe Tax calculates and collects sales tax for, say, California at the 9.5% composite rate, you must ensure that the QBO Tax Rate and Tax Agency configuration for California matches this rate before the integration can correctly assign the tax amount to the correct liability account. Discrepancies here cause reconciliation failures during monthly close and may result in incorrect sales tax remittance amounts.