TC 610: Remittance With Return

What the code actually does

TC 610 is narrow and specific. IRS Document 6209, Section 8A defines it as crediting "the tax module with a payment received with the return, including payment with voucher." Not any payment — the payment that travelled with the filing.

That specificity is what makes it useful. Where a module shows a TC 610, the money and the return arrived together, which is itself evidence about timeliness and about what the taxpayer intended the payment to cover. A payment sent later posts under a different code entirely, and the distinction survives on the transcript for the life of the account.

That evidential quality is worth more than it first appears. Where a client is arguing about a failure-to-pay penalty, or about whether an extension was honoured, the presence of this code and its date establish that money accompanied the filing — a fact the client usually cannot document years later from their own records.

When it cannot post, it disappears for months

This is the scenario worth knowing cold, because clients present it as a crisis and it usually is not one. IRM 21.5.7.3.2.1 describes it exactly: "when a payment attempts to post to an account as a TC 610 transaction (remittance with return) and no account established, the transaction resequences with a resequence code 24."

It then keeps trying, silently. "The payment continues to resequence if no account is established until ECC-MTC cycle 29 when the transaction goes unpostable with an unpostable code (UPC) 151." Later in the year the behaviour changes slightly — after cycle 29 the payment "resequences... for three cycles prior to going unpostable."

So a cheque can clear the taxpayer’s bank, sit in the system for the better part of a filing season, and never appear on the account the client is looking at. Nothing has been lost and nothing has been stolen; the payment has nowhere to land because no entity or module exists for it yet. This is common after an identity-theft filing, a mismatched name control, a first return under a new identifying number, or a return that itself failed to post.

The IRM says how to find it

The manual gives the research route in terms a practitioner can hand straight to the Service: "to locate a TC 610 payment, use CC IMFOLQ with the payment amount or TIN." Asking a caseworker to check IMFOLQ for a resequencing remittance by amount is a far more productive request than asking them to look for a missing payment.

The IRM then routes it: "if you locate a TC 610 payment, prepare a Form 4442, Inquiry Referral, select the Referral Category ‘IMFOLQ Payment’," or, on the other path, "request CC MFTRA definer U for the SSN shown on CC IMFOLQ to establish the account." The fix is usually to create the account the payment is looking for, not to trace the money.

One more instruction saves a wasted request. The IRM states: "if a payment posts as a TC 610, do not request the document. A payment posting voucher does not exist for a TC 610." Asking for the source document on this code produces nothing, and the archived payment images are retrieved a different way.

What TC 610 gets confused with

It gets confused with TC 670, the subsequent payment. The two look alike in a payment column and mean different things: money that came with the return, versus money sent afterwards against a balance. Where the question is whether a client paid on time, the code answers it directly.

It gets confused with a credit. Withholding, estimated payments and refundable credits post under their own codes with their own dates, and a client’s "I already paid" can refer to any of them. Only this one means a remittance accompanied the filing.

And its reversals get read as errors. A dishonoured cheque reverses this code and, on some accounts, generates a bad-check penalty automatically — the mechanics of which are set out on the TC 286 page. A reversal is a returned payment, not an IRS mistake, and the penalty that follows it has its own reasonable-cause defence under IRC §6657. Reading the sequence in order with the IRS Transcript Decoder is how to tell a bounced cheque from a correction.

The practitioner’s actual next step

When a client insists they paid with the return and nothing shows, assume a resequencing payment before assuming a lost one.

Ask for an IMFOLQ search by amount or identifying number, by name, rather than asking generally about a missing payment.

Establish why no account existed — an unposted return, a name-control mismatch, or identity theft — because that is the thing that actually has to be fixed.

Do not request the payment posting document; the IRM says it does not exist for this code.

Check whether the payment was later reversed rather than never posted, since those are opposite problems with opposite answers.

Where the payment did post but the client still shows a balance, look at what it was applied to before assuming a misapplication — the CP14 balance notice and the module can disagree simply because of timing.