Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 3. Submission Processing

Chapter 13. Campus Document Services

Section 122. IMF Entity Control Unpostables

3.13.122  IMF Entity Control Unpostables

All Official Use Only content has been replaced with ≡.

3.13.122.1  (01-01-2010)
General

  1. This section contains general information on processing Individual Master File (IMF) Entity Control Unpostables.

3.13.122.1.1  (01-01-2010)
Purpose and Scope

  1. The purpose of this IRM is to provide instructions and procedures for correcting and resolving Entity Control Unpostables to the IMF Master File.

  2. The mission of the Entity Control Function is to resolve all Entity related problems in a timely manner by providing the taxpayer with the highest degree of Quality and Customer Service.

  3. The words "NOTE" , "CAUTION" , "EXAMPLE" , and "EXCEPTION " appear throughout the text as a reminder to be careful when following prescribed Entity procedures for case resolution.

  4. When correcting unpostables, the first step is to determine whether the unpostable return or document AND the Entity on the Master File are the same. Command Codes (CCs) NAMES, NAMEE, NAMEI, NAMEB, and ENMOD are used to make this determination.

  5. Completely review to resolve all Unpostable conditions which could result in a REPEAT Entity unpostable condition.

  6. The following IRMs are used in conjunction with this section.

    1. IRM 3.0.273, Administrative Reference Guide

    2. IRM 3.10.72, Receiving, Sorting and Numbering

    3. IRM 3.12.32, General Unpostables Framework (GUF)

    4. IRM 3.12.179, IMF and PMF Unpostables

    5. IRM 3.12.37, General Instructions

    6. IRM 3.13.5, IMF Account Numbers

    7. IRM 3.30.123, Processing Timeliness

    8. IRM 2.3, IDRS Terminal Responses

    9. IRM 2.4, IDRS Terminal Input

3.13.122.2  (01-01-2010)
Statute of Limitations (Statutes)

  1. A statute of limitation is a time period established by law to review, analyze and resolve taxpayer and/or IRS related issues.

  2. The Internal Revenue Code (IRC) states that the Internal Revenue Service (IRS) will assess, refund, credit, and collect taxes within specific time limits. These limits are known as the Statute Of Limitations. When the Statute period expires, the IRS can no longer assess additional tax, allow a claim for refund by the taxpayer, nor take collection action. There is an Assessment Statute Expiration Date (ASED), a Refund Statute Expiration Date (RSED), and a Collection Statute Expiration Date (CSED). Each has a different statute expiration period.

  3. The Assessment Statute Expiration Date (ASED) is identified by Generalized Unpostable Framework (GUF) and must be monitored to ensure that the statute does not expire.

  4. The ASED is determined as three years after the Return Due Date (RDD) or IRS received date, whichever is later.

  5. Example of statute expiration date for a timely filed return:

    Form Tax Period IRS Received Date Return Due Date ASED
    Statute Date
    1040 200912 03-15-2010 04-15-2010 04-15-2013

  6. Example of statute expiration date for a late filed return:

    Form Tax Period IRS Received Date Return Due Date ASED
    Statute Date
    1040 200912 05-15-2010 04-15-2010 05-15-2013

  7. If the ASED is imminent (two months prior to ASED), notify the manager or work leader and take necessary action to resolve.

  8. See IRM 3.0.273.11, Administrative Reference Guide, for additional information on Statute Awareness.

3.13.122.3  (01-01-2010)
Notification of Taxpayer Due to Corrected Unpostables

  1. Whenever the SSN shown on the unpostable return/document is changed, the taxpayer must be notified and given the correct SSN and an explanation. Use appropriate C letter. See Exhibit 3.13.122–1 for a listing of appropriate "C" letters.

3.13.122.3.1  (01-01-2010)
Section 3705(a), IRS Employee Contacts

  1. This tridoc contains information on the Restructuring and Reform Act of 1998, Section 3705(a), and provides identification requirements for all IRS employees working tax related matters.

    1. IRS employees are required to give their name and unique identification number during taxpayer telephone, face to face, or written contact. In addition, a telephone number is required on all taxpayer correspondence.

    2. This will provide taxpayers with enough information to identify an IRS employee who has previously assisted with tax related matters.

  2. All IRS employees in the field, national, or area office who communicate by telephone, correspondence, or face to face with taxpayers or their personal representatives on tax related matters are required to provide (at a minimum) the following information:

    1. With telephone contact, provide your title (e.g., Mr., Mrs., Ms., Miss), last name, and your badge identification (ID Card) number.

    2. With face to face contact, provide your title and last name during the conversation, and your badge ID number.

  3. When contacting the taxpayer through Correspondence, provide a contact telephone number where the taxpayer's question(s) can be answered. In addition to your title and last name, provide your IDRS, letter system, or ID Card (badge) numbers.

    1. The IDRS number and numbers for some other letter systems are automatically generated. If it is not generated or a handwritten note is prepared, the ID Card (badge) number must be used.

    2. Employees who have toll-free telephone numbers may also provide their location for identification purposes.

    3. Correspondence, whether sent directly to the taxpayer or to the taxpayer's personal representative, must contain the required information.

    4. When a taxpayer insists on speaking with a specific employee who previously handled their inquiry, or requests/complains about the level of service previously provided, every attempt should be made to resolve the taxpayer's inquiry. If the issue cannot be resolved, the employee should refer the inquiry using established procedures to his or her manager.

    5. Correspondex letters will provide a specific employee name and telephone number only if the employee initiating the correspondence is in the best position to respond to questions that the taxpayer may have about the correspondence or the employee is asking the taxpayer to provide additional case-related information.

    6. Otherwise, if the taxpayer does not need to contact a specific employee, the correspondence needs only an IRS telephone number and standard signature.

    7. Secretaries, receptionists, or other people who answer the telephone in functional offices need to identify themselves and provide their ID Card (badge) number only if they are answering telephones which are routinely used to provide tax or account information, or if they provide a substantive response to the taxpayer's inquiry.

    8. It is not necessary to repeat the ID Card (badge) number on a subsequent contact, when the nature of an employee's work involves multiple contact with the same taxpayer, and the employee has given the taxpayer (either by telephone or in person) their ID Card (badge) numbers on the first contact.

3.13.122.4  (01-01-2010)
Taxpayer Advocate Service (TAS)

  1. This subsection contains information on referring cases to TAS.

3.13.122.4.1  (01-01-2010)
TAS Background Information

  1. The Taxpayer Advocate Service (TAS) is an independent organization within the IRS whose employees assist taxpayers who are experiencing economic harm, who are seeking help in resolving tax problems that have not been resolved through normal channels, or who believe that an IRS system or procedure is not working as it should.

  2. TAS criteria include economic burden, systemic burden, best interest of the taxpayer, and public policy (as determined solely by the National Taxpayer Advocate (NTA)). TAS is responsible for assisting taxpayers who have unresolved problems with the IRS. See IRM 13.1.7, Taxpayer Advocate Service (TAS) Case Criteria, if additional information is required.

  3. While the Internal Revenue Service (IRS) is continually working to serve customers in a quality manner, some taxpayers still have difficulty getting solutions to their problems or getting timely and appropriate responses to their inquiries. Per IRC § 7803(c), Congress established the office of the National Taxpayer Advocate (NTA) and its functions within the IRS to assist these taxpayers. TAS has identified criteria that qualify taxpayers for TAS assistance. The Case Advocate will conduct an independent review of actions that have been taken or need to be taken to resolve the problems taxpayers are experiencing.

  4. Employees should not view TAS Case Criteria as a means of excluding taxpayers from TAS, but rather, as a guide to TAS case acceptance. The criteria under which TAS accepts a case should not govern whether a taxpayer is entitled to relief.

3.13.122.4.2  (01-01-2009)
Referring Cases to TAS

  1. Refer taxpayers to the Taxpayer Advocate Service (TAS) (see IRM Part 13, Taxpayer Advocate Service) when the contact meets TAS criteria (see IRM 13.1.7, TAS Case Criteria) and you can’t resolve the taxpayer’s issue the same day. The definition of "same day" is within 24 hours. "Same day" cases include cases you can completely resolve in 24 hours, as well as cases in which you have taken steps within 24 hours to begin resolving the taxpayer's issue. Do not refer these cases to TAS unless they meet TAS criteria and the taxpayer asks to be transferred to TAS. Refer to IRM 13.1.7.4, Same-Day Resolution by Operations. When referring cases to TAS, use Form 911, Request for Taxpayer Advocate Service Assistance (and Application for Taxpayer Assistance Order), and forward it to TAS in accordance with your local procedures. Check the TAS box on AMS, if applicable.

    Note:

    It is important that all IRS employees handle potential TAS cases with the taxpayer's best interest in mind.

  2. Refer also to IRM 21.1.3.18, Taxpayer Advocate Service (TAS) Guidelines, for more information. Provide the taxpayer with the number for the NTA toll-free case intake line, 1-877-777-4778 or TTY/TDD 1-800-829-4059. The taxpayer should be advised that TAS is available if the taxpayer is not satisfied with the service he or she received.

  3. An IRS employee should make a referral to a TAS office if the employee receives a taxpayer contact, and cannot initiate action to resolve the inquiry or provide the relief requested. A taxpayer does not have to specifically request TAS assistance to be referred to TAS. IRS employees will advise taxpayers of the option to seek TAS assistance when appropriate. TAS will request documentation from the taxpayer if it is needed to support the requested relief, or required by the IRM.

3.13.122.5  (01-01-2010)
Transaction Posting and Cycling

  1. This tridoc contains posting and cycling information.

3.13.122.5.1  (01-01-2010)
General Information

  1. 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 transactions not posting in the correct order. 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, TDAs and refunds etc. are issued. The length of time needed to post a transaction varies.

  2. The posting sequence for all Master Files is generally from lowest numbered Transaction Code (TC) to the highest numbered TC.

    1. TC 011 always posts last to the entity portion of the Master File. It resequences to the next cycle.

    2. On the Business Master File (BMF), TC 150 always posts lasts to allow the tax module to settle properly.

      Example:

      TC 610, 670, 590, and 150 all attempt to post in the same cycle; posting order will be TC 590, 610, 670, then 150.

  3. The input transaction must be posted before the corrected unpostable can post:

    1. The unpostable must be delayed for at least one cycle or more, if necessary.

    2. The release cycle is input on line 9 with CC UPRES.

3.13.122.5.2  (01-01-2010)
Master File Resequencing

  1. Resequencing can delay posting from one to eleven weeks (depending on Master File).

    1. Resequencing can be identified on IDRS by the presence of "RS" transactions (if account is on IDRS).

    2. The following account resequence transactions (TC 011, 013, 040, 041) generally take two additional cycles to post. If the resequencing fails, the account will return to its original condition in the third cycle.

    3. Certain transactions such as merging, account number changes, credit offsets, and FTD mismatches require account resequencing at the Master File.

    4. Form 706 documents with a valid SSN will resequence for 3 cycles.

    5. Early filed returns with remittances will resequence until the RDD.

    6. Balance due e-File returns will resequence until cycle 20 or when the payment posts, whichever is earlier.

3.13.122.5.3  (01-01-2010)
Transaction Posting Time

  1. Transaction posting time depends on the input method as follows—

    1. Corrected unpostable transactions (URC—A, 0, 5, or 6) will be transmitted to Master File in the next cycle.

    2. IDRS transactions, excluding Data Processing (DP) Adjustments held up for review, will be transmitted to Master File in the next cycle.

    3. Transactions input through ISRP are on a regular or expedite cycle.

    4. Functional areas causing unpostables through errors should be alerted so corrective measures can be taken. Improper cycling-in delays posting and consequently delays refunds and billing.

    5. Unpostable cases closed with URC 8 will appear on the Reject Register or in ERS after the next GUF weekly update.

3.13.122.5.4  (01-01-2010)
Rules for Cycling

  1. Cycle transaction if—

    1. The prerequisite transaction has a higher transaction code.

    2. The prerequisite transaction is needed to change the status, filing requirements or balance, to freeze or release a freeze, or to set, change, or remove an indicator.

  2. Do not cycle-in transactions if—

    1. Posting sequence is not necessary.

    2. Prerequisite transaction will post first anyway.

  3. Cycling should be calculated by using the current MCC cycle plus the number of weeks it will take to post to Master File.

    Caution:

    When cycling transactions and entering the number of cycles (cycle delay code), consider the day of the week of input in relation to the day the SC updates to MCC/TCC. If the transaction is being input close to the end of the weekly posting cycle, an additional cycle may be necessary for the transaction to avoid repeat Unpostables. Refer to Exhibit 3.13.122-2, Later Releasing Chart.

3.13.122.5.5  (01-01-2010)
IDRS Programs with Posting Delay Codes

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

  2. Tax examiners must input a PDC with transactions to be cycled.

    1. Transactions can be delayed from one (1) cycle up to a maximum of six (6) cycles.

    2. The posting of these transactions to Master File will be deferred until the indicated number of posting cycles has passed.

  3. The PDC will not post with the transaction or be shown with the IDRS pending transaction. The projected MCC posting cycle on the IDRS "PN" (status pending) transaction will be extended to account for any PDC impact on the transaction.

  4. The following IDRS transaction programs have the posting delay capability:

    1. DP Adjustment CC ADJ54 (Doc. Code 54); AMCLSE (Doc Code 47).

    2. Entity Change CCs INCHG, BNCHG, (except EPMF) and EOCHG (Doc Codes 50, 53, 63, 80, and 81).

    3. Pre-journalized Credit Transfers CCs DRT 24 and DRT 48 (Doc Codes 24 and 48). See following (5).

    4. Dual Debit/Credit Transfer CC FRM 34 (Doc Code 34). See following (6).

    5. Miscellaneous Transactions CC FRM 77 (Cod Codes 77 and 78). See following (7).

  5. Pre-journalized Credit Transfer CCs DRT24 and DRT48 (Doc. Codes 24 and 48);

    1. The PDC can be specified for the debit and the credit side.

    2. This should be used for situations where the debit and credit must have different posting cycles; or delaying the debit to cycle the credit is inappropriate.

  6. Dual Debit/Credit Transfer CC FRM34 (Doc. Code 34);

    1. The PDC is entered only for the debit transaction.

    2. The credit transaction is not created until the debit posts to the master file; hence, a PDC is not necessary.

  7. Miscellaneous Transactions CC FRM77 (Doc. Codes 77 and 78).

    1. The PDC will not be available with the batch input program for Miscellaneous Transactions (CC FRM7A) until the input screen is redesigned.

3.13.122.6  (01-01-2010)
Taxpayer Delinquent Investigation (TDI) and Notice Delay Information

  1. This tridoc contains information for TDI and Notice Delay.

3.13.122.6.1  (01-01-2010)
Erroneous TDIs

  1. Erroneous TD's (Form TDI–14) or TDI Notices (Forms 4901 through 4904) can be generated when:

    1. A TDI satisfying transaction (TC 150, 474, 590, 591, 593, 594, 595, 596, 597, 598 or RPS 610) is unpostable and the transaction is nullified or not posted to master file within 45 days; or

    2. A TDI satisfying transaction attempted to post to the wrong module (MFT and/or tax period incorrect) or to the wrong account (TIN is incorrect).

  2. When nullifying (URC 1 or 8) a TC 150 or TC 610, and the TC 150 will not be re-input 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.

  3. 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.

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

    1. Use Closing Code "17" if the return is being processed BEFORE the Program Completion Date (PCD).

    2. Use Closing Code "18" if the return is being processed AFTER the PCD.

  5. All Unpostable initiated TC 59X should be input through IDRS using CC FRM49.

  6. Use CC TDINQ to research any unpostable TC 59X. Do not change posted entity data based solely on the information found on the unpostable TC 59X.

3.13.122.7  (01-01-2010)
Primary Transaction Code (TC) Prejournalized (PJ) Amounts

  1. To reduce the amount of interest paid due to return untimely processing, be aware that the TC PJ amount or Interest Reduction overpayment amount indicates that a refund is due to the taxpayer.

  2. An "Unpostable Case With Interest Free Period Due to Expire" is an alert to resolve the unpostable as quickly as possible.

  3. The unpostable cases (TC 150) with a refund due should be monitored and corrected to avoid paying interest with the refund.

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ after the Return Due Date (RDD), Received Date (RCD), or Return Processible Date (RPD), whichever is later.

  5. See IRM 3.12.32, General Unpostables, for additional procedures.

3.13.122.8  (01-01-2010)
The Entity Section

  1. The Entity Section consists mainly of the following elements:

    • Name

    • Address

    • Taxpayer Identifying Number (TIN)

    • Date of Birth (DOB)

    • Spouse's Name

    • Spouse's Social Security Number (SSSN)

    • Filing Status Code (FSC)

    • Year Digit (YD)

    • Mail Filing Requirement (MFR)

    • SSA, IRS valid, and IMF Name Controls

    • Scrambled SSN Indicator (XXXSSN)

    • Date of Death (DOD)

  2. The TIN may be a Social Security Number (SSN), Individual Taxpayer Identifying Number (ITIN), Adoption Taxpayer Identification Number (ATIN), or Internal Revenue Service Number (IRSN).

    1. ITIN -- is assigned to the taxpayer by the IRS when processing Form W-7, Application for IRS Individual Taxpayer Identification Number. An ITIN can be identified by a 9 in the first position and the fourth and fifth positions are 70 through 88 (9XX-(70-88)-XXXX).

    2. ATIN -- is assigned on a database and can be identified with a 9 in the first position and 93 in the fourth and fifth positions (9XX-93-XXXX).

    3. IRSN -- is assigned by the IRS when a valid account cannot be found. An IRSN can be identified by a 9 in the first position and a valid campus code in the fourth and fifth positions. See IRM 3.13.5, IMF Account Numbers, for additional information on the valid campus codes. See IRM 3.13.122.8.2.

      Note:

      Typically an IRSN is not assigned to anyone other than the primary taxpayer.

  3. Taxpayers may not be entitled to receive the Earned Income Tax Credit (EITC) when using an IRSN.

    Exception:

    A "true" scrambled SSN case will result in all affected taxpayers receiving the EITC. Refer to IRM 21.6.2.4.2(4).

    However, taxpayers are entitled to claim a personal exemption when they use an ITIN, but are not allowed EITC. URC 8 to Rejects to remove the unallowed exemption and/or EITC amounts if an IRSN or ITIN is present on the return.

  4. Instructions on correctly entering taxpayer names and name controls are contained in IRM 3.13.5, IMF Account Numbers and the Name Control Job Aid (Document 7071).

3.13.122.8.1  (01-01-2010)
Entities Do Not Agree

  1. Research entities via CCs ENMOD and NAMES to determine differences in name, address, filing requirements, FYs, or employment codes.

  2. If research indicates differences between Master File and the unpostable condition:

    1. Update Master File via CC INCHG;

    2. If necessary, assign a new IRSN to the account. If the unpostable is a TC 150 and the return includes EITC, edit the IRSN on the return and URC 8 to Rejects requesting the amount be removed.

      Note:

      If it is discovered that the item is a scrambled case, or that multiple filers are involved, take no action until you coordinate the case with Adjustments. Follow their directions regarding resolution, annotate in the remarks "Scramble Coord with AM" .

  3. If research DOES NOT provide sufficient information to correct the UPC, contact the taxpayer.

3.13.122.8.2  (01-01-2010)
Assigning Internal Revenue Service Numbers (IRSNs)

  1. IRSNs must be assigned only after complete research is conducted.

  2. The method of assigning IRSN's varies from center to center.

  3. The IRSN can be identified by having a "9" in position one of the SSN (9XX-XX-XXXX).

    Exception:

    If the 4th and 5th position numbers are 70 through 88, the number is an ITIN (9XX-(70-88)-XXXX) and should be treated as an SSN.

3.13.122.8.3  (01-01-2010)
Data Master One (DM-1) File

  1. Three sources of information are received and weekly update the DM-1:

    • SSA

    • Individual Taxpayer Identification Number (ITIN)

    • IRS valid processing

    This data base can carry more than one name control for a TIN and they are not listed in any specific order.

3.13.122.8.4  (01-01-2010)
Resolving Taxpayer Identification Numbers (TINs)

  1. Entity can receive any unpostable for resolution of multiple TIN issues.

  2. The IMF is structured into two segments "valid and invalid."

  3. The valid and invalid segments contain the Taxpayer Identifying Number (TIN) and Name Control. The name control is the first four characters of the primary taxpayer's last name.

  4. A TIN/Name Control's validity is determined by finding a matching TIN/Name Control on the DM-1 or SSA NC.

  5. The most common reasons for invalid account numbers are change in marital status, transcription/input errors by the IRS, or taxpayers using an incorrect TIN.

  6. The same taxpayer can be on IMF (valid and invalid segments).

  7. Two different taxpayers can be on IMF under the same TIN (valid and invalid segments).

  8. If two or more TINs are located for the same entity, a consolidation should be done.

  9. Always research completely to determine if the TIN agrees with what is correct. When researching an IMF unpostable condition, search both the valid and invalid segments of the Master File.

  10. If the unpostable TIN is incorrect and you cannot locate a new TIN, use CC IRSN to assign the taxpayer a temporary number. Edit the IRSN on the document and correct the unpostable accordingly.

    1. If the unpostable is a TC 150 and the return includes amounts for a personal exemption and/or EIC, edit the IRSN on the return and URC 8 to Rejects requesting the amounts be removed.

    2. If the unpostable is a TC 150 without amounts for personal exemption and/or EIC, or any other TC, close the unpostable with URC 6.

3.13.122.8.5  (01-01-2010)
TIN Related Transaction Codes

  1. When accounts move from one TIN to another or from one segment to the other (i.e., invalid to valid), it is referred to as resequencing or merging. All parts of the Master File (i.e., INOLE, ENMOD, TXMOD, etc.) do not all merge at the same time.

  2. These TCs apply to resequencing accounts:

    TC Description
    TC 011* TIN change on an account on Master File.
    TC 013* Name change for an account on the valid segment of Master File
    TC 040 To direct a TIN and/or TIN of an account to the VALID segment of Master File
    TC 041 To direct a TIN and/or TIN of an account to the INVALID segment of Master File
    * These TCs are systemically compared against the DM-1 file.

  3. Resequencing accounts is accomplished by automatic resequencing or the input of an entity transaction.

  4. TC 011, 013, 040, or 041 should not be input when the following situations are present on the account. Resequencing will result in a No Merge status.

    1. A TC 150 for same year is posted on both accounts.

    2. The name control of the "from" account does not match the name control of the "to" account (IMFOLE).

    3. One or both accounts contain a vestigial record (removal of modules to Retention Register) for the same tax period (IMFOLV).

    4. Either account contains an unreversed TC 914, 916, or 918 (IMFOLT/IMFOLE).

    5. One or both accounts contain a module with an unreversed TC 400, 424, or 576 (IMFOLT).

    6. Either account contains MFR 08 and Scrambled SSN Indicator (SCI) (IMFOLE).

    7. Both accounts have a combination of a TC 150 and multiple TCs 610 (one of which is RPS), or a TC 150 ("S" coded) on one module and the other module contains an RPS TC 610 not matching the DLN of TC 150 (IMFOLT).

    8. Both accounts contain a module in TDI Status 03 or TDA Status 22, 24, 26, or 60, and location codes (primary and secondary) are not in agreement (IMFOLS).

    9. Both accounts contain a module for same tax year and there are more than 3 TCs 766, Doc Code 54, blocking series 400-499 posted in the accounts (IMFOLT).

    10. Both accounts contain a module for same tax period with an unreversed TC 520 (except closing codes 81 or 85-88) (IMFOLT).

    11. Both accounts contain a module for same tax year and "from " account contains a significant CAF indicator (IMFOLE).

    12. The "from" account contains an indicator in the Abusive Tax Shelter field on ENMOD (IMFOLE).

    13. The "from" account contains a civil penalty name line which does not match the name control of the "to" account (IMFOLE).

    14. Both accounts contain a TC 060, 930, or 940 (IMFOLE and IMFOLT).

    15. The "from" account contains a TC 896 or TC 898 within 6 years of the current 23C date. See IRM 21.4.6.4.21, Resequence Cases.

    16. Only one account contains a Potentially Dangerous Taxpayer (PDT) indicator (IMFOL).

    17. IRA accounts.

3.13.122.8.5.1  (01-01-2010)
IMF Name Changes (TC 013)

  1. When entering a name change (TC 013) to update/correct a joint return filer, it is important to ensure the joint names are in the proper format for the issuance of notices and overpayments.

    Note:

    If the name control on the document is not present as an SSA name control on INOLES, see 3.13.122.8.5.2.

  2. If joint filers require a notice, two notices are issued (one to the taxpayer and another to the secondary taxpayer).

  3. Although the Form 1040 consist of two lines for entering joint names, Master File is limited to ONLY one line for the "Primary Name Line" .

  4. Master File Name Line field must never exceed 35 characters/spaces. It is imperative the name line information is contained in the FIRST NAME LINE ONLY.

    Note:

    DO NOT use the second line as a continuation of the name line. CC INCHG's second name line is used to enter taxpayer information and titles such as DECD, Guardian, Custodian, In Care Of, etc.

    Note:

    The absence of TWO BRACKETS around the PRIMARY taxpayer's last name when the SECONDARY taxpayer's name is different will create unnecessary Unpostable conditions.

  5. Examples of properly input name changes are shown below. Bold print indicates the primary name control.

    Tax Return Input format for joint filers
    John Doe
    Mary Doe     		John & Mary]Doe
    John Doe
    Mary Smith     		John]Doe]& Mary Smith
    John Doe
    Mary Smith-Doe     		John]Doe]& Mary Smith-Doe
    John D Doe
    Mary Ann Smith-Doe     		John D]Doe]& Mary Ann Smith-Doe
    John D Doe III
    MaryAnn L Smith     		John D]Doe]III& MaryAnn L Smith

  6. The above information CORRECTLY entered will display on CC ENMOD and generate two separate notices:

    1. John & Mary Doe (John Doe & Mary Doe)

    2. John Doe & Mary Smith

    3. John Doe & Mary Smith-Doe

    4. John D. Doe & Mary Ann Smith-Doe

    5. John D. Doe III & MaryAnn L Smith

    Entity Formats
    The ampersand (&) indicates to Master File that the information following is the Secondary taxpayer's name.
    The brackets ([ ]) indicates to Master File that the information contained within is the Primary taxpayer's surname of the account when a joint name line is entered.
    No blank spaces should be typed between the brackets when entering name line information for a taxpayer filing SINGLE/Head of Household.
    However, a blank space is always required immediately following the ampersand when entering JOINT filer information.

  7. If the primary and secondary names exceed 35 characters/spaces, see IRM 3.13.5 or Name Control Job Aid, Document 7071 for additional information.

3.13.122.8.5.2  (01-01-2010)
IMF Name Changes TC 040 and TC 041

  1. Generally TC 040/041 is used when a taxpayer has a name change due to marriage, but has not updated with SSA to display the new name control.

  2. TC 040 is used to change the name and/or TIN of the taxpayer's account that resides on the valid segment of IMF.

  3. TC 041 is used to change the name and/or TIN of the taxpayer's account that resides on the invalid segment of IMF.

  4. TCs 040 and 041 do not go through DM-1 validation processes. These TCs should not be used unless IMF established the taxpayer incorrectly; or the taxpayer provides "proof" of their identity through copies of marriage certificates, divorce decrees, legal documents showing a name change, etc.

  5. Before entering a TC 040 or TC 041, thoroughly research the taxpayer's account using INOLES. If necessary, request a NUMIDENT for the taxpayer using MFTRAU to determine the most recent and all the SSA Name Controls reported by the taxpayer.

  6. Information needed to complete a TC 040 or TC 041 is listed below:

    1. New Name Control

    2. Primary Name Line (All Name Lines for TC 040)

    3. Year Name Line

    4. Filing Status Code

    5. New TIN, if necessary

    6. Description of change in the REMARKS field.

3.13.122.8.6  (01-01-2010)
IMF Automated Establishment of Taxpayers

  1. Individual Master File (IMF) completes a special process to establish the secondary taxpayer on Master File for all Married Filing Joint (FSC 2) accounts. With this automated process, IMF separates the secondary taxpayer from the primary taxpayer account and systemically establishes a separate account on Master File.

    Note:

    IMF will not establish secondary taxpayer's accounts when: the Secondary SSN (

    Note:

    S-SSN) is invalid or not available; DECD is present in the Secondary Name Line; the Primary SSN is the same as the S-SSN; or no spouse name indicated when the primary taxpayer filed using FSC 2 or 7..

  2. The accounts systemically established by IMF will display transaction codes with a unique DLN of XX263-001-88888-X. The transaction code(s) may be a combination of TC 000, 01X, or 971 with AC 050 (to change the BOD code).

  3. Unpostables 151, 152, 153, or 156 created by this systemic process require input of TC 040 (valid side) or TC 041 (invalid side) to bypass the NAP and correct the secondary taxpayer's name. See 3.13.122.8.5.2 for TC 040/041 information.

  4. See IRM 3.13.5.8, IMF Account Numbers, for additional information.

3.13.122.9  (01-01-2010)
Accounting Period Change

  1. Approval must be requested if a taxpayer wishes to change an established accounting period. The initial return (TC 150) or extension (TC 620 or 460) with estimated payments filed by the taxpayer will establish the Fiscal Year Month (FYM).

  2. Generally IMF filers DO NOT file FY Returns. If a taxpayer is a FY filer, this information is available.

3.13.122.10  (01-01-2010)
Payment Information

  1. To resolve a voided unpostable return that is assigned to Entity with a remittance, the money must be applied to the return.

  2. If the return contains a misapplied remittance and after thorough research (including RTR) you cannot determine where the payment should be applied, send the payment to the Unidentified Remittance File.

  3. When a payment is sent in with a return, both the payment and the return transaction codes should have a Computer Condition Code (CCC) S.

  4. The most common payment TCs are 610, 660, 670, 430, 710 (this list is not all inclusive of payment TCs).

3.13.122.10.1  (01-01-2010)
Remittance Transaction Research (RTR) System

  1. The Remittance Transaction Research (RTR) system is a researchable database that contains remittance processing data and images from ISRP and Lockbox Bank processing sites. Payment transaction data is made available to access images of remittances and related documents to conduct on-line research to correct processing errors.

  2. RTR provides 3 years of images online for immediate retrieval. Images more than 3 years old are stored offline. These can be retrieved through an online request, which is retrieved and made available by the next business day. Historical data and images in both the old RTR and InfoImage systems will be converted and made available. Historical data and images from the Lockbox Banks will not be made available.

3.13.122.10.2  (01-01-2010)
If TC 150 and TC 610 are Unpostable

  1. Associate both cases and research for a different entity.

    1. If the entity is established, post the transaction.

    2. If the entity is not established, take the necessary action to establish or update the entity.

3.13.122.10.3  (01-01-2010)
If TC 150 is Unpostable with a Posted TC 610

  1. If TC 610 is posted to the correct entity, post the TC 150 transaction.

  2. If TC 610 is not posted to the correct entity and the entity is not established,

    1. Establish the entity.

    2. After the entity has been established, transfer the posted TC 610 to the correct entity using a Posting Delay Code, if necessary.

    3. Release the TC 150 to post after the TC 610, cycle if necessary.

  3. If TC 610 is posted to the wrong entity and the correct entity is established,

    1. Transfer the TC 610 to the correct entity.

    2. Release the TC 150 to post after the TC 610, cycle as necessary.

3.13.122.10.4  (01-01-2010)
If TC 610 is Unpostable

  1. When the TC 610 is unpostable, use all appropriate research to find the matching TC 150.

    1. If found, post the TC 610.

    2. If not found, resolve the TC 610 per the specific unpostable code instructions.

    3. If TC 150 has been shelved (IMF ONLY), ensure proper posting of both the TC 610 and the TC 150.

3.13.122.11  (01-01-2010)
Decedent Returns

  1. The sensitive nature of Decedent returns requires special procedures to ensure the proper person receives the refund check.

  2. Decedent returns must have a Date Of Death (DOD). If Form 1310 or a court certificate is not attached to a return (TC 150) claiming a refund, correspond with 12C letter and suspend the case using CC UPCAS SC.

    Note:

    Form 1310/Court Certificate is not required for Filing Status Code (FSC) 2. The surviving spouse can claim the joint refund.

    1. If taxpayer's reply contains the requested information (Form 1310 or Court Certificate), input TC 540 for the year of death to indicate a deceased taxpayer, and close case accordingly. Cycle case as appropriate. Make sure "DECD" is entered in taxpayer's entity. Attach 12C letter to return.

    2. If there is no reply or the reply is incomplete (i.e., not present or signed, date of death missing, or proper payee cannot be determined), close the case using URC 8. Route to Rejects indicating CCC "3" and CCC "U" should be input. Enter "No Reply from Letter" or "incomplete Information Received Letter" in "Remarks" . Attach a copy of 12C letter to return.

  3. Joint returns:

    If... And DOD... Then...
    Return has Filing Status 2 with two names on Name Line and Claimed Dependent Children Within 2 years of the Tax Period of the Return URC 8 and request Rejects change Filing Status to 5 and remove decedent taxpayer from name line.
    Return has Filing Status 5 and dependent children are claimed Is more than 2 years URC 8 and request Rejects change the Filing Status to 4.
    Return has Filing Status 5 and there are no dependent children claimed Is more than 2 years URC 8 and request Rejects change the Filing Status to 1.
    Return has Filing Status OTHER than 2 with two names on Name Line Is within tax period URC 8 and request Rejects change the Filing Status to 2.
    Return has Filing Status 5 with only ONE name on the Name Line Is within tax period Correspond. If reply contains requested information, correct accordingly. If NO reply or incomplete, URC 8 and request the input of CCC 3 or U.

  4. Other than JOINT return:

    1. "DECD" must be entered after the taxpayer's last name (after any existing suffix).

    2. Always enter a second name line, if available. On overpaid returns a second name line is mandatory. The refund is issued to the person(s) whose name(s) is shown on the second name line. If the proper payee cannot be determined, correspond to the "Estate of … " .

    3. Include the suffix for any name indicating a court-appointed personal representative, such as: Administrator, Executor, Administrative Exec., Trustee, etc.

    4. The second name line should not include any suffixes such as "surviving spouse" , "mother" , "father" , "daughter" , "son, " etc.

  5. For more specific procedures, refer to IRM 3.13.5, Individual Master File (IMF) Account Numbers.

3.13.122.12  (01-01-2010)
Research Command Codes (CCs) —IDRS

  1. This section contains IDRS Research Command Codes (CC).

  2. Input formats are provided on some of the CCs more commonly used in the Unpostable unit. IRM references for additional information are provided for each CC and CC job aids are available online via through Servicewide Electronic Research Program (SERP).

3.13.122.12.1  (01-01-2010)
CC ENMOD

  1. CC ENMOD provides the entity data if the account is on the Taxpayer Information File (TIF).

  2. The input format for CC ENMOD is "ENMOD nnn-nn-nnnn" for IMF or "ENMOD nn-nnnnnnn" for BMF.

  3. See IRM 2.3.15, Command Code ENMOD, for additional information.

3.13.122.12.2  (01-01-2010)
CC ENREQ/INCHG/IRCHG

  1. CC ENREQ is used to generate the input screens CC INCHG or CC IRCHG to initiate an entity change for an account on the TIF.

    1. CC ENMOD must be input prior to CC ENREQ.

    2. CC ENREQ will generate CC INCHG.

    3. CC ENREQR will generate CC IRCHG.

  2. See IRM 2.4.9, Command Codes ENREQ, INCHG, IRCHG, BNCHG, and BRCHG, for additional information.

3.13.122.12.3  (01-01-2010)
CC ESTAB

  1. CC ESTAB is used to obtain original returns/documents from Files and request transcripts from microfilm.

  2. See IRM 2.3.17, Command Code ESTABD, IRM 2.3.18, Command Code ESTABM, and IRM 2.3.62, Command Code ESTAB, for additional information.

3.13.122.12.4  (01-01-2010)
CC NAMEI/NAMES

  1. CCs NAMEI/NAMES are the primary methods to access the Name Search Facility (NSF) used to research a national file of name and address data at Martinsburg Computing Center (MCC), using the taxpayers name and address to locate a TIN.

  2. The NSF contains the full taxpayers name as it was filed on the return and maintains multiple addresses for each taxpayer name.

  3. The following tables provide the NAMEI input formats for desired results and explanations of the input fields:

    INPUT FORMAT
    NAMEIaavvvvvvvvv,avvvvvvvvv,nnnvnnn,vvvvvv Researches for a taxpayer’s Social Security Number (SSN) on the National Name Search Facility (NSF) using the last name, first name, and address information.
    NAMEIaavvvvvvvvv,a,nnnvnnn,vvvvvv Researches for a taxpayer’s SSN on the NSF using the last name, first initial, and address information.
    NAMEIaavvvvvvvvv,-,nnnvnnn,vvvvvv Researches for a taxpayer’s SSN on the NSF using only the last name and address information.

    Note:

    The input fields above are variable in length (defined in the following table) and, when present, must be separated by a comma.

    INPUT FIELD EXPLANATIONS
    a Blank — Regular search.
    B — Business Master File (BMF) display only.
    I — Individual Master File (IMF) display only.
    N — Non-Master File (NMF) display only.
    Q — Invalid SSN display only.
    X — Hardcopy listing.
    avvvvvvvvv Taxpayer’s last name. Up to 10 characters may be entered, and all are used for matching
    avvvvvvvvv Taxpayer’s first initial or first name. A maximum of 10 characters may be entered. Input a hyphen (-) if the first initial and name are unknown
    nnnvnnn Taxpayer’s ZIP Code. The first three digits or the full five-digit ZIP Code must be present if the street address is input. A ZIP code range (nnn-nnn) may also be input. Enter three zeros (000) for a foreign address.
    vvvvvv First six characters of the Taxpayer’s street address or PO Box number. The literal PO BOX should not be used, only the number.

  4. See IRM 2.3.60, Command Code NAMES, NAMEE, NAMEI, and NAMEB, for additional information.

3.13.122.12.5  (01-01-2010)
CC MFTRA (Including NUMIDENT)

  1. CC MFTRA is used to request a hard copy transcript of the taxpayer's account.

    Note:

    Other appropriate IMFOL command codes are to be used before using CC MFTRA when possible.

  2. NUMIDENT—A Social Security Number Identification File which contains entity information. This information is requested with CC MFTRA and request type " U" . The information includes:

    1. Type of SSN Record on File

    2. The Month, Day, and Year the application or correction was recorded on the SSA File

    3. The Disability Status Indicator

    4. The name on the SSN card to be used in work/business

    5. The name on the most recently assigned SSN card, Name at Birth, or any other name(s) used

    6. Any additional names used

    7. Citizenship

    8. Sex

    9. Date of Birth

    10. Place of Birth

    11. Prior Date of Birth

    12. Mother's Maiden Name

    13. Father's Name

  3. See IRM 2.3.32, Command Code MFTRA, for additional information

3.13.122.12.6  (01-01-2010)
CC IMFOL

  1. CC IMFOL provides on-line research capability of Nationwide entity and/or tax data information posted to the Master File. The information is displayed in read only format which cannot be updated. CC IMFOL display consists of entity, posted, return, status, vestigial, and adjustment data. It also displays an index of tax modules for a particular taxpayer. CC IMFOL can be accessed when IDRS is down.

    1. Most accounts will be on-line and accessible. Accounts that are not on-line can be accessed overnight and will remain on-line for 28 days.

      Note:

      Since the Master File On-Line IMFOL does not contain all of the information available on the IDRS screen displays (for example, IDRS notice status, case control information, pending transactions, etc.), it is imperative that you initiate IDRS research before accessing CC IMFOL. CC IMFOL cannot precede command codes which cause changes to the Master File data (for example, IMFOL cannot precede REQ54).

    2. IMFOL does not show pending transactions, IDRS control bases or history items, unpostable or most resequencing transactions.

    3. A definer is required with CC IMFOL. Each definer displays specific tax account information. Listed below is a description of each definer available with CC IMFOL:

    Definer Description
    A Adjustment transactions for a specific taxpayer identification number (TIN) Master File Tax Code (MFT), tax period.
    B Restore recoverable retention tax modules (dropped from 1994 to present) back to the active Master File. Recoverable Retention Register (RRR) tax modules are listed on the Index Screen.
    E General entity information and entity transactions for a specific TIN.
    H Help screens for CC IMFOL.
    I An index screen displaying what tax modules exist and whether or not they are on-line for a specific TIN.
    P Once you have issued one of the other definers you can obtain additional pages with this definer. It must be followed by the page number you want.
    Q Allows the querying of a "resequencing" TC 610 by TIN or payment amount.
    R A TC 150 posted return for a specific TIN/MFT and tax period.
    S The status history data for a specific TIN/MFT/tax period.
    T The general tax module data and tax module transactions for a specific TIN/MFT/tax period.
    V The vestigial data (what modules have been moved to the retention register and when) for a specific TIN.
    Z Audit History Screen

  2. The input formats of the modifiers most commonly used in Unpostables are displayed in the following table:

    IMFOL INPUT FORMATS WITH MODIFIERS
    IMFOLEnnn-nn-nnnnv Definer "E" with an SSN, and a display file source will result in the display of various indicators and freeze codes as well as posted transactions in the entity.
    IMFOLInnn-nn-nnnnv Definer "I" with an SSN, and a display file source will result in the display of an index of all the tax modules for the input SSN.
    IMFOLPnnn-nn-nnnnvyyyymm yyyymm Definer "P" with an SSN, a display file source, a From Date and a To Date will result in this display of payment transactions posted to the SSN within the time frame specified by the From and To dates. Payment transactions with posting dates from the first day of the month in From Date to the last day of the month in To Date are displayed.
    IMFOLRnnn-nn-nnnnvnnyyyymm Definer "R" with an SSN, a display file source, an MFT, and a tax period will result in this display of the posted return for the specified tax module.
    IMFOLTnnn-nn-nnnnvnnyyyymm Definer "T" with an SSN, a display file source, an MFT, and a tax period will result in the display of various module amounts and dates along with a listing of posted transactions for the specified tax module.
    IMFOLVnnn-nn-nnnnv Definer "V" with an SSN, and a display file source will result in the display of the vestigial section of the entity. The vestigial screen lists the tax modules in the account that have been aged off to the retention register.
    IMFORannn-nn-nnnnvnnyyyymm yyyy Displays retention tax modules (1994 and later) from accounts that merged to a new TIN after the tax module had been dropped to retention and IRA Tax Modules that have been archived.

  3. See IRM 2.3.51, Command Code IMFOL, for additional information.

3.13.122.12.7  (01-01-2010)
CC RTVUE

  1. CC RTVUE enables access of return data and review of the response screen layouts used for displaying the Form 1040 series returns and attached forms/schedules.

    1. When working a case, information may be needed which was computer-generated and/or transcribed from individual line items on Form 1040A, 1040EZ, 1040NR, 1040SS/PR, and 1040. This material will cover how to access these documents using IDRS.

      Note:

      Since the Individual Returns Transaction File (RTVUE) does not contain all the information available on the IDRS screen displays (for example, IDRS notice status, case control information, pending transactions, etc.), it is imperative that you initiate IDRS research before accessing.

    2. CC RTVUE with definers is used to access data that was computer-generated and/or transcribed from individual line items from the Form 1040 series and accompanying schedules/forms.

    3. CC RTVUE is a research only command code. Return Transaction File data cannot be updated, nor does it show any adjustments made, or amended/duplicate return information.

    4. A two character/digit definer is input with CC RTVUE to access the returns, schedules, and forms. Definer SM accesses the tax return Summary screen which provides information including the filing status, dependents, exemptions, income tax deductions, payments, and all schedules/forms filed (including dollar totals). All schedules and/or forms shown on the Summary screen may be accessed by the appropriate number or letter combination definer to request specific information.


Next

More Internal Revenue Manual