TC 730: Overpayment Interest Applied (Manual Transfer)

What the code actually does

IRS Document 6209 (the IRS’s reference guide to its data-processing codes) defines TC 730 as a credit that "[credits] Tax Module for a manual transfer of an overpayment of interest," and notes that under Document Code 24 it "generally requires a corresponding TC 850 debit." In plain terms: someone, not the computer, moves a fixed, already-known amount of overpayment interest off the module (the record for one tax type and period) where it accrued and onto a different module in the same account — a different tax period or return type — using two codes entered as a pair. TC 850 is the debit that leaves the source module; TC 730 is the credit that lands on the receiving one.

Document 6209 also flags a narrower path into the same code: "Doc. Code 58 transfers such overpayment to the MF from a non-ADP return," meaning some interest transfers originate outside the IRS's core Automated Data Processing pipeline and reach Master File (the IRS's official repository of taxpayer data) through a different documentary route, though the credit still posts as the same TC 730.

What this means for your refund

If TC 730 shows up on your account, interest the IRS already calculated on an overpayment in one filing period was manually carried over and credited to a different one — most often because that interest was needed to help pay down a balance due elsewhere in your own account. The dollar amount next to the code is interest that moved, not new interest layered on top of what you already had; it is the same money, relocated to a different module.

Because a person entered this transfer rather than the computer, it is worth confirming that the receiving module and the date used for the transfer actually line up with your own records. Manual entries carry more room for a keying error than an automated one does, and the IRS Transcript Decoder can help you locate the corresponding TC 850 debit that should exist somewhere else on the account.

Why TC 730 exists instead of a generated transaction

Master File already has a fully automated way to move overpayment interest between two of a taxpayer's own modules: TC 856 debits the source module and TC 730's systemic cousin, TC 736, credits the receiving one, both generated with no manual entry at all. That automated pairing is the default precisely because it lets Master File carry out a routine internal offset without a person keying in two matching entries by hand. IRM 20.2.4.7.6, Master File and Systemic Offsets, explains why that automated pair can't always be used: "Master File will only generate the correct amount of overpayment interest if it originates the offset. Expressly, offset overpayment interest will systemically generate only on systemic offsets, not manual offsets."

The same subsection gives the specific scenario that forces the manual pair instead: "When a TC 770 must be offset, a manual transfer using TC 850 and TC 730 is always used. Debit with TC 850 using the 23C date of the TC 770, and credit with TC 730 using the date interest on the TC 770 was computed to ('CR-INT-TO-DT' of TC 770)." (The 23C date is the date the IRS officially records, or assesses, a transaction on the module. Only the TC 850 debit uses it; the TC 730 credit carries the date to which the IRS computed the TC 770 interest.) A TC 770 is itself a manually computed interest credit — a person already worked out that interest by hand. Because the computation didn't originate from Master File's own systemic offset logic, the computer can't be trusted to move it a second time on its own, so a person moves it a second time too.

What people mistake TC 730 for

People confuse it with TC 736, which looks like it performs the identical job — both are credits that land interest on a receiving module — but Master File's systemic offset engine generates TC 736 systemically, while TC 730 exists specifically for the cases that engine cannot handle on its own. Doc 6209 marks the line by transaction type: TC 736 carries the label "Generated Transaction," while TC 730 "generally requires" its paired TC 850 debit rather than posting as a standalone entry.

It is also easy to mistake TC 730 for new interest income rather than a relocation of interest that already existed. It is not — the interest was already computed, and if it traces back to a TC 770, already credited to the taxpayer once before the manual transfer moved it to the module that actually needed it.

What to do next

Confirm the paired TC 850 exists before treating a TC 730 as fully explained. Doc 6209 is explicit that the credit "generally requires a corresponding TC 850 debit," so a TC 730 with no matching debit anywhere on the account is worth flagging rather than assuming away.

Trace TC 730 back to the TC 770 it was computed from, where one exists — IRM 20.2.4.7.6 ties the TC 730 transfer date specifically to that TC 770's own interest-computed-to date, not to an arbitrary processing date, so a mismatch there is a real discrepancy worth raising.

Do not treat a posted TC 730 as proof the underlying interest amount was independently verified. Like TC 852's correction of a mishandled TC 850, TC 730 only confirms a transfer happened — checking whether the amount transferred was calculated correctly in the first place is a separate step.

If a TC 732 also appears on the module, treat the TC 730 as corrected rather than still in effect, and read that code's own page for what specifically triggered the fix.