TC 672: Correction of TC 670 Processed in Error

What the code actually does

IRS Document 6209, Section 8A (the IRS’s reference guide to its data-processing codes) titles TC 672 "Correction of 670 Processed In Error" and defines it as reversing "a 670 in whole or in part by debiting the module." Where TC 670 credited a subsequent payment onto the module (the record for one tax type and period), TC 672 is the Service pulling some or all of that credit back because it posted incorrectly.

The same entry restricts where it can appear: on MFT (Master File Tax account type) 04 it is "only valid for tax periods subsequent to 199412," the tax period "must end in '12'," and it "is not valid with doc code 34." A TC 672 that fails those conditions on an MFT 04 module falls outside the conditions the entry states.

The real mechanic: a corrected 670 becomes a 673

Reading a transcript literally here will mislead. Doc 6209's very next entry after TC 672 states: "input of a TC 672 changes an existing TC 670 to TC 673." The same chart defines TC 672 as reversing "a 670 in whole or in part by debiting the module," so the correction does two things: it debits the module, and it converts the original TC 670 into a TC 673.

The practical effect is that a practitioner sees a TC 673 standing where the TC 670 used to be. Read cold, that can look like an entirely different payment appeared from nowhere, when in fact it is the original payment, relabeled because the TC 672 reversed it.

That matters most on an employment tax account, where the designated payment code riding with the original TC 670 decides whether money reduced a responsible person's Trust Fund Recovery Penalty exposure under IRC §6672. A TC 672 correcting a genuinely misposted payment removes it from the module entirely. The relabeled TC 673 marks the payment the TC 672 reversed; the TC 672 debit takes the money, in whole or in part, off this module, so trace where it went, and its designated payment code, before counting the TC 673 as a payment still on the account.

The MFT 04 restriction is tighter than it looks

Doc 6209's MFT 04 condition for TC 672 is more specific than the parallel rule on the with-the-return side. TC 672 requires not just a tax period after 199412, but one whose period "must end in '12'" — a period ending in 12 specifically — and it is barred from doc code 34 on top of that. A TC 672 purporting to correct a period that does not end in 12 does not fit the pattern Doc 6209 describes.

That narrower condition is worth checking before treating an odd-looking TC 672 as unexplained rather than miscoded. A transcript anomaly on MFT 04 is often easier to resolve by testing it against this specific period-ending and doc-code combination than by assuming the posting itself is wrong.

What people mistake TC 672 for

People confuse it with a dishonored payment. IRM 5.1.2.6.2 names a separate, specific code for that: TC 671, "Subsequent Payment Check Dishonored." A bounced check reverses a TC 670 through that mechanism and can carry its own penalty consequence; TC 672 has nothing to do with a bad check — it is the debit side of a correction or credit transfer; the payment went to the wrong module, date or payment type, whether through an IRS posting error or the taxpayer's own misdirection (IRM 21.5.8, Exhibit 21.5.8-1).

People also confuse it with its counterpart on the with-the-return side. TC 612 does for a TC 610 exactly what TC 672 does for a TC 670, and both share the general 199412 cutoff on MFT 04 — but TC 672 carries the additional period-ending-in-"12" condition TC 612 does not, so the two codes' MFT 04 rules are not identical and should not be assumed interchangeable just because the last two digits match.

What to do next

Before concluding a TC 670 disappeared, check whether a TC 673 now sits where it used to — that is the same payment after a TC 672 correction, which debited it off the module in whole or in part; trace where it went.

Where the module shows a TC 673, trace its designated payment code the same way you would for the original TC 670; the relabeling does not on its own tell you whether the trust fund designation survived.

Distinguish this from a dishonored check before advising a client: TC 671 means the payment failed, TC 672 means a correction or credit transfer of the payment, whoever caused the misposting, and they call for different conversations.

On MFT 04 modules, confirm the tax period and doc code against Doc 6209's restrictions before treating an odd TC 672 entry as unexplained.

Reconstruct the full sequence with the IRS Transcript Decoder rather than reading a TC 672 or TC 673 as a standalone event.