Part 21. Customer Account Services
Chapter 7. Business Tax Returns and Non-Master File Accounts
Section 10. No-Merge Cases
21.7.10 No-Merge Cases
Manual Transmittal
August 27, 2024
Purpose
(1) This transmits revised IRM 21.7.10, Business Tax Returns and Non-Master File Accounts, No-Merge Cases.
Material Changes
(1) The following table outlines changes made to IRM 21.7.10, No-Merge Cases. Various editorial changes were made throughout the IRM. Also, cross references and hyperlinks were added, removed, or revised, as appropriate.
IRM Reference | Material Changes |
|---|---|
IRM 21.7.10.3(1)(2) | IPU 23U118 issued 11-22-2023. Corrected link in (1) to IRM 3.13.2.14.1, Consolidating Accounts per SERP Feedback #14182. Added verbiage in (2) to address 4442’s from the Puerto Rico AM Directorate. |
IRM 21.7.10.4.6.4.2 | Revised note in (1). Moved (2) inside If/Then chart and added link to IRM 21.10.4.6.1.1, One Taxpayer Involved (NOMRG-DUP), for clarity. |
Effect on Other Documents
IRM 21.7.10, dated 08-17-2023 (effective 10-01-2023), is superseded. Interim Procedural Update (IPU) 23U118 issued 11-22-2023 is incorporated in this publication.
Audience
This IRM is intended for Taxpayer Services, Customer Account Services, and Small Business/Self-Employed employees who handle issues related to Business Master File Tax Returns.
Effective Date
(10-01-2024)
LuCinda Comegys
Director, Accounts Management
Taxpayer Services Division
No-Merge Program Scope and Objectives
(1) This section contains information on Business Master File (BMF) account consolidation. An unsuccessful attempt to merge (consolidate) an account is called a no-merge condition. This section also describes the various BMF No-Merge (NOMRG) transcripts generated by master file.
(2) Purpose: To provide procedures for resolving no-merge conditions identified by NOMRG transcripts.
The IRS mission is to provide America's taxpayers top quality service by helping them understand and meet their tax responsibilities and by applying the tax law with integrity and fairness to all.
The IRS will not tolerate discriminatory treatment of taxpayers by its employees in any programs or activities supported by the Service. No taxpayer should be subject to discrimination in educational programs or activities based on sex, race, color, national origin, disability, reprisal, religion, or age.
If a taxpayer believes they have been discriminated against on the basis of sex, race, color, national origin (including limited English proficiency), disability, reprisal, religion, or age, advise the taxpayer that he/she can forward an e-mail to:*EDI.Civil.Rights.Division@irs.gov, file a complaint online, a form can be found online at Civil Rights On-Line form, or send a written complaint to:
Internal Revenue Service
Office of Equity, Diversity and Inclusion, CRU
1111 Constitution NW Rm 2413
Washington, DC 20224
The Taxpayer Services (TS) and Small Business/Self Employed (SB/SE) Business Operating Divisions (BODs) are responsible for taxpayer relationships by:
Providing general tax related information,
Providing information on the status of taxpayer returns/refunds/accounts, and
Adjusting taxpayer accounts, when appropriate.
These responsibilities are divided into three subordinate units:
Customer Assistance, Relationships, and Education (CARE)
Customer Account Services (CAS)
Compliance
To ensure taxpayer inquiries and accounts are addressed correctly, Taxpayer Assistance Centers (TAC), Accounts Management (AM), and Compliance Services use the guidelines provided in IRM 21, Customer Account Services
(3) Audience: The primary users of this IRM are Customer Service Representatives (CSR) and Tax Examiners (TE) who are assigned no-merge inventory.
(4) Policy Owner: The policy owner is the Director, Accounts Management, Taxpayer Services Division.
(5) Program Owner: The program owner is Process and Program Management (PPM), Accounts Management, Taxpayer Services.
(6) Primary Stakeholders: The primary stakeholders are Taxpayer Services (TS), Small Business Self Employed (SBSE), and Large Business and International (LB&I).
(7) Program Goals: Program goals for this type of work are included in the Accounts Management Program Letter as well as IRM 1.4.16, Accounts Management Guide for Managers.
Background
(1) Employees in the Accounts Management (AM) organization respond to taxpayer inquiries (phone and paper) as well as process claims, certain applications, internal adjustment requests, and transcripts.
(2) IRM 21.7.10 provides guidance to AM employees assigned no-merge inventory.
Authority
(1) Delegated authorities and policy statements related to Accounts Management can be found in IRM 1.2.1.13, Policy Statements for Customer Account Services , for more information.
Roles and Responsibilities
(1) The Taxpayer Services Commissioner has overall responsibility for the policy related to this IRM, which is published on a yearly basis.
(2) Additional information is found in IRM 1.1.13.7.3, Accounts Management, and IRM 21.1.1, Accounts Management and Compliance Services Overview.
Program Management and Review
(1) IRM 1.4.16, Accounts Management Guide for Managers, provides guidance for program management and review of programs assigned to Accounts Management.
Program Controls
(1) Goals, measures, and operating guidelines are listed in the annual Program Letter.
(2) Quality data and guidelines for measurement are referenced in IRM 21.10.1, Embedded Quality (EQ) Program for Accounts Management, Campus Compliance, Field Assistance, Tax Exempt/Government Entities, Return Integrity and Compliance Services (RICS) and Electronic Products and Services Support.
Terms/Definitions/Acronyms
(1) T
Note: The most common acronyms used are spelled-out within the IRM subsections.
Related Resources
(1) In addition to this IRM and resources cited within, assistors may need to refer to other IRMs and supplemental resources such as the following:
IRM 1.1.13.7.3, Accounts Management
IRM 1.4.16, Accounts Management Guide for Managers
IRM 2.3.11, Command Codes TXMOD and SUMRY
IRM 2.3.15, Command Code ENMOD
IRM 2.3.18, Command Code ESTABM
IRM 2.3.47, Command Codes INOLE, EOGEN, and SPARQ
IRM 2.3.59, Command Codes BMFOL and BMFOR
IRM 2.3.32, Command Code MFTRA
IRM 2.4.9, Command Codes ENREQ, INCHG, IRCHG, BNCHG, and BRCHG
IRM 21.2.2-2, Accounts Management Mandated IAT Tools
Document 6209, IRS Processing Codes and Information
(2) Below are additional websites, job aids, or electronic tools that are required to assist in completing work in Accounts Management:
The Account Management Services (AMS) is a web-based system that emphasizes the sharing of key business data and provides a consolidated and synchronized view of taxpayer data and contact information from various IRS systems.
The Correspondence Imaging Inventory (CII) is for scanning all Accounts Management adjustment receipts and correspondence into digital images for case work resolution.
The Employee User Portal (EUP) may be used to view corporate and individual electronic tax returns filed via MeF.
Servicewide Electronic Research Program (SERP) can be utilized to find SERP Alerts, IPUs, Correspondex Letters, IRM Supplements and other information.
The Electronic Publishing website can be used to research forms, instructions, publications, and other Internal Revenue Manuals, revenue procedures and IRS announcements.
What Are No-Merge Transcripts?
(1) The common No-Merge (NOMRG) transcripts worked by Accounts Management include:
NOMRG–DUP - IRM 21.7.10.4.6.1
NOMRG–RPS - IRM 21.7.10.4.6.2
NOMRG–400 - IRM 21.7.10.4.6.3
NOMRG–VEST - IRM 21.7.10.4.6.4
REVAL–VEST - IRM 21.7.10.4.6.4
(2) Business Master File (BMF) generated NOMRG transcripts are listed below:
NOMRG AF - A complete transcript generated when a merge is attempted, both accounts have an Exempt Organization (EO) section, and one account has affiliation code of 6 or 8 (central organization) and the other has affiliation code of 7 or 9 (subordinate organization).
NOMRG CONS - A transcript generated when the sum of the transaction section byte counts, excluding the return byte count, if present, exceeds 20,900 bytes.
NOMRG DUP - A complete transcript generated when an account merge fails because tax modules for equal periods each contain Transaction Code (TC) 150.
NOMRG FYM - A complete transcript generated when a merge fails because both Taxpayer Identification Numbers (TIN) have a different fiscal year month (FYM).
NOMRG GEN - A complete transcript generated when a merge is attempted, both accounts have an EO section, and the Group Exemption Numbers (GEN) are different (neither EO status is zero).
Note: The GEN is a four-digit number that uniquely identifies a central organization and its named subordinates on whose behalf the central organization has applied for a group ruling of exemption.
NOMRG NOUS - A complete transcript generated when a merge fails because one account has a foreign address and the other does not.
NOMRG RPS - A complete transcript generated for an attempted merge when the Remittance Processing System (RPS) transaction codes are not compatible. Both modules contain a Transaction Code (TC) 150 with multiple TC 610 (one is an RPS). The TC 610 and TC 150 Document Locator Numbers (DLN) do not match.
NOMRG SS - A complete transcript generated when a merge is attempted, both accounts have an EO section, and both accounts have non-zero EO current status codes and non-zero subsection codes which are different.
NOMRG STAT - A complete transcript generated when a merge is attempted, both accounts have an EO section, and their EO statuses are incompatible.
NOMRG TOP - A complete transcript generated when a merge failed because tax module either had an unreversed TC 896 dated less than 6 years prior to Revenue Accounting Control System (RACS) 006 date, or any TC 898 with significant net memo amount dated less than 6 years prior to RACS 006 date and does not meet REVAL conditions.
NOMRG VEST - A complete transcript generated when an account merge fails because one account contains a vestigial record and there is an equal period tax module or vestigial record present in the other account.
NOMRG 400 - A complete transcript generated when an account merge fails because one or both accounts contain modules for equal tax periods with an unreversed TC 400 posted.
NOMRG 520 - A complete transcript generated when a merge attempt fails because there is an unreversed TC 520 in each module.
NOMRG 91X - A transcript generated if there is an unreversed TC 914 posted to either account, and if both accounts contain an unreversed TC 910 with significant Agent Identification (ID) and the Agent's ID does not match, or one account contains a 918 freeze, or both accounts contain a 918 freeze but the File Location Code (FLC) of the unreversed TC 918 is different.
NOMRG 930 - A complete transcript generated when both modules contain a posted TC 930.
NOMRG 8752 - A transcript generated when Form 8752 tax module merge failed due to posted return with significant transfer amount or an unreversed TC 766 with "8899" in Blocking Series (BS) of DLN.
(3) No-Merge cases received electronically are controlled on the Correspondence Imaging Inventory (CII) with an IDRS control under Command Code (CC) ENMOD or CC TXMOD.
Cross-reference (X-REF) TINs are listed in a new section of the case page labeled "Associated TINs" beneath the images section.
"No Documents were found for this case" will be displayed in the Document Images section of the page.
The specific type of No Merge transcript (e.g., NOMRG-DUP) can be identified by the case note that is written when the case is created.
Since the transcript control will not request documents from Files, these cases are distributed to Customer Service Representatives (CSR) active inventories.
When a paper transcript generates, a control may show on each tax module affected by the account merger.
If a CII transcript generates, the control often shows on only one module of CC TXMOD.
Note: The Associated TINs section of the page isn't visible while the case is in work distribution (UA). It is visible once the case is assigned to a CSR.
(4) Additional information on the electronic notice process can be found at the Correspondence Imaging Inventory (CII) link on Servicewide Electronic Research Program (SERP).
No-Merge Research
(1) In order to resolve a no-merge case, you must understand the transaction codes. If you are not sure of a transaction code, see IRM 3.13.2.14.1, Consolidating Accounts, or Document 6209 , IRS Processing Codes and Information.
(2) If you identify a no-merge case while staffing an Accounts Management (AM) toll-free phone application, prepare Form 4442, Inquiry Referral, and route it to the AM Paper function within your Directorate, except Puerto Rico who will send the 4442 to the Brookhaven Campus paper function until further notice.
Exception: If there is an open control on the account, refer Form 4442 to the employee who has the open control.
(3) No-merge case controls can be found on CC TXMOD or CC ENMOD of either -Employer Identification Numbers (EIN). The employee with the no-merge open control must be contacted before any adjustment action is taken on the related accounts.
(4) The Form 706, United States Estate (and Generation-Skipping Transfer) Tax Return, and Form 709, United States Gift (and Generation-Skipping Transfer) Tax Return, inventory is centralized at the Estate and Gift Tax Operation (Cincinnati Compliance Campus). Reassign Form 706 (MFT 52) and Form 709 (MFT 51) no-merge transcripts to IDRS number 0283000000.
No-Merge Procedures
(1) This subsection contains the following procedures:
Transaction Code (TC) 011 Merge Accounts Procedures - IRM 21.7.10.4.1
TC Related to Entity Changes - IRM 21.7.10.4.2
Determining if Accounts Can/Should be Merged - IRM 21.7.10.4.3
Successful Merge - IRM 21.7.10.4.4
Failed Merge - IRM 21.7.10.4.5
No-Merge Cases - IRM 21.7.10.4.6
TC 011 Merge Accounts Procedures
(1) Command Code BRCHG is used to input Transaction Code (TC) 011 and TC 05X. This procedure is restricted to the Submission Processing BMF Entity Function. TC 011 will change the Employer Identification Number (EIN) of an account already on Master File (MF), or it will consolidate two EINs. No other entity change can be made with this transaction code. TC 011 always posts last to the entity portion of the MF. It will resequence to the next cycle. TC 05X is used to make changes to the fiscal year month (FYM).
(2) A failed merger (consolidation) attempt creates a no merge case. No-merge cases are time consuming and require extensive research. Before requesting an account merger (consolidation), you must:
Complete thorough research to ensure a merger request is appropriate.
Review IRM 21.7.10.4.3, Determining if Accounts Can/Should Be Merged.
Verify the same taxpayers are involved.
Recognize the account module and the entity conditions that prevented a successful merge.
Transaction Codes Related to Entity Changes
(1) The following transaction codes (TC) are related to entity changes.
TC 011 - Changes the taxpayer identification number (TIN) of an Account on the Master File (MF) or consolidates two TINs. The input is restricted to the Submission Processing BMF Entity function. The incorrect employer identification number (EIN) can be identified by a series of eights (88888) in the Filing Requirement Section of the transcript. The series of eights also signifies that the account is inactive and may prevent the posting of subsequent transactions. The correct EIN can be identified by a series of zeros (00000) in the Filing Requirement Section. IRM 3.13.2.14.1, Consolidating Accounts, provides detailed information on TC 011.
TC 012 - Reopens (Reactivates) an account on MF. The input is restricted to the Submission Processing BMF Entity function. This will reverse a TC 011. IRM 3.13.12.6.2.1, TC 012, provides detailed information regarding TC 012.
TC 013 - Indicates a change to primary name. The authority for making changes to a primary name line is delegated to the Submission Processing BMF Entity function. Accounts Management employees are authorized to make corrections (e.g., misspellings, input errors, missing or incorrect suffixes). See IRM 21.7.13.6.5.6, Authority for Making Primary Name Line Changes, for additional information.
TC 014 - Indicates a change to taxpayer's address
TC 016 - Indicates a change to various entity data (e.g., filing requirements, fiscal year month, employment codes, etc.)
TC 020 - Deletes an account or makes it inactive (changes all filing requirement codes to 8). The input is restricted to the Submission Processing BMF Entity function.
TC 026 - Deletes the Entity data that remained on the MF under the old EIN/Social Security Number (SSN) (Generated transaction).
TC 040 - Changes SSN or name of an account on the valid segment of the Individual Master File (IMF) or the valid portion of the BMF.
TC 041 - Changes SSN or name of an account which is on the invalid segment of the IMF/Individual Retirement Account File (IRAF) or the invalid portion of the Business Master File (BMF).
Note: See Document 6209, IRS Processing Codes and Information, IRM 3.13.2, BMF Account Numbers, and IRM 2.4, IDRS Terminal Input, for additional information and input requirements.
Determining if Accounts Can/Should Be Merged
(1) An account merger (consolidation) request can be received by phone, correspondence, or internal request. Use Integrated Data Retrieval System (IDRS) and Corporate File On Line (CFOL) command codes to research the accounts on master file to determine whether the accounts can or should be merged (consolidated). If the merge cannot be substantiated by master file research, request clarification from the taxpayer.
Note: If contacting the taxpayer by telephone, use proper authentication prior to discussing the tax account information.
(2) Various items should be considered when researching taxpayer records to substantiate a merge of accounts. Consider the differences in the following:
Name lines
Addresses
Filing requirements (ownership or business structure change)
Entity establishment dates
Example: Entities established years apart may indicate different taxpayers. Final returns posted to oldest established taxpayer identification number (TIN) may indicate a change in ownership.
(3) Prior to making a merger (consolidation) request, ensure the filing requirements are compatible. If the filing requirements are not compatible, complete research must be performed to ensure an accurate merger. Taxpayer contact may be necessary. If the taxpayer wants to merge a Form 1120 with a Form 1065, probe the taxpayer for additional information. A consolidation may be inappropriate. For example, the taxpayer may need to finalize one account and establish a new business structure type (corporation verses partnership) and request a new employer identification number (EIN). The following table will assist with comparing filing requirements:
Filing Requirement | Incompatible Filing Requirements |
|---|---|
Form 1120 |
|
Form 1041 |
|
Form 1065 |
|
Form 1066 |
|
Form 8752 |
|
Form 990-T |
|
Form 5227 |
|
Form 990-PF |
|
Form 4720 |
|
Form 990 |
|
Form 706GS(T) |
|
Form 941 |
|
Form 1120-C |
|
Form 1041-A |
|
Example: One account has a Form 1041 filing requirement and the other a Form 1120 filing requirement. Unless the establishment of one of the filing requirements was an IRS error, these accounts should not be merged because the filing requirements are incompatible.
Example: One account was established in 2005 and the other in 2014. Final returns have posted to the account established in 2005. This usually indicates a change in ownership and the accounts should not be merged unless clarification is received from the taxpayer.
(4) Analyze status of specific types of tax and tax periods.
Example: If the returns are posted under the same tax period and Master File Tax (MFT) code with different liabilities, the entities may be for different taxpayers.
(5) When it is determined a merge is necessary, process as follows:
Attach proper documentation for each entity to Form 3465, Adjustment Request, (correspondence request) or Form 4442, Inquiry Referral (phone request). The form must contain the employee number, all research actions, and the reason for the merge. Forward the form to Submission Processing BMF Entity for Transaction Code (TC) 011 action.
Note: Before forwarding the merge request to Entity, the Accounts Management (AM) manager or lead customer service representative will review the case to ensure the accuracy of the merge request.
The Correspondence Imaging Inventory (CII) History Notes should accurately show the research performed to determine a merger is necessary and the lead/manager concurrence.
Follow the procedures in the table below.
If... | Then... |
|---|---|
The merge will resolve the case | 1. Assign the control base to Entity. |
Additional AM actions are necessary to resolve the case after the merge is complete( i.e., any required tax adjustment) | 1. Retain case control. |
Successful Merge
(1) A transaction code (TC) 005 indicates an account is being resequenced for an attempted merge with another account.
(2) A successful merge is indicated by the posting of a TC 005/TC 006 combination on the new "to" account. The transactions will post one cycle apart. The TC 005 shows a TIN cross-reference to the from account.
(3) A TC 026 will post to the "from" account. The account is removed from master file. The taxpayer identification number (TIN) will show as a cross reference TIN on CC INOLES and CC INOLEX.
Failed Merge
(1) A transaction code (TC) 003 posted on the "from" account indicates an unsuccessful merge. In most cases, the TC 003 will post after the TC 011 and the TC 011 will show the cross-reference taxpayer identification number (TIN).
Example: The same tax module under both numbers contains a posted return (TC 150).
(2) A TC 006 without a cross-reference TIN indicates an unsuccessful merge.
(3) The TC 006 may show a no merge reason code (NMRG-RC). The reason codes are found in the Document 6209 under Section 8C - Master File Codes 6 - No Merge Reason Codes.
No-Merge Cases
(1) When a taxpayer is erroneously assigned two Employer Identification Numbers (EIN), a transaction code (TC) 011 is input to consolidate duplicate numbers. The Social Security Administration (SSA) receives notification of the consolidation.
(2) Consolidation will not be successful if any of the following conditions are present:
A return posts (TC 150) in each module - generates NOMRG-DUP transcripts
A return posts (TC 150) in one module and retention record (vestigial record) in the other - generates NOMRG-VEST transcripts
Unreversed TC 400 (if transaction section has exceeded posting size) in either module - generates NOMRG-400 transcripts
Each module contains a combination of a TC 150 and multiple TC 610 (payments post with return) one of which is an RPS - generates NOMRG-RPS transcripts
(3) If an EIN is inactive or deactivated by EIN consolidation and an Integrated Data Retrieval System (IDRS) transaction is required on the deactivated EIN, the account may need to be reopened to avoid certain unpostable conditions. The reactivation will post with a TC 012. The TC 012 reactivates the EIN on IDRS and will not systematically move any tax modules. Since the reopen procedure is restricted to the Submission Processing BMF Entity function, the reopen request must be sent to Entity before any corrective action is taken on the account.
NOMRG-DUP
(1) When an attempt is made to merge a taxpayer’s account with the same Master File Transaction (MFT) and tax period and both modules contain a Transaction Code (TC) 150, a NOMRG-DUP transcript is generated for review.
(2) When a merge is unsuccessful, a Correspondence Imaging Inventory (CII) transcript case will generate with a control on one tax module or ENMOD.
(3) Review the original returns with Corporate File On Line (CFOL) command codes or Employee User Portal (EUP). If necessary, request the original paper tax returns. Check the tax periods, entity data, tax return data, and the signature and titles area for any differences.
(4) Before taking any adjustment action, determine if another taxpayer is involved under either taxpayer identification number.
(5) Tax increases within 90 days of the Assessment Statute Expiration Date (ASED) are statute imminent and must be expedited to the Statute Function. The local Accounts Management Statute Coordinator provides local statute imminent case routing instructions.
One Taxpayer Involved (NOMRG-DUP)
(1) If only one taxpayer is involved:
Input Transaction Code (TC) 291 and any other applicable TCs to reduce the tax and related penalties and interest to zero for duplicate modules on the incorrect taxpayer identification number (TIN).
Use the appropriate blocking series (BS) for the type of tax being adjusted.
Enter Hold Code 4 to prevent generating the adjustment notice and hold the credit. If there is credit in the module, transfer the credit to the correct TIN.
Reminder: Enter TC 570 (additional liability and or credit pending, hold) when necessary, and monitor. Reverse with TC 571.
Do not delete the filing requirements for an incorrect TIN. It is not necessary, because the filing requirements are deleted when a merge occurs (from EIN filing requirements are changed to 8s).
Input TC 290 and any other applicable transaction code necessary to increase the tax to the correct amount on the correct TIN. Use the appropriate BS for the type of tax being adjusted.
Note: If there is no change in the tax liability, do not adjust the tax.
Enter HC 3 to prevent generating an adjustment notice if no additional tax or refund is due.
Note: This will not prevent any other notice.
Use a no source document (NSD) indicator on the TC 29X and reference the Correspondence Imaging Inventory (CII) case number. If a source document (SD) is necessary, attach supporting documentation to justify the adjustment action.
(2) If the account to be merged contains transactions which cannot be transferred with the above documents (e.g., TC 300, TC 301, TC 400, etc.), prepare the appropriate request for the Accounting function (i.e., Form 3465, Adjustment Request, or Form 12810, Account Transfer Request Checklist).
(3) If the merge activity was generated by taxpayer correspondence or phone contact, the taxpayer must be notified of the corrective action.
More Than One Taxpayer Involved, Merged in Error (NOMRG-DUP)
(1) Follow the procedures below when a merge is in error and more than one taxpayer is involved.
Determine the correct taxpayer identification numbers (TIN).
Input or request the appropriate entity transaction for each affected TIN. Accounts Management is not authorized to input all Entity transaction codes (TC) (e.g., TC 011, Change EIN, TC 012, Reopen Entity Account, and TC 013, Name Change).
Transfer credits, as appropriate.
Determine whether other modules were moved to an incorrect TIN during the merge. A TC 446 indicates merged transactions.
Move modules back to the correct TIN, if moved to an incorrect TIN during the merge. If necessary, reopen the TIN via TC 012.
Refile any returns, as appropriate.
More Than One Taxpayer Involved, Merged Correctly
(1) Follow the procedures below when the merge was correct and more than one taxpayer is involved (this may occur when a successor company files using a different EIN).
Use the available Correspondence Imaging Inventory (CII) images, Integrated Data Retrieval System (IDRS), and Corporate File On Line (CFOL) Command Codes to review the accounts and verify whether the tax returns posted to the correct taxpayer identification number (TIN).
Verify the assessment (TC 150) is correct as filed. If correct, do not adjust the account. Refile the returns.
If the final returns have not posted, reopen the TIN, with a Transaction Code (TC) 012. Since Accounts Management is not authorized to reopen the TIN, send a request to the Submission Processing BMF Entity function.
Move the credits to the correct module(s) and allow the final returns to post.
NOMRG–RPS
(1) NOMRG–RPS transcripts generate when two accounts attempt to merge as a result of an entity transaction and both contain a module for the same tax period with a combination of:
A posted return (TC 150)
Multiple payments (TC 610), one of which is a Remittance Processing System (RPS)
(2) If there is only one taxpayer involved, follow the procedures below:
If... | Then... |
|---|---|
Only one taxpayer | Input transaction code (TC) 291 in BS 15/05 and any other necessary TC to reduce the tax, related penalties, and the interest to zero on the incorrect TIN. |
Credit should be held | Use HC 1. |
Credit and notice should be held | Use HC 4. |
TC 610 payment is on the account | Transfer to the valid account. |
Credit should be prevented from offsetting or refunding | Input TC 570. |
Returns are secured | Analyze the accounts and returns. |
Adjustment actions are necessary | Adjust the accounts. |
No adjustment is necessary | Input TC 290 .00 using the appropriate BS. |
Both accounts are valid | Do not request a TC 020. Combine all the returns belonging to one taxpayer under the correct TIN (TC 290) and back out the data pertaining to the other account (TC 291). |
(3) If there are two taxpayers involved, follow the procedures below:
If... | Then... |
|---|---|
A taxpayer files a return using an incorrect TIN | Research for the correct TIN for the taxpayer that is posted to the invalid segment. |
Taxpayer's return post to incorrect TIN | Take the appropriate action to post the data to the correct TIN. |
A TIN needs to be reopened | Request a TC 012. |
A valid TIN cannot be determined | Contact both taxpayers. (If contacting by telephone, you must authenticate who you are speaking to prior to discussing tax account information.) |
Both taxpayers claim the same TIN or one does not respond | Route the case to the Submission Processing BMF Entity function with all pertinent information. |
NOMRG-400
(1) A NOMRG-400 transcript generates when a merge attempt fails because one or both accounts contain a tax module with a transaction code (TC) 400. (When an account returns to a different file validity than the account's correct Social Security Number (SSN) validity, REVAL-400 transcripts generate.)
(2) To resolve the NOMRG-400 transcripts, examine the transcripts and returns (if secured) to determine if the account consolidation is necessary.
(3) If the account consolidation is NOT necessary, or impossible, destroy the transcripts.
(4) If the account consolidation is necessary (the "from" account has a return or payment data necessary to update the "to" account), follow procedures below:
Prepare a Form 12810, Account Transfer Request Checklist, for Accounting to reverse the TC 400.
Attach transcripts to the form.
Maintain a suspense file until Accounting verifies the TC 400 is reversed.
Receive verification, input entity transaction to consolidate the accounts. (Input TC 040 or TC 041, as appropriate.)
Close the case file and destroy the transcripts.
NOMRG-VEST and REVAL-VEST
(1) A NOMRG-VEST transcript is generated when two accounts attempt to merge and one or both accounts contain a vestigial (retention) record for the same tax period. A REVAL-VEST transcript is generated when the file validity account is returned to the account's correct Taxpayer Identification Number (TIN) validity.
(2) A vestigial record is an account that has been transferred out of Master File (MF) and moved to the Retention Register. The Retention Register is the microfilm storage of older, inactive accounts when they are removed from MF. The basic tax module removal criteria include:
The assessed module balance is zero and the last transaction has been posted 51 or more months.
The assessed module balance is credit and the last transaction has been posted 60 or more months.
Credit modules are not subject to specific retention holds.
Debit modules past the collection statute expiration date are not subject to specific module retention holds.
Note: Items c and d will generate a TC 388 or TC 608, respectively, to reduce the module balance to zero before removing the module.
(3) Examine the transcripts and returns (if secured) to determine if the account consolidation is necessary. Take the following action:
Request the transcripts for those tax modules on the retention register.
If consolidation is unnecessary or impossible, destroy the transcripts.
If consolidation is necessary, move all available tax modules. The related modules must be available on MF. A tax module that is on the Retention Register cannot be adjusted until it has been restored to MF. In order to restore an account to the master file (MF) you must obtain a transcript of the account. IRM 21.7.10.4.6.4.1, Retention Register Module Research and Reinstatement, provides request guidance.
(4) If moving posted tax information is an issue, the tax module must be moved when any of the following conditions are met:
The Assessment Statute Expiration Date (ASED) is open.
There is a balance owed on the tax module.
The tax module has an overpayment that must be refunded.
(5) All available tax modules must be moved to the correct Employer Identification Number (EIN). If a tax module cannot be restored to master file due to retention period or microfilm destruction, do not move the tax module. The research response may indicate the requested tax module is not available (retained) or destroyed. No action is required on these tax modules; however, the Correspondence Imaging Inventory (CII) History Notes must be update with an explanation why the specific tax module was not moved to the correct EIN.
Retention Register Module Research and Reinstatement
(1) There are two types of retention register: microfilm and on-line. IRM 21.2.2.5, Retention Register Research, provides instructions for all research command codes utilized through IDRS.
(2) Before requesting retention modules on microfilm, use Command Code (CC) BMFOL to check the on-line retention registers to ensure the account module is not available on-line. CC BMFOL definer code B is used to restore recoverable retention register tax modules back to active BMF master file. A confirmation screen will show a TAX MODULE REQUESTED TO BE REESTABLISHED message. The weekly cut-off time for BMFOLB requests is 5:00 p.m. Wednesday ET. Request input after 5:00 p.m. are processed the following cycle. IRM 21.2.2.5.9, On-Line Retention Register, provides additional detail.
(3) If you determine that microfilm research is necessary, make a request using the following methods:
Microfilm research can be requested with CC ESTAB definer M. IRM 21.2.2.5.8.3, Researching Microfilm Retention Record, provides additional detail.
A transcript can be obtained by sending a Form 3774, Request for Research, to the Research Branch. The Research Branch will check the microfilm records and return a microfilm transcript of the account.
CC MFTRA with request type Z is used to request a tax module hard copy transcript. The message "A MICROFILM REQUEST HAS BEEN GENERATED" will be displayed to show the operator that there is no need to input an ESTAB "M" request. Ensure the account information is not available on the on-line retention register before using CC MFTRA.
Note: CC BMFOR can be used to review recently removed tax modules from master file. The input format for CC BMFOR is the same as for CC BMFOL. These tax modules cannot be re-established to MF through CC BMFOL definer code B. Only BMF modules dropped to retention in 2009 and later are available. See IRM 2.3.59.4, Command Code BMFOR Basics, for additional detail.
(4) If a tax module cannot be restored with an IDRS command code and a transcript was secured during research, prepare Form 5248, Transfer Request, to reactivate the tax module. The transcript is attached to Form 5248 and forwarded to the Accounting Function. Establish an IDRS dummy tax module for the module being restored by Accounting. The account should be restored within 4 to 6 weeks.
One Taxpayer Involved
(1) If one taxpayer filed two tax returns using different taxpayer identification numbers (TIN), data on both of the returns can result in a tax assessment.
(2) Request and review tax returns, if needed. Do the following:
Transfer the account involved from the retention register to the Master File. IRM 21.7.10.4.6.4, NOMRG-VEST and REVAL-VEST, and IRM 21.7.10.4.6.4.1, Retention Register Module Research and Reinstatement, provide retention register information, research, and module reinstatement.
.
Note: Modules brought back from retention on a NMRG-VEST case can merge systemically.
If... | Then... |
|---|---|
There is one TC 150 and account can be merged |
|
There are two TC 150 |
|
Note: Review IRM 21.7.10.4.3, Determining if Accounts Can/Should be Merged, before submitting a consolidation (merger) request and IRM 21.7.10.4.6.4, NOMRG-VEST and REVAL-VEST, to determine whether a consolidation is necessary or possible.
Two Taxpayers Involved
(1) Determine if returns are for separate entities.
If... | Then... |
|---|---|
Entities are separate | Close the control base as "NO CHANGE". |
Entities are not separate | 1. Follow procedures in IRM 21.7.10.4.6.1.2, More Than One Taxpayer Involved, Merged in Error (NOMRG-DUP), and IRM 21.7.10.4.6.1.3, More Than One Taxpayer Involved, Merged Correctly, as appropriate. |
