TC 651: Dishonored Federal Tax Deposit
By Forrest Baumhover, CFP®, EA · Last verified September 9, 2026
TC 651 means a federal tax deposit bounced — and because deposit timeliness is judged by the deposit schedule, not the return's due date, a client can face both a bad-check penalty and a separate Failure to Deposit penalty from a single returned check.
What the code actually does
IRS Document 6209, Section 8A defines TC 651 as reversing "a dishonored payment submitted as a Federal Tax Deposit," scoped to employment and excise-tax MFTs (Master File Tax account types) 01, 03, 09, 10, 11, 12, 14, and 16 — the same family TC 650 posts against.
The penalty consequence follows the same pattern as every dishonored-payment code in this batch: "if not accompanied by a secondary a TC 280, a TC 286 systemically generates."
Two penalties can stack from one bad check
This detail is easy to miss. A dishonored federal tax deposit is not just a returned-payment problem under IRC §6657; it also means the deposit, as of the date it bounced, was never actually made on schedule — which can separately trigger the Failure to Deposit penalty under IRC §6656 the deposit was supposed to satisfy in the first place, on top of whatever the bad-check penalty itself adds.
The two penalties rest on different statutes and different reasonable-cause standards. Treating a TC 651 as a single bad-check event, and stopping there, misses the second exposure: the Failure to Deposit penalty scales with how many days late the deposit ultimately was, rather than being a flat charge like the bad-check penalty, so the two together can add up to more than either one alone. Building a reasonable-cause case for one penalty without addressing the other leaves real exposure on the table. A fact that excuses the dishonored check, such as a bank processing error, does not automatically excuse the underlying deposit being late. The two arguments need to be made separately.
Confirming the deposit schedule was actually missed
Not every dishonored deposit produces a Failure to Deposit penalty — if a replacement deposit was made within the schedule's own timing rules, or the employer qualifies for a safe harbor, the penalty may not apply at all. IRM 21.5.7.3.2 directs the same account-wide research used across this batch — CC (Command Code) IMFOL/BMFOL and the IAT (Integrated Automation Technologies) TC Search Tool, the internal command-code tools an IRS employee uses to reconstruct a payment history — to trace the full deposit and reversal timeline before assuming the worst case, since the timeline itself often determines whether any penalty applies at all.
Because TC 650 deposits can roll between adjoining tax periods, confirm which specific deposit actually bounced before assuming the current-period shortfall on the module (the account record for one tax period) is the dishonored one — a deposit that rolled forward before the dishonor posted can leave the wrong quarter looking short. Pulling the full transcript for both the current and adjoining periods, rather than relying on a single-period balance-due notice, is usually the fastest way to see which deposit the TC 651 actually reversed.
What TC 651 gets confused with
It gets confused with TC 652, the correction of a TC 650 posted in error made by the IRS itself. 652 corrects an IRS mistake and carries no automatic penalty; 651 reflects an actual returned payment and typically does.
It gets confused with a single, isolated penalty event. In practice it is often two: the bad-check penalty on the dishonored instrument itself, and a separate Failure to Deposit penalty on the underlying missed deposit.
It gets confused with the general "payment bounced" pattern seen in TC 611 or TC 621. The mechanism is identical, but only a dishonored FTD carries the deposit-schedule consequence layered on top.
The practitioner's actual next step
Separate the bad-check penalty analysis from the Failure to Deposit penalty analysis; they have different triggers and different reasonable-cause arguments, and conflating them in a single abatement request risks losing the argument that would otherwise have succeeded on its own.
Confirm with the bank why the deposit was dishonored, since a bank or EFTPS processing error can support both penalties at once under IRC §6657's own built-in good-faith/reasonable-basis exception — the more direct fit here than ordinary reasonable-cause abatement, consistent with the same exception TC 611 relies on — but document the reason in writing, since a verbal explanation from the bank rarely survives to the abatement request months later.
Check whether a timely replacement deposit was made after the dishonor, which can limit or eliminate the deposit-schedule penalty, and note the exact date it posted for the reasonable-cause narrative.
Reconstruct the full deposit history across adjoining periods before concluding which specific TC 650 the TC 651 actually reversed, since attaching the wrong deposit to the wrong reversal can lead to a reasonable-cause argument built on the wrong facts entirely.