TC 472: Reversal of TC 470 — Only If the Closing Code Matches

What the code actually does

IRS Document 6209, Section 8A titles TC 472 "Reversal of Taxpayer Claim Pending" and describes it plainly: it "records that a TC 470 was processed in error. Reverses TC 470." Whatever TC 470 had frozen — collection, notices, or both, depending on that code's own closing code — comes off when this one posts correctly.

On IMF (Individual Master File), Doc 6209 adds that TC 472 "permits normal issuance of TDA/BAL DUE" — a Taxpayer Delinquent Account moving into balance-due collection status — "whenever no adjustment is to be input"; the account resumes the collection-notice track it was on. But the next notice depends on where that track was, not on a fresh start: "next notice or TDA/BAL DUE issued is dependent on the status when TC 470 was input to module." A client whose account was already deep into the notice stream before the freeze went on picks back up from there, not from the beginning.

The closing code has to match

This is the detail that actually matters on a transcript, and Doc 6209 states it as a firm requirement rather than a suggestion. "Input of Collection Closing Code 99 is required to reverse a TC 470 with Closing Code 99. Closing Code 94, 95 or 96, 98, 99 required to reverse TC 470 CC 94, 95 or 96, 99 respectively. Closing Code 98 required to reverse TC 470 CC 98." Read plainly, each closing code on the original 470 needs the identical code on the 472 that reverses it — a 470 CC 95 is reversed by a 472 CC 95, a 470 CC 99 by a 472 CC 99, and so on down the chart.

CC 97 — the Large Corporate Account offset freeze — works the same way, and IRM 21.5.6.4.7 states its specific release mechanic — "manual input of TC 472 cc 97 by designated BMF Adjustment employees, or automatic release after the 52-cycle systemic hold" — using BMF, the Business Master File, to mean the business-account side of the reversal. A TC 472 with no closing code, or the wrong one, does not touch a CC 97 freeze at all.

The practical consequence is that a bare "TC 472 posted" line does not tell a practitioner the freeze actually lifted. A transcript can show a 470 and a 472 in sequence and still leave the original hold standing if the two closing codes do not correspond, which is exactly the kind of mismatch that makes this pair easy to misread.

It doesn't touch the collection statute

IRM 5.1.19.2.2, the IRM's own canonical list of transaction codes that suspend or extend a Collection Statute Expiration Date (CSED), does not include TC 470 under any closing code. Doc 6209's TC 472 entry gives its reversal no CSED effect either. The two facts point the same direction: whatever a TC 470/472 pair is doing to notices or collection activity, it is not tolling the statute along the way, and a practitioner should not build a CSED calculation around either code without a separate transaction — commonly a TC 550 — that actually states one.

What TC 472 gets confused with

It gets read as proof the underlying claim was resolved in the taxpayer's favor. It is not. Doc 6209's own language is "processed in error" — the code corrects a mistaken freeze, and says nothing about whatever pending matter the TC 470 was originally protecting. A real, correctly-input TC 470 is not touched by this code at all; only an erroneous one is.

It also shows up as routine housekeeping inside a much bigger event rather than as news on its own. IRM 5.19.7.15, Processing Defaulted OICs, instructs examiners to "research all tax modules on the offer for an unreversed TC 470 prior to input of TC 781" and to "input TC 472 to reverse any unreversed TC 470" as one step in defaulting a compromise. A TC 472 appearing right before a TC 781 is not a separate, good-news event — it is IRS staff clearing an unrelated hold so the default itself can post cleanly.

The practitioner's actual next step

Read the closing code on the original TC 470 before assuming any TC 472 reversed it — match the two codes rather than the two transaction dates.

Where the closing code is 97, confirm the account actually carries Large Corporate Account status through the Practitioner Priority Service line before advising on the freeze at all.

Do not build a CSED calculation around this pair — neither code appears on the IRM's own list of statute-suspending transactions.

If the TC 472 sits immediately before a TC 781 on an Offer in Compromise (OIC) module, read it as default housekeeping rather than as relief on the original claim.

Confirm the resumed notice or balance-due track against the account's status before the freeze, since the IRS resumes from there, not from zero.