TC 672: Correction of TC 670 Processed in Error

What the code actually does

IRS Document 6209, Section 8A 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, 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 — Form 941 employment tax — 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 a payroll module is not describing a real correction.

The real mechanic: a corrected 670 becomes a 673, not a paired reversal

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." That is not describing two separate line items — a positive 670 sitting next to a negative 672 — it is describing the original TC 670 itself being converted into a TC 673.

The practical effect is that a module corrected this way may never display a bare TC 672 as its own permanent entry the way a typical reversal pair does. What a practitioner sees instead is 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 same payment, relabeled through the correction.

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. But because the mechanism can instead relabel the transaction as TC 673 rather than erase it, the money and its designation may still be sitting on the account — just under a code a practitioner has to know to look for.

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'" — an annual, calendar-year-end Form 941 period specifically — and it is barred from doc code 34 on top of that. A TC 672 purporting to correct a quarter-ending period on an employment tax module, rather than a year-end one, 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 TC 672 gets confused with

It gets confused with a dishonored payment. IRM 5.1.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 corrects a posting the Service itself got wrong.

It also gets confused 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.

The practitioner's actual next step

Before concluding a TC 670 disappeared, check whether a TC 673 now sits where it used to — that is very likely the same payment after a TC 672 correction, not a missing one.

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 the Service's posting was wrong, 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.