TC 620: Initial Installment Payment (Extension Payment)

What the code actually does

IRS Document 6209, Section 8A 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 is proof of a timely-filed extension request, independent of whatever TC 150 return eventually posts. A module carrying TC 620 and a companion TC 460 establishes that the taxpayer requested the extension 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 conditions the TC 460 generation on Condition Code "L" not being present, and conditions Form 8868 and Form 5558 status updates on a Notice Code of 1 or 2 being present on the input. Where one of those flags is missing or wrong, the payment can post as a TC 620 without the extension actually taking effect — the module shows money received with no matching TC 460.

That split is the actual audit trail worth reading. If a transcript shows TC 620 with no TC 460 following it, the IRS rejected the extension request, or a defect in it kept the extension from taking effect, even though the payment posted and cleared — a materially different problem than a late return, and one the client's own bank statement cannot reveal.

A TC 620 with no TC 460 is not just a diagnosis — it can also be the fact pattern that supports a failure-to-file reasonable-cause argument, since it shows the client made a timely, good-faith attempt to extend even though the extension itself was defective.

Tracing a TC 620 that will not post

The same payment-tracer discipline that applies to every code in this batch applies here. IRM 21.5.7.3 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 extension payment cannot be located at all, the same IRM directs preparation of Form 4446 and referral to the Hardcore Payment Tracer Function — the identical escalation path every other payment-tracer code in this batch uses.

A posted TC 620/TC 460 pairing confirms the extension request processed; it does not, by itself, confirm the payment was adequate. For a Form 7004 extension, Treas. Reg. §1.6081-3(a)(3) requires the filer 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 TC 620 gets confused with

It gets confused 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.

It gets confused 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.

Its dishonored-check reversal, TC 621, gets read 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.

The practitioner's actual next step

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, treat it as a defective extension request, not a missing payment — the Condition Code or Notice Code gating almost certainly failed.

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 Service to research it under IRM 21.5.7.3 (CC BMFOL/IMFOL, the IAT TC Search Tool) before assuming the check was lost — those are IDRS command codes only an IRS employee can run.