Splitting Stripe Payouts by Product in QuickBooks

The question arrives in support tickets in almost exactly these words: how do we assign Stripe payouts to different Chart of Accounts accounts based on the product purchased?

It is a completely reasonable thing to want. You sell three things, you want three revenue lines in QuickBooks, and the payout is the number you can see sitting in your bank feed. So the payout looks like the thing to split.

It is not, and the reason is worth understanding rather than working around. A Stripe payout has no product dimension. Not because the feature is missing, but because by the time a payout exists, the individual sales that produced it have already been netted into a single balance. Asking the payout to carry product detail is asking the wrong record to do it.

The good news is that the split you want is real, supported, and happens one layer down. This post covers where that layer is, what the payout record can and cannot tell you in each holding-account mode, and the one configuration where an account-level dimension genuinely does route revenue to different QuickBooks accounts.

Ready to stop hand-splitting deposits? Start a free trial and see where your Stripe revenue actually lands.

What a payout is by the time it reaches your books

A Stripe payout is one settlement movement: an amount of your Stripe balance going to your bank account, which is all Stripe's payouts documentation describes it as. Acodei processes each payout with its own job when the payout.paid event arrives, after that payout's balance transactions have been fetched from Stripe.

That last detail is the important one. A payout is assembled from balance transactions. The charges, the refunds, the fees, and any uncommon activity that happened in the window are all balance transactions, and the payout is what is left when they are summed. The sale of a $79 plan and the sale of a $1,200 annual license do not survive into the payout as separate facts. They survive as arithmetic.

So when you look at a $5,664.80 deposit in your bank feed, you are looking at a number with no seams in it. Consider a day that produced:

Activity	Amount
Pro plan sales	$4,000.00
Starter plan sales	$1,500.00
Setup fee sales	$600.00
Stripe processing fees	($185.20)
One refund	($250.00)
Payout to bank	$5,664.80

There is exactly one thing in that table your bank feed knows about, and it is the bottom row. Every product distinction lives in the rows above it, which is the entire point: the segmentation you want already happened, earlier, on records that still had product identity. The payout is downstream of it.

The record that carries product identity

The record with a product on it is the sales record Acodei creates when the charge or invoice syncs, and the thing that decides which product goes on it is product mapping.

When a Stripe event arrives, Acodei's mapping engine walks your configured rules from top to bottom. The moment a rule matches, it stops searching and uses that rule to determine the QuickBooks Product/Service, and with it the linked income account. That parenthetical is the whole mechanism you are looking for. You do not map revenue to an income account directly. You map it to a QuickBooks product, and the product points at the account.

From the matched product, Acodei creates or updates the corresponding Sales Receipt, Invoice, or Payment in QuickBooks. If your setup is invoice-based, the line items on the invoice reflect the mapped product. In a sales-receipt flow, each sales receipt line references the matched product. The mapping logic is identical either way.

If no rule matches, one of two things happens depending on your configuration: the transaction falls back to a single catch-all product, or it throws a sync error, if your configuration disallows uncategorized items.

So the chain from a customer's card to a line on your profit and loss runs:

1. Stripe charge or invoice arrives.
2. A mapping rule matches and resolves one QuickBooks product.
3. That product carries a linked income account.
4. The sales record posts, and revenue lands in that account.
5. Later, separately, a payout moves the cash.

Steps 2 through 4 are where a segmented profit and loss is built. Step 5 cannot contribute to it, because step 5 has no products in it. For the mechanics of the six matching techniques and how to choose between them, what Multiple Product Mapping actually does covers the rule types in detail, and the amounts product mapping cannot reach covers the lines that have none of the properties a rule can read.

Why both facts are true at once: the holding account

The reason revenue and cash can separate cleanly is the holding account, which is the QuickBooks account that stands in for your Stripe balance. Every synced sale is deposited into it, and every payout moves money out of it into the real bank account.

Every Sales Receipt Acodei creates carries the resolved holding account as its deposit-to account, and so does every standalone Payment. That is the join. Revenue is recognized against products and income accounts when the sale syncs, the money sits in the holding account, and the payout later sweeps it to the bank without touching revenue at all.

Once you see it this way, the original question dissolves. The payout does not need a product dimension because it is not a revenue event. It is a cash movement between two accounts you own. The chart of accounts a Stripe business needs walks through which accounts have to exist for this to work, and the holding account covers the choice itself.

What the payout record shows, and it depends on your mode

Here the answer stops being uniform, because the shape of the payout record follows from your holding-account mode, and one mode does show mapped products on the payout.

Non-UF, an asset clearing account. Each payout becomes a single QuickBooks Transfer from the holding account to the mapped deposit bank account, for the payout's net amount. One record, one number, no line detail. Composition lives on the sales records.

Undeposited Funds. Each payout becomes a QuickBooks Deposit that itemizes the underlying activity, charges, refunds, fees, and mapped uncommon transaction types, out of Undeposited Funds into the bank account. Those lines are built from the payout's balance transactions, grouped by type and mapped product.

Read that last clause carefully, because it is the closest thing to a yes in this entire post, and it is narrower than it looks. A UF deposit does group lines by mapped product. But the products doing that grouping for uncommon activity come from Balance Transaction Mapping, which is the mapping surface for disputes, reserves, Connect transfers and similar types appearing inside a payout. It is not your sales product mapping producing a product-level revenue breakdown. The charge lines in a UF deposit are the individual payments being swept, and those payments already carry their own products from when they synced.

Two other differences matter if you are choosing a mode with reporting in mind:

• A UF deposit can only be built if every underlying transaction already exists in QuickBooks. Missing ones block the payout with a mismatch error and are recorded for retry.
• Under UF, some items are only added at deposit time, including deferred fees and mapped uncommon types.

That timing difference is also why reconciliation differs. With Non-UF, the correct method is balance reconciliation: the QuickBooks clearing-account balance should equal the Stripe balance, and because every sale, fee and payout posts against it as it happens, the two can be compared daily, which is the gold standard. With Undeposited Funds, the method is payout matching only: match each payout Deposit against the bank feed, then reconcile the bank account. Acodei does not support balance-reconciling the Undeposited Funds account itself, because sales sit in UF until a payout sweeps them and the balance can legitimately diverge from the Stripe balance at any given moment.

Neither mode changes where revenue segmentation happens. It changes only how much composition the cash record displays.

The one dimension that does route products at account level

There is a real exception, and it is worth knowing because it is the only case where something payout-adjacent genuinely decides which income account revenue lands in.

If you run multiple Stripe accounts, Acodei can map products by Stripe account ID. One account's transactions can resolve to a "Consulting Service" product in QuickBooks while another account's resolve to "Merchandise". Multi-account setups also commonly want separate deposit accounts and holding accounts per Stripe account, and the deposit bank account is itself assigned in Account Mapping per Stripe account, and per currency for multicurrency users.

Holding-account resolution follows the same shape, in order: the connection default, then per Stripe account where multiple holding accounts are enabled, then per currency when multicurrency is on and the Stripe account is flagged multi-currency.

The practical consequence is worth spelling out. Each Stripe account pays out separately, each can have its own deposit account, and mapping keyed on the Stripe account sends its revenue to its own QuickBooks product. That combination is the closest anything gets to "split my payouts by product," because the separation runs all the way through.

That is a real answer, but notice what makes it work. It is not the payout carrying product detail. It is the account being the dimension, upstream of both the payout and the product. If your revenue streams are genuinely separate businesses already running on separate Stripe accounts, you get the separation for free. If they are three products inside one Stripe account, spinning up extra Stripe accounts to get reporting is the wrong tool, and rule-based mapping on the charge is the right one.

What to actually do

If the goal is a profit and loss that breaks out revenue by product, the work is at the charge, and it is mostly QuickBooks-side setup done in the right order.

1. Create the QuickBooks products first, pointed at the income accounts you want. The product is what carries the account, so the account assignment is a property of the product, not of the mapping rule. Intuit's guide to adding product and service items and changing the account for a product or service cover both steps.
2. Keep every mapping product non-taxable. All QuickBooks products used in Acodei mapping must be marked as non-taxable. Tax calculated by Stripe syncs through the Stripe Tax feature instead, and making products taxable in QuickBooks conflicts with sales and payout math.
3. Write rules specific-first. The engine stops at the first match, so a broad rule sitting above a specific one will intercept transactions meant for the specific one.
4. Decide what happens to unmatched transactions. A catch-all product keeps sync flowing and quietly pools revenue. A sync error stops the transaction and makes you look. For product-level reporting, an error is usually the more honest setting, because a catch-all is invisible in a report that looks complete.
5. Reconcile the payout as one cash movement. Do not try to decompose it into revenue. Stripe payout reconciliation covers the mechanics end to end.
6. Build the reports on the QuickBooks side. Once products point at the right income accounts, the segmentation is a reporting question. Managing multiple revenue streams in QuickBooks covers the report customization.

Three traps worth knowing before you build this

Mapping changes are not retroactive. Mapping rules are not versioned, and a change takes effect for future transactions only. Fixing a rule today does nothing to the six months of revenue already sitting in the wrong income account. Plan the product list before volume accumulates, not after a quarter-end report looks wrong.

Refunds do not always return to the product they came from. Partial and full refunds route differently depending on whether the original invoice had one line or several, and multi-line cases land on the Default Refund Product rather than the original. There is an admin setting to always send refunds to the default refund product, which is generally recommended for clean accounting, because netting refunds against original products leaves gross revenue in QuickBooks lower than actual gross revenue. If your product-level revenue looks slightly off in a month with returns, this is usually why. Stripe charges mapped to the wrong QuickBooks product covers the diagnosis.

Fees are not part of this at all. Fees, including instant-payout fees, and non-payout balance activity are captured on the Daily Balance Summary rather than on the payout record. Where a payout's own balance transaction does carry a fee, it is recorded against your Stripe fee product. Either way, fees are an expense with their own account and never a reduction of a product's revenue line.

If you want a second reporting axis on top of products, classes are the other dimension, and QuickBooks class tracking for Stripe revenue covers how a label reaches the record rather than which account it lands in.

Frequently asked questions

Can I assign Stripe payouts to different income accounts by product?

No, and the payout is the wrong record for it. A payout is one settlement of a netted balance, assembled from the balance transactions in its window, so the individual product-level sales no longer exist as separate facts by the time it is created. The split happens earlier, when the charge or invoice syncs and product mapping resolves a QuickBooks product with a linked income account.

Where does the product-to-income-account link actually live?

On the QuickBooks product, not in Acodei. A mapping rule resolves a QuickBooks Product/Service, and that product carries the linked income account. So changing which account revenue lands in is done by repointing the product in QuickBooks, and changing which revenue goes where is done by editing the mapping rule.

Does Undeposited Funds show product detail on the payout?

Partly, and not the part most people want. A UF payout becomes an itemized Deposit whose lines are built from the payout's balance transactions, grouped by type and mapped product. The products grouping uncommon activity come from Balance Transaction Mapping, for types like disputes, reserves and Connect transfers. Sales revenue was already recorded with its own products when each payment synced.

Will fixing my mapping rules correct revenue that already synced?

No. Mapping rules are not versioned and changes apply to future transactions only. Existing records keep the product they were given at sync time.

I have several Stripe accounts. Can revenue from each go to a different income account?

Yes. Acodei can map products by Stripe account ID, so one account's revenue can resolve to one QuickBooks product and another account's to a different one. Multi-account setups can also have separate deposit and holding accounts per Stripe account, and the deposit bank account is assigned in Account Mapping per Stripe account.

What happens to a Stripe charge that matches no mapping rule?

One of two things, depending on your configuration. It falls back to a single catch-all product, or it throws a sync error if your configuration disallows uncategorized items.

Do the QuickBooks products I map to need any particular setup?

They must be non-taxable. Every QuickBooks product used in Acodei mapping is required to be marked non-taxable, because taxable products conflict with sales and payout math. Stripe-calculated tax reaches QuickBooks through the Stripe Tax feature instead.

Why does my payout not equal my revenue for the day?

Because a payout is net and revenue is gross. Fees and refunds are subtracted inside the payout, and fees are recorded as an expense on the Daily Balance Summary rather than as a reduction in revenue. Revenue is recognized when the sale syncs into the holding account, and the payout is a later movement of cash out of it.

The short version

The payout is the last record in the chain and the only one with no product on it. Every record before it has one, which is why the answer to "split my payouts by product" is to stop looking at the payout and go set up the products the charges map to.

Get the QuickBooks products right, point them at the income accounts you want, order the rules specific-first, and the segmented profit and loss appears on its own. The payout stays what it should be: one line of cash, matched once, in the bank feed.

Start a free trial and map your Stripe revenue to the accounts you actually report on.