TC 620: Initial Installment Payment (Extension Payment)

What the code actually does

IRS Document 6209, Section 8A (the IRS’s reference guide to its data-processing codes) defines TC 620 narrowly: it "credits the module with the remittance received with the Form 7004" — the module being the account record for one tax period. The same entry extends the definition to Form 8868 (tax-exempt organizations) and Form 5558 (employee benefit plan returns) — three different extension forms, one posting code.

The remittance is only half of what the code does. Doc 6209 states that a TC 620 with Document Code 04 also "generates TC 460 to extend the due date... for filing return," and posts a status code specific to the form: Status 04 for the Form 1120 series, 706-GS(D), 706-GS(T), 1041 family, 1042, 1065 family, 3520-A, and 8804; Status 14 for Form 8868. The payment and the extension are a single posting event.

That matters because TC 620 shows a remittance posted with an extension form, independent of whatever TC 150 return eventually posts. A module carrying TC 620 and a companion TC 460 shows that the taxpayer remitted with an extension form and the IRS processed it — evidence a client rarely thinks to preserve on their own once the extended return is filed months later.

The gating condition practitioners miss

Doc 6209 generates TC 460 from a Doc Code 04 TC 620, conditions the Form 7004 update on Condition Code "L" not being present, and conditions the Form 8868 update on Notice Code 1 or 2 and the Form 5558 update on Notice Code 1 being present on the input. Where one of those flags is missing or wrong, the payment can post as a TC 620 without a matching TC 460 — the module shows money received with no TC 460.

That split is the actual audit trail worth reading. If a transcript shows TC 620 with no TC 460 following it, check the document code first: Doc 6209 shows Doc Code 04 generating TC 460, and Condition Code L or a missing Notice Code can also block it.

Tracing a TC 620 that will not post

IRM 21.5.7.3.2 directs researchers to "CC IMFOL and/or CC BMFOL" — IDRS (the IRS's internal Integrated Data Retrieval System) command codes only an IRS employee can run — noting that "CC IMFOL definer code 'P' displays payments within a specific date range," and recommends the Integrated Automation Technologies TC Search Tool, which "allows research of payments by amount, date, and TIN" (Taxpayer Identification Number).

Because TC 620 is BMF/EPMF-specific, CC BMFOL is the more likely tool in practice. Where the IRS cannot locate the extension payment at all, IRM 21.5.7.3 also directs IRS employees to prepare Form 4446 and refer the case to the Hardcore Payment Tracer Function — the escalation path the other payment-tracer pages describe.

A posted TC 620/TC 460 pairing confirms the extension request processed; it does not, by itself, confirm the payment was adequate. For a corporate Form 7004 extension, Treas. Reg. §1.6081-3(a)(3) requires the corporation to remit a properly estimated unpaid tax liability — so a practitioner should not assume a TC 620/TC 460 pairing on a Form 7004 module settles validity regardless of the dollar amount sent; an extension built on a token or clearly unreasonable estimate can still be treated as invalid. Confirm the specific reasonable-estimate requirement under the governing regulation before assuming the same rule applies unchanged to a Form 8868 or Form 5558 extension.

What people mistake TC 620 for

People confuse it with TC 610, the remittance-with-an-original-return code. The two are structurally parallel — both are the "payment that arrived with a filing" code — but TC 610 posts against the return itself while TC 620 posts against the extension request that precedes it. A module can carry both, in that order, for the same tax period.

People confuse it with a garden-variety subsequent payment. TC 620's value is precisely that it is not one: it is timestamped and typed as an extension remittance, which is why it (and its companion TC 460) is the thing to pull when a client insists they filed an extension and the IRS disagrees.

People read its dishonored-check reversal, TC 621, as an IRS error. A bounced check reverses TC 620 and, absent a secondary TC 280, generates a TC 286 bad-check penalty automatically under IRC §6657 — a returned payment, not a posting mistake.

What to do next

When a client disputes a late-filing penalty and claims an extension was filed, pull the module for TC 620 and TC 460 together, not the payment alone.

If TC 620 posted but no TC 460 followed, ask the IRS employee to confirm the document code, Condition Code and Notice Code on the input before treating it as a defective extension request.

Confirm which form generated it (7004, 8868, or 5558), since the status code and due-date mechanics differ by form.

If the payment cannot be located on the module at all, ask the IRS contact to trace it before assuming the check was lost.