TC 667: Estimated Tax Credit Transfer Out

What the code actually does

IRS Document 6209, Section 8A (the IRS’s reference guide to its data-processing codes) defines TC 667 as "a debit transaction representing amount of ES [Estimated Tax] Credits transferred to a spouse's account," which also acts to "release Excess ES Credit Freeze." This is the losing side of the automated search the TC 666 page documents in full — one module gives up estimated tax credit, the other receives it as TC 666.

The trigger is the same either way: a return claiming more estimated tax credit than its own module holds causes Master File to search the spouse's account, and where that search finds an available excess, TC 667 is the mechanism that actually moves it.

Because the transfer is automated and requires no request, each module's available ES credit can change without a client request. Doc 6209 does not say whether the transfer creates IRC §6654 exposure.

Why an "excess" was sitting there to begin with

This code presumes the spouse's own module was carrying more estimated tax credit than that module's own return actually needed — an "Excess ES Credit Freeze" existed precisely because the credit exceeded what the spouse's filing required. TC 667 releases that freeze by moving the excess to where it was actually claimed.

A client confused about why their own module shows a debit for money they thought they had already used should understand the sequence this way: the credit was never fully needed on their own return in the first place, which is exactly why it was sitting frozen as an excess rather than already applied.

Reading it alongside the manual allocation procedure

Where spouses disagree about how joint estimated tax payments should be divided, IRM 21.6.3.4.2.3.2 sets out the manual process for resolving it. If both spouses still cannot agree, the caseworker asks the taxpayer to submit a computation allocating the credit "in proportion to each spouse's separate tax"; if neither spouse can produce one, the same IRM table lets the caseworker determine that same proportional allocation directly instead. Outside a community property state, where the IRM refers the taxpayer to Pub. 555 instead, the IRS applies the resulting transfer "in four equal installments, unless directed otherwise" — that installment rule governs how the IRS applies an already-determined allocation, not how it decides the allocation itself.

A TC 667 generated automatically is a different event from a manual transfer completed under that IRM procedure, even though both move estimated tax credit between spouses' modules. Confirm which process actually produced a given transfer before explaining it to a client who disputes the amount.

What people mistake TC 667 for

People confuse it with TC 666, the credit side of the identical event — the two only make sense read together as one transfer split across two modules.

People confuse it with a manual credit-transfer correction. This specific code is Master File's own automated response to an excess-credit condition, not a caseworker-initiated fix for a misapplied payment.

People confuse it with a penalty-triggering shortfall. Doc 6209 describes TC 667 only as a debit moving ES credits to the spouse's account that releases the Excess ES Credit Freeze; it does not mention an estimated tax penalty.

What to do next

Confirm the paired TC 666 credit landed on the correct spouse's module before treating this debit as final — the two transactions should carry matching dates and amounts.

Check whether the excess credit that funded this transfer was itself correctly computed, since a wrong original allocation compounds when it is automatically moved.

For a disputed allocation, apply the manual joint-allocation procedure in IRM 21.6.3.4.2.3.2 rather than treating an automated TC 667 as the final word.

Recompute each spouse's actual estimated tax position once the transfer posts, since the freeze release changes what each module shows as available and check each spouse's installments against the return actually filed.