TC 342: Interest Restriction Deletion

What the code actually does

TC 342 carries no money. IRS Document 6209, Section 8A titles it “Interest Restriction Deletion” and describes its single function: it “removes restriction on the computer computation of interest set by a previously posted TC 340 or 341, and allows the computer to recompute normal interest.” It “can only be input for 0 amount.” Everything else on a transcript in this family moves a dollar figure; this one changes a state. After a TC 342 posts, the module is computing its own interest again, the way an ordinary account always was.

That makes it the code a practitioner wants on a client who has been living with a restricted module — because on a restricted module, interest only updates when a human remembers to update it, and the balance a client is quoted can be months out of date in either direction.

The prerequisite is the whole story

A TC 342 is not available on request, and understanding why is the difference between a productive conversation and a wasted one. Doc 6209 states the gate directly: “TC 342 may not be input without first securing the source document for the TC 340/341 and making the determination that the TC 340/341 was unnecessary.” It repeats the point as a caution — the code “should not be used without first determining interest should not be restricted.” IRM 20.2.1.4.1 frames the same requirement from the employee’s side, listing among the ways to facilitate systemic computation “determining whether the input of a prior TC 34X on a tax module, barring IRS computer systems from calculating interest, was warranted,” and pointing at IRM 20.2.5.6.2 for “requirements that must be met before inputting TC 342.”

Read together, those impose two conditions, and the first is often the harder one. Somebody has to physically locate the original computation behind the TC 340 or TC 341 — a document that may be years old and held in files rather than on the system. Only then can anyone reach the second condition, which is a substantive judgment that restricting the module was a mistake in the first place. A request that the restriction simply be lifted because it is inconvenient does not engage either condition.

What makes a TC 342 argument winnable

The gate is “unnecessary,” not “no longer needed,” and that wording rewards a specific kind of showing: that the condition which justified manual computation either never applied to this module or has been resolved on the record. A restriction set for a combat-zone tour pattern, a disaster-area postponement, or a carryback adjustment is warranted while those facts are live. A restriction that was generated automatically — Doc 6209 records that a return filed with Condition Code Z generates a zero-amount TC 340 and turns the restricted-interest indicator on — may never have reflected any considered determination at all, and a zero-dollar restriction with no computation behind it is the cleanest version of this argument.

The practitioner’s work is therefore documentary rather than rhetorical. Establish what set the restriction, establish that the condition is gone or was never present, and ask for the source document to be pulled. Note also what a TC 342 does not do: it does not abate anything already assessed. Interest that posted while the module was restricted stays posted unless it is separately abated, so a client who wants both outcomes is asking for two transactions, not one. That distinction is worth stating plainly in any written request, because a request that mixes the two invites a response addressing only the easier half of it, and the module can end up recomputing forward while the disputed accruals from the restricted period sit untouched on the account.

What TC 342 gets confused with

TC 342 is most often confused with TC 341, on the reasonable-sounding logic that removing a restriction and removing interest are the same kind of relief. They are not related outcomes at all. TC 341 reduces an assessed interest amount and leaves the module restricted; TC 342 changes nothing about the balance and un-restricts the module. A client asking to “have the interest taken off” and a client asking to “have the account computing normally” need different transactions, and conflating them produces a request the IRS cannot act on as written.

It also sits in an exact structural parallel with two penalty codes already in this library, which is the fastest way to place it: TC 162 removes the computation restriction a manual failure-to-file penalty entry leaves behind, and TC 272 does the same for the failure-to-pay penalty. All three are zero-dollar restriction-deletion codes. TC 342 is that same idea applied to interest — which also means a module restricted for interest is frequently restricted for the failure-to-pay penalty too, and clearing one does not clear the other.

The practitioner’s actual next step

Determine what set the restriction before requesting anything, distinguishing a considered manual computation from an automatically generated zero-amount entry — the two support very different arguments.

Frame the request as a determination that the original restriction was unnecessary, because that is the statutory-style gate the IRM actually imposes, and ask explicitly that the source document be secured.

Treat abatement as a separate ask. A TC 342 recomputes forward; it does not reverse interest already assessed under the restriction.

Check the module for a parallel penalty restriction, since the same input that restricted interest often restricted the failure-to-pay penalty as well.

Confirm the state change actually took effect afterwards using the IRS Transcript Decoder, and re-verify any payoff figure quoted to the client before the restriction was lifted.