Quickbooky

Accounting News

Banking & Checks

Handling a Bounced Check and Its Bank Fee in QuickBooks Online

A returned check in QuickBooks Online needs different handling depending on whether the bank covered it or the vendor redeposited it.

Handling a Bounced Check and Its Bank Fee in QuickBooks Online

QuickBooks Online users who write a check the bank then refuses for insufficient funds keep landing on the same fork: does the payment stay in the books, or does it come out? The accepted guidance on Intuit’s help pages answers with a split. The bank charge always gets its own entry, and the check itself only gets undone in some cases. Which case applies depends on what the bank and the vendor did next.

The problem a bounced check creates

A rejected check leaves records in QuickBooks Online that no longer match reality. The check sits in the register as a completed payment, and the vendor’s balance shows the bill as settled. Meanwhile the account never actually lost that money, and the bank added a charge of its own.

Users typically spot the mismatch during reconciliation, when a fee line arrives from the bank with nothing in the books to match it. Some spot it earlier, when a vendor asks to be paid again while the software still reports the original bill as closed.

Who gets billed for the fee?

One decision drives everything else: who the bank actually charged. If the fee landed on your own account, the payee on the fee entry should be the bank. If the bank added the fee to the vendor’s invoice instead, the payee should be the vendor. Getting this wrong quietly distorts the vendor’s balance, because the charge attaches to the wrong party. Settle it once, since the same rule applies in every scenario below.

Scenario 1: the bank covered the check

In the first case the bank honored the payment despite the shortfall and simply charged you for it. The check went through, so the payment record is correct and must stay. Only the fee needs an entry.

Create a new expense from the plus menu. Pick the payee using the rule above, then choose the account the charge came from. In the reference field, type something like NSF fee so the entry stays identifiable at reconciliation. Under category, select bank charges; if that account does not exist yet, create it from the same screen. Enter the amount, complete any other fields that apply, and save.

Scenario 2: the check came back unpaid and was not deposited again

In the second case the bank refused the check outright, and the vendor returned it without trying a second deposit. Now the books are wrong in two ways: they show a payment that never happened, and the fee still needs recording.

Void the check first. Open the expenses area, move to the vendors list, and select the vendor you paid. In that vendor’s transaction list, open the bounced check, choose Void from the More menu, and confirm. The transaction stays on file but no longer counts as money spent, and a bill the check was paying returns to unpaid.

Then record the bank charge exactly as described in scenario 1, with the same payee rule and the same reference label.

Void rather than delete. A voided transaction keeps its place in the audit trail, while a deleted one vanishes and leaves gaps that surface later at reconciliation.

Scenario 3: the check was deposited a second time

A third path gets less attention, and skipping it causes its own damage. Here the check bounced once, but the vendor or the bank deposited it again and it cleared on the second attempt.

Nothing gets voided in this case. The payment finally went through, so the original check stands exactly as written. Record the fee, again with the same payee rule, and stop there. If the second attempt also failed, you are back in scenario 2, and the void applies to that same check.

The trap works in both directions. Voiding a check that later cleared leaves a paid bill looking open. Leaving a dead check in place does the opposite, showing money as spent when the vendor was never paid.

Mistakes that make this worse

We see the same handful of errors around this issue. The fee gets recorded against the wrong payee, which skews the vendor’s balance. The reference field is left blank, so the charge looks like an ordinary bank cost months later. The check is deleted instead of voided, destroying the trail. Or the user voids first and asks questions after, without checking whether the payment actually failed for good.

The short version

The bank charge always gets its own expense entry; that part is constant. The check itself only comes out of the books when the payment truly failed and will not be attempted again. Work out which path your check took before touching the register, and the rest follows.

← Back to Community Issues