TC 522: Correction of TC 520 Processed in Error

What the code actually does

IRS Document 6209, Section 8A titles TC 522 "Correction of 520 Processed in Error" and describes it as a transaction that "indicates and reverses previously posted 520's as an error, and causes Closing Codes, if 70-89, to be updated to zeros." The freeze comes off, and the two-digit code that had defined which kind of litigation or bankruptcy proceeding it represented gets zeroed out along with it.

That zeroing detail is the tell. A genuine resolution leaves a record of what the closing code was, because the case that ran under it actually happened. Wiping the closing code to zero is what a correction does — the erroneous entry is being erased, not archived.

Doc 6209's "70-89" range spans two different manuals, and this page only covers one of them. As TC 520's own page establishes, closing codes 70-82 and 84 are the -W litigation band that IRM 25.3.8 governs; codes 83 and 85-89 are the -V bankruptcy band, which that same chapter explicitly excludes ("not covered in this IRM are -V Freezes... not a part of this IRM") in favor of the IRM 5.9 bankruptcy series. Everything below on this page — the "DO NOT INPUT TC 521" instruction, the Appeals two-way formulation, the matching-code table — is sourced to IRM 25.3.8 and applies to a TC 522 correcting a litigation-coded TC 520. A TC 522 correcting a bankruptcy-coded TC 520 is a separate IRM 5.9 matter this page does not cover.

The IRM says, in capital letters, not to confuse it with TC 521

IRM 25.3.8.2.2, *Incorrect Closing Code - What to Do*, is unusually direct about this exact mix-up: "when finding an incorrect Closing Code correct it by inputting or requesting input of a TC 522 to remove the TC 520," followed by a note, in the manual's own capitals: "DO NOT INPUT TC 521."

The instruction exists because both codes remove the same TC 520 freeze from a module, and a caseworker who reaches for the wrong one is recording the wrong history on the account. TC 521 is reserved for a freeze that was correctly posted and has now genuinely concluded; TC 522 is reserved for one that should never have posted, or whose closing code was wrong, in the first place.

It also covers Appeals reversing itself, not just data-entry mistakes

The correction is broader than a simple typo fix. IRM 25.3.8.5.2 and 25.3.8.5.3 both describe the same two-way choice facing Appeals when a Tax Court or Collection Due Process matter concludes: the closing action "could be either posting: TC 522 to correct an erroneous input or a case withdrawn or meeting Appeals criteria for a disregarded or non-processable case, or TC 521 to close the litigation freeze."

Read against that sentence, TC 522 covers three distinct fact patterns lumped under one code: a data-entry error, a case the taxpayer withdrew, and a case Appeals never actually took up as a properly processable matter. None of those three is "the litigation happened and concluded" — which is exactly what TC 521 is for — and a practitioner explaining a TC 522 to a client should not describe any of them as a resolved dispute.

What TC 522 gets confused with

The confusion runs in the direction the IRM is guarding against: reading TC 522 as a favorable outcome because the freeze is gone and the case is "closed." IRM 25.3.8.5 describes both TC 521 and TC 522 as returning the account so it can "reenter the business stream" — collection resumes either way — but only TC 521 means anything was actually decided.

It also gets confused with a partial correction. Doc 6209 notes that "some TC 522s require the matching Closing Code and others do not," so the presence of a TC 522 does not by itself tell a practitioner whether the specific closing code it removed needed to match the original TC 520's code or not — that detail lives in the litigation closing-code table this same IRM section maintains, not in the reversal transaction itself. IRM 25.3.8.2's own table names the closing codes where a match is actually required: 73, 76, 77 and 81. Outside that specific band, the correction does not have to reproduce the original code exactly to be effective.

Why the closing code matters even after it is gone

The closing code that TC 522 zeros out was carrying real information before the correction — which type of proceeding the freeze represented, and which of several IRM subsections governed it. A caseworker researching a module after the fact, or a practitioner trying to explain the account's history to a client, cannot recover that information from the corrected module alone; the transcript will show a TC 520 and a TC 522, and nothing about the closing code that briefly sat between them.

That is worth knowing before promising a client a full account history reconstructed purely from IDRS (the IRS’s internal Integrated Data Retrieval System) transcript codes. Where the specific type of the erroneous posting matters — for a fee dispute, a complaint about how a case was handled, or simply making sense of a confusing prior year — the underlying case file, not the transcript, is what still holds the answer.

The practitioner's actual next step

Do not describe a TC 522 to a client as a resolved case — treat it as evidence the freeze itself was the mistake, a withdrawal, or a case Appeals never took up.

Check which of the three fact patterns actually applies before advising on next steps, since a withdrawn case and a data-entry correction call for different follow-up with the client.

Confirm the account genuinely re-entered active collection rather than assuming a fresh freeze was substituted — TC 521 and TC 522 both end in the same status, but neither guarantees no other hold exists on the module.

Where a matching closing code was required for the correction, verify the removed code actually lines up with the original TC 520 before treating the module as clean.

Reconstruct the litigation history in sequence with the IRS Transcript Decoder rather than reading TC 522 in isolation.