The QuickBooks Bank Rule That Recategorizes Stripe Deposits

Twenty-two Stripe charges on a Tuesday, totalling $8,410.00. Stripe takes $250.49 in processing fees and pays out $8,159.51 on Thursday. Your sync tool records the day correctly: $8,410.00 of income across itemized sales receipts, $250.49 to a Stripe fees expense account.

Then a bank rule you wrote eleven months ago sees a deposit whose description contains the word STRIPE, categorizes it to Sales income, and posts it without asking. Your books now report $16,569.51 of income for a day that earned $8,410.00.

Nothing errored. No sync failed. No transaction is missing. Every entry involved is real, and each one looks correct on its own. That is what makes this the single most common way a Stripe close goes wrong, and why it usually survives several months of review before anybody catches it.

This post is about the rule itself: what it can see, why it fires, why the standard advice to create it is exactly backwards on a synced file, and why the damage it does is shaped differently depending on which holding account you chose. If you already know you have this problem and just want it gone, our guide to preventing duplicate Stripe transactions covers the cleanup. This one covers the machine that keeps producing them.

Start a free trial and let Stripe payouts arrive in QuickBooks as records that match your bank feed instead of records that fight it.

What a bank rule can actually see

Most of what goes wrong here follows from one fact, so it is worth being precise about it before anything else.

Intuit's help article on setting up bank rules describes the condition builder directly: in the Conditions fields you specify whether the rule applies to Description, Bank text, or Amount, then select Contains, Doesn't contain, or Is exactly to decide how QuickBooks applies the rule.

Three fields. Three operators. Around them sit two scoping choices, Money in or Money out, and a bank account or All bank accounts. You can set a single rule with up to 5 conditions, and you can create up to 2,000 bank rules.

That is the entire vocabulary available to you, and the important thing about it is what is missing. There is no condition for where a transaction came from. There is no condition for whether the money it represents is already recorded somewhere else in your file. A rule is stateless with respect to the rest of your ledger: it looks at one incoming line, compares its text and its amount against your conditions, and acts.

A Stripe payout landing in your checking account is text and an amount. So is a refund from a supplier, a transfer between two of your own accounts, and a deposit from a second processor. If any two of those share a fragment of descriptor text, one rule claims both, and nothing in the mechanism will tell you it happened.

For the full anatomy of the object, including priority ordering and the limits, see our glossary entry on the QuickBooks bank rule.

The setting that turns a suggestion into a posting

Every rule carries an opt-in checkbox, and this is the one that decides whether you have a convenience or a liability.

Intuit labels it Automatically confirm transactions this rule applies to, and describes the effect plainly: with it enabled, any transactions on the For review tab that meet the conditions are automatically added.

Off, a rule is a data-entry shortcut. It pre-fills the category and the payee, the transaction still appears for review, and anything the rule got wrong is visible to you before it reaches your books. On, the rule is a posting mechanism that runs on the bank's schedule rather than yours. Whatever it gets wrong reaches your books first and is discovered later, if at all.

Both settings are defensible. A rule matching an exact recurring amount from a named vendor, with auto-confirm on, saves real time at close to zero risk. The test worth applying is simple: if this rule matched something it should not have, when would I find out? If the honest answer is "at month end" or "when the accountant asks", the rule should be suggesting rather than confirming.

On a Stripe deposit, the honest answer is almost always month end. That is the whole problem.

Why the standard advice is wrong here

Search for how to handle Stripe deposits in QuickBooks and you will be told, repeatedly and confidently, to set up a bank rule that categorizes them to income. For a business that records nothing else about its Stripe activity, that advice is defensible: the deposit is the only record you are ever going to have, so booking it to revenue at least gets money into the right neighbourhood.

On a file where an integration is already writing the sales, the same advice produces three separate errors that compound.

A payout is not revenue. Stripe's own payouts documentation describes the mechanism: Stripe sends funds from your available balance to your bank account as payouts. The earning already happened, at the charge. The payout is the money moving. Categorizing it to an income account records revenue a second time.

The amount is wrong even if the category were right. The $8,159.51 that arrives is the $8,410.00 you earned minus the $250.49 Stripe kept. Booking the deposit as revenue records net as gross, understates your top line, and loses the fee as a deductible expense at the same time. Two errors from one entry, pointing in opposite directions, which is part of why the net effect on the P&L can look plausible.

The rule cannot tell the difference, and cannot be taught to. The condition that would make this safe is "unless the sales behind this deposit are already in my file", and that condition does not exist in the vocabulary. This is the part that trips up people who try to engineer their way out: they narrow the descriptor, add an amount range, add a fourth condition. None of it helps, because the problem is not that the rule matches too much. The problem is that matching is the wrong operation entirely. The deposit should be matched to a record that already exists, not categorized as something new.

The damage has two different shapes

Here is the part that most treatments of this problem miss, and the reason it is worth understanding your own setup before you go looking.

What a Stripe payout looks like in QuickBooks depends on which account is standing in for your Stripe balance. Acodei's holding account is the account every synced sale is deposited into, and every payout is what moves money out of it into your real bank account. There are two ways to configure it, and they produce different documents.

With Undeposited Funds, a payout becomes an itemized Deposit that lists each charge, refund and fee it contains. That Deposit matches the bank line, and it shows its own composition.

With a regular asset clearing account, a payout becomes a single Transfer for the net amount, moving money from the clearing account to the bank. That Transfer matches the bank line, and the composition lives on the individual sales records instead.

In both cases the operative word is matches. There is already a record in QuickBooks for that payout. The intended action on the review tab is to tie the bank line to it. A rule that auto-adds the line does not just create a duplicate. It also prevents the match from ever happening, and what that costs you is different in each mode.

Under a clearing account, the balance tells on the rule

If your holding account is a regular asset account, the payout Transfer was supposed to draw the clearing balance down. When a rule adds the bank line as income instead, the Transfer sits unmatched and the clearing account never gets drawn down at all.

So the clearing balance climbs, by exactly one payout every payout, and it keeps climbing. That is a loud symptom, and it is loud in a place somebody is already looking. With a clearing account, the correct reconciliation method is balance reconciliation: the QuickBooks clearing balance should equal your Stripe balance. Comparing them daily is the gold standard and monthly is the minimum. Acodei has automated tracking built for exactly this comparison, scoped to non-Undeposited-Funds connections, fetching both balances into a daily record of whether the two match.

A rule quietly doubling your revenue will break that comparison on its first firing. You have a detector, it runs daily, and it is pointed straight at this failure.

Under Undeposited Funds, the rule removes the only checkpoint

Undeposited Funds works differently, and this is the case worth being careful about.

With Undeposited Funds, the reconciliation method is narrower by design: match each payout Deposit against the bank feed, then reconcile the bank account. Did the payout match, and is the amount right? If yes, the reconciliation work is done. Acodei does not support balance-reconciling the Undeposited Funds account itself, and the reason is timing rather than omission. Sales sit in Undeposited Funds until the payout deposit sweeps them, and some items are only added at deposit time, so a point-in-time comparison between that balance and your Stripe balance is not a meaningful test the way it is for a clearing account.

Read those two paragraphs together and the conclusion is uncomfortable. Under Undeposited Funds, the payout match is not one control among several. It is the entire reconciliation. And an auto-confirm rule on the payout line is a machine whose only function is to consume that line before the match can happen.

The rule does not merely create a duplicate here. It removes the one check that would have found the duplicate. That is why this configuration can carry the problem for months while a clearing-account file catches it inside a day, and it is the single best argument for looking at your rules list rather than waiting for a symptom.

How to tell whether this is happening to you

Four checks, cheapest first. None needs more than the QuickBooks UI.

1. Read your rules list. Go to the Rules page and look for anything scoped to Money in that could match a payment processor descriptor. Note which ones have auto-confirm enabled. Intuit states that the rule with the highest priority will always be applied first, so also check the order: a broad rule sitting above a narrow one claims transactions the narrow one was written for, which is why a rule you do not remember writing is frequently the one doing the damage.

2. Compare one day against Stripe. Pick a day with a payout. Total the income your books recorded for it and compare against the Stripe dashboard's gross volume for the same day. If your books read roughly gross plus net, you have found it.

3. Look at the Categorized tab, not the register. In Transactions, open Bank transactions and select Categorized. Stripe deposits that were added rather than matched will be sitting there with an income category on them. Deposits that were matched will name the record they matched to. Intuit's guidance on categorizing and matching downloaded transactions covers the distinction: where the transaction already exists in QuickBooks, you get the option to match it rather than to add it.

4. Check whether the sync's own payout records are unmatched. If you find itemized Deposits or Transfers for payouts sitting in the register with nothing tied to them, the bank lines they were waiting for went somewhere else.

If several months are involved and fees or refunds look wrong too, work through the complete cleanup playbook rather than fixing deposits one at a time. It sequences the repairs in an order that does not create new problems.

Fixing the rule is not the cleanup, and the order matters

This is the operational point that costs people the most time, and it follows directly from how rules are scoped.

QuickBooks applies your rules to transactions on the For review tab. That tab is the queue of what has arrived and not yet been dealt with. Rules do not reach back into transactions you already accepted. So:

• Deleting the rule stops the bleeding and repairs nothing.
• Cleaning up the entries repairs the past and stops nothing.

Doing the second without the first is the specific mistake worth naming, because it feels like progress and is not. You spend an afternoon recategorizing four months of deposits, and the next payout arrives on Thursday and the rule books it to income again.

Do them in this order:

1. Disable or delete the rule first. On the Rules page, the Actions dropdown offers Copy, Disable and Delete. Disabling is enough to stop it and leaves the definition in place if you want to look at it afterwards.
2. Then clean up what it already wrote. The mechanics of undoing a wrongly added deposit and matching it correctly are covered in our duplicate transactions guide, and the treatment differs depending on whether the period is closed.
3. Then re-check the next payout by hand. One deliberate match on the next payout confirms the rule is genuinely gone and that the matching path works.

One caution on closed periods. If some of the affected months are already closed, do not reopen them casually to fix deposits one by one. The month-end questions this raises are covered in our Stripe QuickBooks close checklist, and the choice between correcting in the current period and reopening a filed one is a conversation with your accountant, not a bookkeeping preference.

What duplicate protection does and does not cover

It is worth being exact here, because the name invites an assumption that is not correct, and acting on the wrong assumption is how this problem survives a review.

Acodei has a duplicate protection mechanism. With it enabled, the QuickBooks DocNumber on a synced record is set to the Acodei transaction id, so a re-sent webhook collides with the record that already exists rather than writing a second copy.

Read what that actually protects. It protects the records Acodei writes, from Acodei writing them twice. It is a collision on an identifier that Acodei puts there.

A record created by a bank rule from the bank side has a different origin and carries no such identifier. It is not something that mechanism can see, and no setting on the sync side changes that. This is genuinely a two-system problem: the sync did its half correctly, the rule did its half correctly, and neither is aware of the other. Nothing on the Acodei side detects, disables, or works around QuickBooks bank rules, and you should be sceptical of any tool that claims otherwise, because a rule is a QuickBooks object acting on the QuickBooks side of the bank feed.

The corollary is the useful one. Removing a rule's output is QuickBooks-side work, because it is not an Acodei record. Where a record that Acodei wrote needs rebuilding, the tool for that is the Data Feed, which is the ledger of every synced, pending and errored transaction with its status and error message. The documented action there is to resync rather than to hand-edit the QuickBooks record, because manual edits break the linkage Acodei uses for reconciliation and reversal. Knowing which of the two you are looking at saves the wrong repair.

Where a bank rule is still worth having on a Stripe file

None of this is an argument against bank rules. It is an argument against one specific rule.

Rules remain genuinely useful on the same file, for lines nothing else is recording:

• Your monthly Stripe Billing subscription fee, if you pay for one, going to a software expense account.
• Bank charges from your own bank, which no processor integration will ever record.
• Payouts from a second processor you have not integrated, where the deposit really is the only record you are going to get.
• Recurring vendor payments with stable descriptors and stable amounts, which is the case the feature was designed for.

The distinction is not "rules are dangerous". It is that a rule should record something, and a Stripe payout on a synced file is already recorded. Reserve rules for lines that would otherwise be invisible, and leave the ones that have a match waiting for them alone.

FAQ

Should I create a bank rule for Stripe deposits in QuickBooks?

Not if an integration is already recording your Stripe sales. The payout is money you have already earned arriving net of fees, so categorizing it to income records revenue that is either duplicated or wrong by the amount of the fees. The intended action is to match the payout to the record the sync already wrote, and a rule with auto-confirm enabled prevents that match from ever being offered.

Why does my QuickBooks income look higher than my Stripe gross volume?

Because the same money has been recorded twice, once as the sales and once as the deposit. It is the signature of this problem: the books read roughly gross plus net for the period. Compare a single day first rather than a month, because one day is small enough to reconcile by eye.

Will deleting the bank rule remove the duplicate entries it created?

No. QuickBooks applies rules to transactions on the For review tab, so a rule change affects what arrives from now on and does not revisit anything already accepted. Deleting the rule and cleaning up its output are two separate jobs, and the rule has to go first or the cleanup gets refilled.

Does the problem depend on how my holding account is set up?

The duplicate happens either way. How quickly you are likely to notice does depend on it. With a regular clearing account, the payout Transfer never draws the balance down, so the clearing balance climbs and a daily balance comparison catches it. With Undeposited Funds, matching each payout on the bank feed is the whole reconciliation, and an auto-confirm rule consumes exactly that line, so the failure removes its own detector.

Can a bank rule be written so that it only fires when the money is not already in my books?

No. Rule conditions match on Description, Bank text or Amount, and none of those can express a question about the rest of your ledger. Narrowing the conditions reduces how often the rule misfires and does not change what it does when it fires.

Can I keep any rules on the bank account my Stripe payouts land in?

Yes. Scope matters more than the account. A rule limited to Money out, or to descriptors that have nothing to do with your processor, does not touch payout lines. What to avoid is a broad Money in rule on All bank accounts, which is the shape most likely to claim a deposit you meant to match.

Stop the review tab from being the weak point

A bank rule that auto-adds Stripe deposits is a small piece of automation doing exactly what it was told, in a file where what it was told is wrong. The fix is structural rather than clever: the payout should arrive with a record already waiting for it, and your job on the review tab should be to confirm a match rather than to make a decision.

Acodei writes your Stripe sales, refunds and fees into QuickBooks and books the payout against the holding account, so every payout arrives on the bank feed with a record already waiting to match it, and the review tab becomes a checkpoint instead of a place where revenue gets invented. For the wider reconciliation workflow this sits inside, see our guide to reconciling Stripe to QuickBooks Online.

Start a free trial and give your Stripe payouts something to match.