The following unique campus addresses and Zip Codes should be used when the taxpayer has provided no address and we cannot obtain one for IMF processing:

Generally, payments will not offset to or from another tax module if both modules are settled, except the ESTIMATED TAX(ES) Credit offset.

When a payment is identified for a particular tax module and it has unposted from another module, post the payment to the proper module, rather than letting the computer offset the payment.

When attempting to post a payment to a tax module which contains a TC 760, Substantiated Credit, for the same amount and approximately the same date—

A credit transfer is used to transfer money from one tax module to another or between Master Files. Each has unique Doc Codes and only certain transaction codes are valid for a specific Doc Code.

When transferring a payment to a settled module, use unpostable bypass indicator 0 or 1 to prevent an unpostable 198/305.

Transfer vouchers are identifiable by their Doc Codes—24, 34, 48, and 58.

Form 8758, Excess Collections File Addition Used to transfer non-revenue receipts to Excess Collections.

Form 8765, IDRS Control File Credit Application—requests a transfer from Excess Collections to a taxpayer's account.

See IRM 3.17.220 for additional information on the preparation and use of these forms.

Unpostable examiners may detect erroneous refunds.

CC NOREF is used to intercept erroneous refunds.

If the credit side of the transfer has posted, and an erroneous refund is in the process of being issued:

If the credit is not frozen from refunding, research IDRS each cycle until the debit posts in order to intercept any generated refund.

Ensure the transaction is being directed to the correct Master File, MFT, and Taxpayer.

If the credit part of the transfer has posted and refunded:

If the module is in a TC 740 freeze status, do not attempt to update the account; it will send another refund.

The Unpostable function will attempt to correct all unposted TC 740/841 prior to sending to Refund Inquiry.

If unable to resolve, route to the Refund Inquiry function for assistance (see IRM 21.4.6):

The Refund Inquiry function will research and enter the correct information on UPCAS Z.

The Unpostable function will close the case within five work days after receiving the correct information.

If the Unpostable TC 740/841 is a money discrepancy, (see IRM 3.17.79).

This subsection contains instructions on how to correct unpostable conditions involving Excess Collections, Dishonored Checks or Unidentified Remittance if the corrective action can be identified.

This involves various UPCs such as 168, 189, and 194 involving the correction of CREDIT modules.

Complete all research on the case.

Category Y–1 consists of all current-year TC 610 transactions (payment with return) that are not Doc Codes 24, 34, 45, 48, 58, or 87. Unpostable Code is 140.

All IMF TC 150 transactions with an Unpostable Code other than 140 and the "RPS Indicator" is "S" (IMF returns with an RPS remittance).

Category Y–2 consists of prior list year RPS TC 610 and/or TC 150 transactions, or

RPS TC 610 and/or TC 150 transactions with an unpostable classification code of "Corrected" or "Reclassified" (Repeats).

Erroneous TDI's (Forms TDI–14) can be generated when

When nullifying (URC 1 or 8), a TC 150 or TC 610 and the TC 150 will not be reinput to the same tax module within six weeks after the Return Due Date (RDD). Input a TC 599 with closing code 17 or 18 unless otherwise directed.

When a TDI satisfying transaction other than a TC 150 or TC 610 attempts to post to the wrong tax module or account and the unpostable will not be corrected within six weeks after the RDD, expedite the resolution by the end of the next week.

To prevent erroneous TDI's, input a TC 599 with the appropriate closing code if the TC 150 cannot be posted timely to stop the TDI.

All Unpostable initiated TC 59X should be input through IDRS.

Do not change posted entity data based solely on the information found on the unpostable TC 59X.

CC-STAUP and TC 470 with no closing code Notice Delay—generally it is not necessary to delay IDRS notice issuance on unpostable modules because:

General—A transaction frequently requires a related transaction to post first. Most transactions require the establishment of an account or tax module as a prerequisite. Many unpostables result from improper cycling. All Doc Code 47 (Exam) and most Doc Code 54 (DP) Adjustment transactions require a return be posted. Reversal transactions require the related original transaction to be present. After all transactions have posted, analyses are made, new status and freeze conditions are set, (released or changed) and notices, TDA's and refunds etc. are issued. The length of time needed to post a transaction varies.

Tax examiners have the ability to cycle transactions input via IDRS using a Posting Delay Code (PDC).

The following IDRS transaction programs have the posting delay capability:

All payment deposits are assigned a 20 digit Trace ID number. When tax examiners process unpostable payment transactions, the Trace ID number may not be already transcribed on the payment document. Unpostables will be required to ensure that the Trace ID number is on all payments that are nullified using URC 1 or sent to Rejects using URC 8. This includes any payments that have to be renumbered or reprocessed. The Tax Examiners (TEs) will have to identify the Trace ID number and it on the document, even if a dummy document is created. The Trace ID will not be viewable or correctable in GUF. The Trace ID number for a payment can be identified on IDRS using TXMOD. If the payment is from ISRP, RPS or Lockbox, use Remittance Transaction Resource System (RTR) to find the Trace ID. Once the Trace ID is identified, it must be transcribed onto the payment document.

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

If there are indications that FDC has previously reviewed the return (a Fraud Detection or FDC stamp is on the return or on an attached Form indicating that they have seen the return), do not set aside for FDC review.

Cases being worked that meet the following FDC criteria will be set aside to be reviewed by Fraud Detection:

If any of these conditions are present, discontinue unpostable processing. Set aside the case for FDC review.

If an unpostable record that is assigned to Unpostables, Entity Control or Examination falls into Fraud Detection criteria, it should be reassigned and worked by Fraud Detection.

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Refer to Fraud Detection for review any return or document on which the taxpayer:

If the document has already been forwarded to Fraud Detection or Examination for the above reasons (By Code & Edit, for example), DO NOT forward again. Continue with regular unpostable resolution procedures.

If an assigned record is determined to have Fraud Detection, Statute or Bankruptcy issues, the case should be processed in accordance with the following categories:

Document 47 or 54 exception: If URC 2 (void) is used and the transaction is remade by a prompt/quick assessment (TC370) due to a Statute issue, the transaction should not repeat as a Statute unpostable.

The Data Master File (DM–1) is a data base of name controls and TINS received from three sources:

The DM–1 receives weekly updates from all three sources.

The DM–1 determines the validity of all transactions containing entity information. The DM–1 "directs" transactions to either the valid segment or the invalid segment of Master File.

The IRS also receives weekly tapes from the Social Security Administration that contain all name controls and TINs assigned or updated for a one week period.These are designated as"NEW SSA NC" on the NAP file, via CC INOLE. When a transaction finds a match on the DM-1 file with this indicator present, the transaction will post to the invalid side.

The transaction given the validity digit of "1" is run against the Accretion File.

The Master File is structured in two segments—valid and invalid for taxpayer's who file using SSNs only.

The validity of an SSN/Name Control is determined by finding a matching SSN/name control on the Data Master File (DM–1) file or the Accretion File. Refer to IRM 3.13.5, IMF Account Numbers, for additional information on the DM–1.

Output from the Master File that contains an asterisk (*) or "W" immediately following the SSN indicates the account is invalid for the SSN/Name Control combination.

The most common reasons for an invalid account number are:

Master File is segmented according to SSN validity.

"Proximal match" on name controls attempt to locate a name on the DM–1 or accretion files.

See IRM 3.13.5, IMF Account Numbers, for information on the issuance of Individual Taxpayer Identification Numbers (ITINs).

Command Code MFTRA with Request Type "U" is used to request SSA NUMIDENT transcripts. The data NUMIDENT entity information is direct from SSA transcripts. The requested NUMIDENT transcript will be returned in approximately one to three days under CC ACTRA-NUMIDENT Transcript. The SSA provided information includes:

GUF has implemented validity checks to prevent return SSNs out of the range of numbers issued by SSA from attempting to post to the Master File.

If the taxpayer has an SSN out of the valid range, GUF will not allow the unpostable to be resolved. It will print "SSN NOT GREATER THAN 001-01-0000" or "FIRST THREE DIGITS OF SSN ARE INVALID" .

When the primary SSN is out of the valid range, perform all "in-house" research. If a valid SSN, invalid SSN, or Internal Revenue Service Number (IRSN) is found, correct the unpostable record with URC 6. If no other number is found, reassign the case to Entity for assignment of a temporary IRSN. The temporary number must be established on the Master File with a TC 000. Close the Unpostable with URC 6 and cycle as necessary. If the return was processed as "LONG ENTITY," TC 000 is not necessary.

Entity Control will send a letter to the taxpayer notifying him/her of the assignment of a temporary IRSN. They will explain to the taxpayer that the number shown on his/her return is out of the range of numbers assigned by SSA. They will instruct the taxpayer to go to SSA to obtain verification of the number they used on the return.

Under no circumstances should a taxpayer ASSIGNED an IRSN by Unpostables or Entity Control receive EIC and/or their Personal Exemption. After informing the taxpayer of the assignment of the IRSN, URC 8 to Rejects. Inform Rejects to removed the taxpayer's Personal Exemption and/or EIC claimed.

Any errors observed in the taxpayer's entity or any change of address indicated from a return (TC 150) or taxpayer correspondence should be corrected. Correction of the address can be done via IDRS or the posting of a TC 430 or TC 150 long or intermediate entity with the correct address information.

If a TC 150 is already posted to both the invalid and valid taxpayer's account for the same tax period, do not input a transaction that will cause the two accounts to merge (i.e., TC 011/013/040/041).

When a name or name line change is needed to an entity and INOLE/ENMOD shows an EO Subsection, Do Not input a TC 013. Reassign the case to Entity Control. Explain on Form 8749 why the name or name line change could not be made (e.g., E.O. Subsection).

If an unpostable case repeats or has unposted due to a no-merge condition, or is in a CP43 situation, reassign the case to the Entity Control Function. Explain on Form 8749, which condition exists on the module.

Entity Code—A code indicating whether a transaction carries full or abbreviated entity data. The entity code is present with the following IMF unpostables and Transaction Codes; otherwise the field is blank:

The following is a list of Entity Codes and their meanings:

Filing Status Codes—Identifies the taxpayer's marital and family situation on Forms 1040/1040A/1040EZ. It is an important factor in determining whether the return is required to be filed, the amount of standard deduction, and the correct tax.

The meaning of Filing Status Codes (FSC) are as follows:

Establishing an account

Correcting name on Unpostable record

Correcting name on IMF residing on VALID segment

Correcting the SSN on Unpostable record.