TC 272: Failure to Pay Penalty Restriction Deletion
By Forrest Baumhover, CFP®, EA · Last verified September 7, 2026
TC 272 carries no money and does one thing — switches the failure-to-pay penalty computation back on after a manual entry froze it. On an account where the tax stayed unpaid, that can make the balance go up rather than down.
What the code actually does
TC 272 is a state change, not a transaction with an amount. IRS Document 6209, Section 8A describes it in one line: it “removes restriction on computation of FTP Penalty on previously posted TC 270 or 271. Causes recomputation and allows normal computation of Failure to Pay Penalty.” IRM 20.1.2.2.5 lists it as “TC 272—removal of computation restriction of the penalty for failure to pay,” directly beside its late-filing twin, “TC 162—removal of computation restriction of the penalty for failure to file.”
The reason it exists is that the codes it cleans up are self-restricting. Posting a manual TC 270 restricts penalty computation on the module, and a TC 271 input without Reason Code 062 does the same. Once either has happened, the failure-to-pay penalty on that account stops updating on its own, and nothing short of a TC 272 will start it again.
When it is the right request
IRM 20.1.2.2.4.1 gives the operative instruction and it is narrower than “the module is restricted”: “input TC 272 with a zero amount to remove the manual restriction on the FTP penalty when a module has been restricted in error.” The predicate is error. The IRM’s general posture supports pressing on that where it fits — IRM 20.1.2.2.5 states that because the systems usually compute these penalties correctly, “it is important that taxpayer accounts are not unnecessarily restricted from systemic penalty computation.” A restriction that was a side effect of an abatement rather than a decision about the account is the clearest candidate.
The most frequent version of that in practice is an omitted reason code. Where a client paid the tax in full and won a reasonable-cause abatement, the IRM directs that the abatement be input as a TC 271 with RC 062 precisely so the module keeps computing. If RC 062 was left off, the account is now restricted for no substantive reason, and asking for a zero-amount TC 272 is asking the IRS to undo an input defect rather than to reconsider the merits — a materially easier conversation, and one that does not put the abatement itself back in play.
Why it can raise the balance
This is the part to check before requesting anything, because a restriction is not always working against the client. Doc 6209 says a TC 272 “causes recomputation” and “allows normal computation” of the penalty. On a module where the tax remains unpaid, the failure-to-pay penalty has been frozen for however long the restriction has been in place, and normal computation means the system catches up.
That is exactly the situation IRM 20.1.2.2.4.1 contemplates when it describes the restricting form of an abatement as appropriate where the taxpayer qualifies for relief but the underlying tax has not been paid, there is no reasonable expectation of payment soon, and the circumstances are expected to persist. For that client the restriction is the relief — it is what stopped the penalty from growing. Lifting it because the account “looks wrong” would convert a deliberate protective posture into a live accrual. So the first question is never whether the module is restricted; it is whether the restriction was an error or a decision.
What TC 272 gets confused with
TC 272 gets confused with TC 271, because both appear on the same module in the same family and both are described loosely as fixing the penalty. They are not alternatives. TC 271 abates a dollar amount and may itself impose the restriction; TC 272 abates nothing and only removes one. A client whose penalty is too high needs a 271; a client whose account has stopped computing needs a 272; a client whose abatement was input without RC 062 needs the 272 and not a second 271.
It is also read as though it reversed the abatement it follows, which is understandable — a code that “causes recomputation” sounds like it might recompute the penalty back into existence. It does not disturb the abated amount. What it does is resume forward computation, so any increase after a TC 272 is new accrual on unpaid tax rather than a reinstatement of what came off. The genuine reinstatement risk on this family is separate: the IRM permits a reasonable-cause abatement to be reasserted in full where the taxpayer willfully continued in the failure to pay.
The practitioner’s actual next step
Confirm the module is actually restricted before anything else, and identify which entry did it — a manual assessment or an abatement missing its reason code.
Decide whether the restriction is helping the client. Where the tax will not be paid, a frozen penalty is a benefit and a TC 272 would end it.
Where the restriction was an input defect on a paid-in-full account, frame the request as error correction under the IRM’s own instruction rather than as a request for relief, and ask specifically for a zero-amount TC 272.
Model the catch-up accrual before requesting the deletion on any account with an unpaid balance, so the client is not surprised by a larger number after a change made on their behalf.
Verify the state actually changed afterwards with the IRS Transcript Decoder, and re-check the failure-to-file side of the module separately, since a parallel restriction there needs a TC 162 rather than this code.