TC 788: Offer in Compromise Conditions Completed
By Forrest Baumhover, CFP®, EA · Last verified September 7, 2026
TC 788 is the offer finished — every term met, the account released, the file closed — and despite sitting eight numbers above the acceptance code it does not reverse it; it requires the acceptance to still be standing in order to post at all.
What the code actually does
TC 788 closes out a completed offer. IRS Document 6209, Section 8A describes it as recording "the closing of an accepted Offer-in-Compromise," after which "issuance of future OIC transcripts is discontinued."
The condition it enforces is the interesting part: "to post, an unreversed TC 780 must be posted." The completion cannot exist without a standing acceptance. That single clause settles the question the numbering invites, and it is the reason this page exists rather than being a line on the acceptance page.
It is not the reversal of the acceptance
Practitioners reasonably assume that a higher-numbered code in the same family undoes the lower one, because across most of the master file that is exactly how the numbering works — assessment and abatement, freeze and release. Here it does not.
An accepted offer is undone by default or termination, which are different codes entirely and which put the compromised liability back. This code does the opposite: it records that the taxpayer met every term, including any collateral agreement, and that the Service has nothing further to monitor.
The distinction is worth getting right in front of a client, because the two outcomes could not be further apart. A completion is the end of the matter; a default is the beginning of collection on a liability the client believed was settled. Reading one as the other is the sort of error that changes what a practitioner does next by everything.
What survives the completion
Doc 6209 records that on completion the "account and Tax Module is released for offsetting and refunding insofar as pertains to OIC freeze" — so the refund and offset restrictions that came in with the acceptance come off, and the client’s account behaves normally again.
But one thing deliberately does not come off: "credit/debit interest restriction (and FTP on BMF) established from the posting of TC 780 are retained." The interest and failure-to-pay restrictions that stopped the compromised years from growing survive the completion permanently.
That is the correct outcome and worth understanding rather than being surprised by. Completing an offer does not retrospectively restore the interest the compromise extinguished; the restriction stays in place so the module cannot start accruing again on a liability that no longer exists. A module that begins accruing after a completion is showing a problem, not normal behaviour.
What TC 788 gets confused with
It gets confused with TC 780, the acceptance, and the gap between them is the entire term of the offer — commonly five years for a periodic payment offer, plus the compliance period that runs alongside it. That interval is itself the thing to manage: between the two codes the client has to make every payment and stay compliant on every subsequent filing and payment obligation, and it is the later years — the ones nobody was thinking about when the offer went in — that most often break an accepted offer. A client who has just been accepted is nowhere near this code.
It gets confused with the pending code by clients relaying what they were told, and the TC 480 page covers why processability, acceptance and completion are three separate events with three separate codes. Where an offer is still being contemplated rather than monitored, the OIC pre-qualifier works the financial test the Service will apply.
It also gets confused with automatic. IRM 5.19.7.5.3 shows manual input and follow-up in the process — "input TC 788 using CC REQ77 with Delay Code 2 to allow TC 971/032 to post. Set a follow-up for 2 cycles to ensure TC 788 input on Masterfile" — and the chapter carries a whole subsection on correcting unpostable TC 788s on mirrored accounts. A client whose offer terms were plainly completed and whose account still shows no completion code has a plausible administrative problem worth raising, not a settled matter to leave alone.
The practitioner’s actual next step
Confirm which code actually posted before telling a client their offer is finished — completion and default look similar only in the sense that both end the monitoring.
Where the terms have been met and no completion code has appeared, treat it as an administrative gap and ask, since the IRM itself contemplates unpostables and manual follow-up here.
Check that the interest and failure-to-pay restrictions were retained, and query any module that starts accruing again.
Expect refund and offset behaviour to return to normal at this point, and tell the client so.
Keep the compliance period in view until the completion code is on the account, not merely until the payments stop.
Watch subsequent-year filing and payment compliance as closely as the offer payments themselves, since that is what usually causes a default.
Read the whole sequence — pending, accepted, completed — in order with the IRS Transcript Decoder rather than from the client’s file.