Connecting Stripe to QuickBooks: the chart of accounts decides everything

There are several ready-made connectors for this, and for a straightforward business one of them is probably the right answer. What decides whether any of them works — including one you build — is a question that has nothing to do with the connection: which account each movement posts to.

Get that mapping right and the bookkeeping is quiet. Get it wrong and every month produces a reconciliation that somebody does by hand, which is the situation the integration was bought to prevent.

What we'll cover

• The mapping is the configuration
• Accounts each movement needs
• Sales tax, which is the hardest part
• Building it with CodeWords
• What the ready-made connectors do
• Where they stop
• Summary or detail
• The monthly close, and what it should look like
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The mapping is the configuration

Every movement needs a destination account, and the list of movements is longer than people expect.

A wrong mapping is silent. The books balance and the categories are wrong, which is discovered at year end.

Your accountant decides this, not the connector's defaults, which are generic by necessity.

Document it as a table — movement type to account — and keep it with the integration.

Review it when you add products, since a new revenue type frequently needs a new account and defaults to the wrong one.

Test with a closed month, comparing the integration's output against what was filed, before trusting it forward.

Accounts each movement needs

Sales revenue, possibly split by product or by region depending on how you report.

Processing fees as an expense, separate from other bank charges so the rate is visible.

A clearing account for funds in transit between the charge and the payout, which is the account most often missing and the reason bank reconciliation fails.

Refunds, as a contra-revenue account rather than an expense.

Disputes and their fees, separately, since they behave differently and their fees are usually retained regardless of outcome.

Sales tax liability, which is not revenue and must not be posted as such.

Currency conversion, where applicable, as its own expense rather than absorbed into fees.

Sales tax, which is the hardest part

Tax collected is a liability, held on behalf of an authority, not income.

Rates vary by jurisdiction, and for many sellers by the customer's location rather than yours.

Stripe may or may not be calculating it, depending on your setup, and the integration needs to know which.

Registration thresholds matter, and crossing one changes your obligations in a place you may not have noticed.

Partial refunds need proportional tax treatment, which is the detail most implementations get wrong.

This is an accountant's question, not a configuration one, and the cost of getting it wrong is assessed later with interest.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so Stripe, QuickBooks and your reporting can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the account mapping, the level of detail, and how exceptions are handled.
3. Authorize the connections — Stripe and QuickBooks.
4. Describe the exceptions: a dispute, a multi-currency payout, a negative payout, a refund crossing a period.
5. Run it against a closed month and reconcile against what was filed before running it forward.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What the ready-made connectors do

Post transactions on a schedule, usually summarised by payout or by day.

Handle the common movements — charges, refunds, fees — with a configurable mapping.

Match payouts to bank deposits, which is the main thing they are bought for.

Require little setup for a business selling one kind of thing in one currency in one jurisdiction.

Are cheap relative to building anything.

Are the right answer for most small businesses, and it is worth saying so plainly before describing when they are not.

Where they stop

Multi-currency handling varies and is frequently the first thing to break.

Platform and marketplace flows, where money passes through to third parties, are usually out of scope entirely.

Custom revenue recognition — deferred revenue on annual plans, for instance — is not something a generic connector does.

Class, location and project tracking in QuickBooks may not be populated, which matters if you report by segment.

Joining to your own data — a customer segment, a product line not visible to Stripe — is not available.

Unusual movements such as account-level adjustments and reserves are handled inconsistently or not at all.

Summary or detail

Summarised by payout is usually right: one journal per payout matching one bank line, with the detail underneath.

Per transaction creates an unusable ledger for any volume, and QuickBooks slows noticeably.

Customer-level detail is worth keeping only where you invoice specific customers and need receivables per customer.

Keep the detail in Stripe and reference it, rather than duplicating it into the accounting system.

Ask your accountant what they need to see, which is usually less than people assume and differently structured.

Match the granularity to the reconciliation, since that is the task the data exists to support.

The monthly close, and what it should look like

The point of this integration is that month end stops being an event. Whether it does depends on a few habits rather than on the connector.

Reconcile weekly, not monthly, since a discrepancy found in week one is traceable and the same discrepancy found in week five is archaeology.

Have a single expected difference between Stripe and the books, explained and stable. An unexplained variance that moves each month means the mapping is wrong somewhere.

Check the clearing account balances to near zero after each payout settles, which is the fastest available test that the whole thing is working.

Close the period and lock it, so late adjustments post forward with a reference rather than quietly changing a filed month.

Keep the exception list short and named. Disputes in progress, a currency conversion, a manual adjustment — three known items is fine and thirty is a system nobody trusts.

Hand your accountant the same report every month, in the same shape, since consistency is what makes a review quick.

Making it survive

Make posting idempotent, since a duplicated journal entry is a real problem and retries happen.

Never edit a posted period. Late adjustments post to the current period with a reference.

Alert on any unmatched amount rather than forcing a balance, because a silent plug is the worst outcome here.

Handle the negative payout, which occurs when refunds exceed charges and breaks most implementations.

Report the outcome: payouts posted, entries created, and any difference between Stripe and what was recorded.

Limits worth knowing about

QuickBooks API limits apply and a historical backfill will be slow.

Editing posted entries is constrained, and in a closed period it should not happen at all.

Multi-currency behaves differently between QuickBooks versions and regions.

Stripe's dashboard figures use its own definitions, which will not match your books exactly, and that difference needs explaining rather than resolving.

This is bookkeeping, not advice. The treatments here are common practice and your accountant's instruction governs.

What to build first

The mapping table: every movement type Stripe produces, with the account it should post to, agreed with your accountant before anything is connected. It takes an hour of their time, it is the thing every connector asks you for anyway, and it is what determines whether the integration produces quiet books or a manual reconciliation every month.

Two habits make the difference. Use a clearing account for funds in transit, since its absence is the single most common reason bank reconciliation fails on these integrations. And test against a closed month before running anything forward, because the errors here are silent — the books balance and the categories are wrong, and nobody finds out until year end.

Frequently asked questions

What decides whether this integration works?

The mapping from each Stripe movement to a QuickBooks account. A wrong mapping is silent — the books balance and the categories are wrong — and it is usually discovered at year end.

Which accounts do I need?

Sales revenue, processing fees as a separate expense, a clearing account for funds in transit, refunds as contra-revenue, disputes and their fees separately, sales tax as a liability, and currency conversion where applicable.

Why is a clearing account necessary?

Because money sits between the charge and the payout. Its absence is the most common reason bank reconciliation fails on these integrations, since nothing accounts for the funds in transit at a period boundary.

Should tax collected be posted as revenue?

No. It is a liability held on behalf of an authority. Posting it as income overstates revenue and creates a problem that is assessed later with interest.

Should I use a ready-made connector or build something?

For a business selling one kind of thing in one currency in one jurisdiction, a ready-made connector is usually right and considerably cheaper. Build when you have multi-currency, platform flows, custom revenue recognition, class or project tracking, or joins to your own data.

Should transactions post individually or summarised?

Summarised by payout, so one journal matches one bank line with the detail underneath. Per-transaction posting creates an unusable ledger at any volume and slows QuickBooks noticeably.

What happens with a negative payout?

It occurs when refunds exceed charges in a period, and it breaks most implementations. Handle it explicitly rather than discovering it during a bad month.

How do I verify the integration before trusting it?

Run it against a closed month and reconcile the output against what was actually filed. The errors are silent, so this is the only check that finds them before year end.

How often should I reconcile?

Weekly. A discrepancy found in the first week is traceable to a specific movement; the same discrepancy found at month end is archaeology, and it is usually resolved by a plug rather than an explanation.

What is the fastest check that the mapping is right?

The clearing account. It should balance to near zero once each payout settles, and a persistent balance means something is not being accounted for between the charge and the deposit.

Related reading

• Automating Stripe to accounting
• Connecting Xero to Stripe
• Connecting Stripe to Google Sheets