QuickBooks Bank Rule

What a rule can actually see

A rule is narrower than most people assume, and knowing exactly how narrow is what makes the rest of this predictable.

In the Conditions fields you specify whether the rule applies to Description, Bank text, or Amount. Then you select Contains, Doesn’t contain, or Is exactly to decide how QuickBooks applies the rule. That is the entire vocabulary. There is no condition for the source of a transaction, no condition for whether something else in your books already accounts for it, and no way to ask whether a matching record exists elsewhere in the file.

Around the conditions sit two scoping choices. A rule is set to either Money in or Money out, and from the in dropdown you select a bank account, or select All bank accounts. Both are easy to leave broad, and a rule scoped to All bank accounts on Money in will look at every deposit that lands anywhere in the file.

The limits are generous enough that they are rarely the constraint. You can set a single rule with up to 5 conditions, and you can create up to 2,000 bank rules.

The practical consequence of that condition list is the boundary this whole entry turns on. A rule matches on text and amount. A Stripe payout arriving in your checking account is text and an amount. So is a customer refund, a transfer between your own accounts, and a deposit from a second processor. If two of those share a descriptor fragment, one rule claims both, and nothing about the rule mechanism will tell you it happened.

Priority, and which rule wins

Rules are not evaluated as a set of independent filters. They are ordered, and the order is a thing you control and are responsible for.

Intuit states the behavior plainly: the rule with the highest priority will always be applied first. To change it, you reorder your bank rules priority, select reorder and drag the rule to your desired order.

That sentence is doing more work than it looks like it is. It means a broad rule sitting above a narrow one will claim transactions the narrow rule was written for, and the narrow rule will look broken while being perfectly correct. The usual shape of this is someone writing a careful rule for one specific descriptor, watching it never fire, and concluding that rules do not work, when in fact a rule they wrote eight months ago and forgot about is matching on a two-word fragment above it in the list.

The discipline is the same one that applies to any ordered rule list: most specific at the top, broadest at the bottom, and treat a rule that matches on a short generic string as something that belongs near the bottom or does not belong at all.

Worth noting where the ordering does not reach. Rules are applied to what QuickBooks is about to show you for review. They do not reach back into transactions you have already accepted, so fixing a rule stops future damage and repairs none of the past.

Auto-confirm turns a suggestion into a posting

Every rule carries an opt-in setting labelled Automatically confirm transactions this rule applies to. Enabling it means any transactions on the For review tab that meet the conditions are automatically added.

This single checkbox is the difference between two very different objects. Off, a rule is a data-entry shortcut: it pre-fills the category and payee, you glance at the result, you click. Whatever the rule got wrong, you see before it reaches your books. On, the rule is a posting mechanism that runs without you, and whatever it gets wrong reaches your books first and is found later, if at all.

Neither setting is correct in general. Auto-confirm on a rule matching an exact recurring amount from a named vendor saves real time at near-zero risk. Auto-confirm on a rule matching a common descriptor fragment is a machine that writes entries you did not review into a period you will later have to reconcile.

The test worth applying before enabling it: 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.

Why the standard Stripe advice is the dangerous rule

Almost every general guide to Stripe bookkeeping arrives at the same recommendation, which is to set up a bank rule that categorizes your Stripe deposits to income. For a business hand-keying nothing and syncing nothing, that advice is fine. For a business whose Stripe activity is already being written into QuickBooks by an integration, it is precisely the wrong rule, and the reasons stack.

The first is that a payout is not revenue. A payout is a movement of money you have already earned, arriving net of fees. Booking it to an income account records income that either does not exist, because the sales are already recorded, or exists at the wrong amount, because the fees have been taken out of it and are now invisible.

The second is that a rule cannot distinguish these cases. It sees a deposit whose description contains a payment processor’s name. It has no way to ask whether the sales behind that deposit are already sitting in your file.

The third is the compounding one, and it is why this belongs in a definition rather than a troubleshooting note. If the rule has auto-confirm on, it does not create one wrong entry. It creates a wrong entry per payout, on the payout schedule, indefinitely, and each one looks entirely plausible in isolation: a real deposit, on a real bank statement, from a real payer. Cleaning up the entries without removing the rule means the rule refills them.

The correct handling on a synced file is not a better rule. It is the absence of one, so that each payout arrives on the review tab and can be matched to the record the sync already wrote, rather than added as something new.