3.13.122.1
(01-01-2014)General Information and Introduction

3.13.122.1.1
(01-01-2015)Purpose and Scope

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

The mission of the Entity Control Function and the Unpostable 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.

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.

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, FINDS, FINDE and TPIIP, and ENMOD are used to make this determination.

Completely review to resolve all unpostable conditions which could result in a REPEAT entity unpostable condition.

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

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

The Internal Revenue Code (IRC) states that the 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.

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.

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

Example of statute expiration date for a timely filed return:

Form

Tax Period

IRS Received Date

Return Due Date

ASEDStatute Date

1040, U.S. Individual Income Tax Return

201014

03-15-2015

04-15-2015

04-15-2018

Example of statute expiration date for a late filed return:

Form

Tax Period

IRS Received Date

Return Due Date

ASEDStatute Date

1040, U.S. Individual Income Tax Return

201014

05-15-2015

04-15-2015

05-15-2018

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

See IRM 25.6.1, Statute of Limitations Processes and Procedures.

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

Whenever the Social Security Number (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.

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

This section 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.

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.

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

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:

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

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.

The Integrated Data Retrieval System (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.

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

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

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.

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.

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

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.

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-2014)Taxpayer Advocate Service (TAS)

This subsection contains information on referring cases to TAS.

3.13.122.4.1
(01-01-2014)TAS Background Information

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.

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.

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.

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.

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, Taxpayer Advocate Service (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 Accounts Management System (AMS), if applicable.

Note:

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

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

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.

The following types of cases should NOT be referred to TAS:

Cases where the taxpayer’s complaint or inquiry only questions the constitutionality of the tax system; or

Cases where the focus of the taxpayer's inquiry is solely to employ frivolous tax strategies to avoid or delay filing or paying
federal taxes

TAS Case Criteria - Any taxpayer contact that meets any of the criteria listed below should be forwarded to the local Taxpayer
Advocate for special handling using a Form 911, Request for Taxpayer Advocate Service Assistance (And Application for Taxpayer
Assistance Order). The following is a list of situations to be referred if any of the criteria apply:

The taxpayer is experiencing economic harm or is about to suffer economic harm.

The taxpayer is facing an immediate threat of adverse action.

The taxpayer will incur significant costs if relief is not granted (including fees for professional representation).

The taxpayer will suffer irreparable injury or long-term adverse impact if relief is not granted.

The taxpayer has experienced a delay of more than 30 days to resolve a tax account problem.

The taxpayer has not received a response or resolution to their problem or inquiry by the date promised.

A system or procedure has either failed to operate as intended, or failed to resolve the taxpayer’s problem or dispute within
the IRS.

The manner in which the tax laws are being administered raises considerations of equity, or has impaired or will impair the
taxpayer’s rights.

The NTA determines compelling public policy warrants assistance to an individual or group of taxpayers. The NTA has the sole
authority for determining which issues are included in this criterion and will so designate by memo.

Note:

Case criteria are not meant to be all-inclusive. Evaluate each taxpayer situation based on the unique facts and circumstances
of each case.

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

This section contains posting and cycling information.

3.13.122.5.1
(01-01-2014)General Information

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 Document Code 47 (Exam) and most Document Code 54 (Data Processing) 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, Taxpayer Delinquent Accounts (TDAs)
and refunds etc. are issued. The length of time needed to post a transaction varies.

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

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

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.

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

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

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

3.13.122.5.2
(01-01-2014)CADE 2 Impact on Unpostables

In January 2012 with CADE 2 implementation, the following cycles were accelerated and will impact the processing of unpostables:

Campus Cycle: Thursday - Wednesday

Master File Processing: Friday - Thursday

GUF Processing: New available Tuesday; Closing Tuesday

All new unpostables will be available to work on Tuesday morning. The GUF closing runs will occur on Tuesday evenings.

Note:

This applies to both IMF and BMF sites.

For example – Unpostable conditions identified on transactions input in the campus in any given cycle (with new cycle close
of Wednesday), will be processed by Master File on Thursday and will be available in Unpostables to work as new inventory
the immediately following Tuesday.

IMF Master File will begin processing and posting specific transactions daily. IMF will also identify unpostables transactions
each day of the cycle. However, GUF will continue to run weekly. Unpostables for all 5 days of the IMF cycle will be marked
for GUF to locate for opening runs to begin on Monday.

IMF will not re-analyze the account at the end of the cycle to determine whether the unpostable condition has been resolved.
There is a potential that the transaction needed to resolve the unpostable condition may post on a subsequent day in the same
cycle. In this situation, the unpostable can be closed with Unpostable Resolution Code (URC) 0.

GUF 07 reports should contain multiple IMF data rows for each day of the production cycle (data for Day 1 of the cycle, data
for Day 2 of the cycle, etc.)

Note:

BMF will continue to process weekly and will create one unpostable file for GUF to locate for the opening run on Monday.

Not all transactions or accounts will post in IMF daily. Transactions or accounts marked as weekly will result in the transactions
resequencing until Master File processes the end of the cycle on Thursday.

Note:

BMF will continue to process weekly.

Corporate Files On Line (CFOL) Command Codes (CCs) will contain an indicator on the screen to identify whether the IMF account
is a daily account or a weekly account.

3.13.122.5.3
(01-01-2014)Master File Resequencing

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

Resequencing can be identified on Integrated Data Retrieval System (IDRS) by the presence of "RS"
transactions (if account is on IDRS).

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.

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

Form 706, United States Estate (and Generation-Skipping Transfer) Tax Return, documents with a valid Social Security Number
(SSN) will resequence for 3 cycles.

Early filed returns with remittances will resequence until the RDD.

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

3.13.122.5.4
(01-01-2014)Transaction Posting Time

Transaction posting time depends on the input method as follows—

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

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

Transactions input through Integrated Submission and Remittance Processing (ISRP) are on a regular or expedite cycle.

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.

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.5
(01-01-2014)CADE 2 Daily Transaction Posting

Daily transactions directed to a daily account are expected to post daily with daily processing. Transactions will be viewable
using CFOL CC's the second day after campus input. Transactions will be viewable on IDRS CC's the third day after campus input.

Weekly transactions directed to a daily account are expected to post with the weekly processing run on Thursday and may result
in the account type changing to weekly.

Daily and weekly transactions directed to a weekly account are expected to post with the weekly processing on Thursday.

Note:

For items 2 and 3, transactions will be viewable using CFOL CC's on the Saturday following the Thursday processing run. Transactions
will be viewable on IDRS CC's Monday following the Thursday processing run.

Use of the Posting Delay Code on transactions will result in the transaction being held until the weekly processing on Thursday.
When the transaction is processed on Thursday and the Posting Delay Code contains a value other than zero, the transaction
will continue to resequence for the number of cycles equal to the value. For example: A transaction input with a Posting Delay
Code of 1 will be processed on Thursday, and will resequence until the following weekly processing day (the following Thursday).

Note:

Use of the Posting Delay Code on a daily account with daily transactions may result in delaying the posting of the transactions
that would resolve the account.

IMF transaction posting dates will reflect a format of YYYYCCDD. YYYY will indicate the year. CC will indicate the posting
cycle. For IMF transactions, the following values for DD are defined:

01 = Friday

02 = Monday

03 = Tuesday

04 = Wednesday

05 = Thursday

Note:

BMF transaction posting dates will continue to reflect YYYYCCDD. YYYY will indicate the year. CC will indicate the posting
cycle. For BMF transactions the DD value will be 08.

3.13.122.5.6
(01-01-2014)Rules for Cycling

Cycle transaction if—

The prerequisite transaction has a higher transaction code.

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.

Do not cycle-in transactions if—

Posting sequence is not necessary.

Prerequisite transaction will post first anyway.

Cycling should be calculated by using the current Martinsburg Computing Center (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/Tennessee Computing Center (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.

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

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

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

The following IDRS transaction programs have the posting delay capability:

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

A TDI satisfying transaction attempted to post to the wrong module (Master File Tax) MFT and/or tax period incorrect) or to
the wrong account (Taxpayer Identification Number (TIN) is incorrect).

When nullifying (URC 1 or 8) a Transaction Code (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.

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 TDIs, input a TC 599 with the appropriate closing code if the TC 150 cannot be posted timely to stop
the TDI.

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

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

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

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.

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

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 as follows:70 through 88 (9nn-(70-88)-nnnn)90 through 92 (9nn-(90-92)-nnnn)94 through 99 (9nn-(94-99)-nnnn)

ATIN -- can be identified with a 9 in the first position and 93 in the fourth and fifth positions (9nn-93-nnnn).

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. See
IRM 3.13.122.8.2 for more information on IRSNs.

Taxpayers with an IRSN or ITIN are ineligible to receive the Earned Income Tax Credit (EITC). However, taxpayers are entitled
to claim a personal exemption when they use an ITIN, but not an IRSN. URC 8 to Rejects to remove the EITC and/or exemptions
if an IRSN or ITIN is present on the return.

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

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

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

Update Master File via CC INCHG.

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

If research DOES NOT provide sufficient information to correct the Unpostable Code (UPC), contact the taxpayer.

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

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

Exception:

TINs beginning with a 9 and the 4th and 5th position numbers are 70-88, 90-92, 94-99 or 93 are not an IRSN.

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

The DM–1 file is a database of name controls and associated TINs received from these four sources:

Social Security Administration (SSA)

IRS processing

IRS Individual Taxpayer Identification Number (ITIN) File

ATIN (Adoptive Taxpayer Identification Number) File

Note:

The ITIN and ATIN processing is completed at Austin Submission Processing Campus (AUSPC). The ATIN and ITIN taxpayer information is sent forward DAILY. However, these taxpayer accounts will initially reside on the
invalid segment.The new ATINs, ITINs, IRS Valid and the new SSA Accounts will be directed to the invalid side of IMF. These new accounts WILL NOT validate or attempt to post to the valid side of IMF until after completion of the next quarterly
merge.

Reminder:

The DM-1 quarterly updates are done in January, April, July, and November of each year.The quarterly merges are scheduled in cycles 05, 15, 31, and 44.

The DM–1 also receives weekly updates from the SSA and the IRS processing.

Programming determines the validity of the data on the DM–1. It "directs"
transactions to either the valid or the invalid segment of the IMF.

Transactions that match the TIN/Name Control on the DM–1 File are directed to the valid segment of the IMF for posting.

Note:

IMF Valid TINs display without an asterisk.

Transactions that successfully obtain a proximal match on the IRS valid name control file are directed to the valid segment of the IMF for posting.

If the TIN and Name Control were added this quarter, the transaction is considered valid. However, these transactions are
directed to the invalid segment of the IMF for posting until the quarterly merge is completed.

Reminder:

It is important to note that IMF does move VALID IMF accounts to the INVALID side of IMF due to the quarterly merges.

The DM–1 file may display/record more than one name control for a TIN.

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

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

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.

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

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.

The same taxpayer can be on the valid and invalid segments of the Master File.

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

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

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.

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

If the unpostable is a TC 150 and the return includes amounts for a personal exemption and/or Earned Income Tax Credit (EITC),
edit the IRSN on the return. URC 8 to Rejects requesting the personal exemptions and EITC be removed.

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

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.,CC's INOLE, ENMOD, TXMOD, etc.) do not all merge at the same time.

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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 IRM 3.13.122.8.5.2.

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

Although the Form 1040, U.S. Individual Income Tax Return, consist of two lines for entering joint names, Master File is limited
to ONLY one line for the "Primary Name Line"
.

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. The second name line on CC INCHG is used to enter taxpayer
information and titles such as 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.

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

Tax Return

Input format for Joint Filers

John DoeMary Doe

John & Mary]Doe

John DoeMary Smith

John] Doe]& Mary Smith

John DoeMary Smith-Doe

John] Doe]& Mary Smith-Doe

John D DoeMary Ann Smith-Doe

John D] Doe]& Mary Ann Smith-Doe

John D Doe IIIMaryAnn L Smith

John D]Doe]III & MaryAnn L Smith

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

John & Mary Doe (John Doe and Mary Doe)

John Doe and Mary Smith

John Doe and Mary Smith-Doe

John D. Doe and Mary Ann Smith-Doe

John D. Doe III and 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.

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.

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

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

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.

Before entering a TC 040 or TC 041, thoroughly research the taxpayer's account using CC INOLES. NUMIDENT transcripts are ordered
through IDRS using CC MFTRA with Request Type "U"
However, it takes approximately three days to generate and receive the transcripts from the campus print room. If employees
have access to CONTROL D WebAccess (CTDWA), the NUMIDENT transcripts are available in approximately one day. Requests printed
using CONTROL D can also be converted to a PDF file and may be forwarded to any employee working the case. See IRM 1.4.16,
Accounts Management Guide for Managers, for additional information. IRM 1.4.16 contains information on viewing and/or printing
reports. See IRM 2.3.32 CC MFTRA for additional information.

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 Social Security Number (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.

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

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.

3.13.122.9
(01-01-2014)Accounting Period Change

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

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-2014)Payment Information

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

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.

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.

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-2014)Remittance Transaction Research (RTR) System

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.

RTR provides three years of images online for immediate retrieval. Images more than three 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.

Associate both cases and research for a different entity if necessary.

If the TIN listed on the return and payment are correct and research indicates the TP is not deceased or died after the year
listed on the document, refer to IRM instructions for the specific UPC.

If the correct entity is found and established, URC 6 TC 150 and TC 610 to the correct SSN.

If the correct entity is found but not established, and the Entity Code (EC) on the return is not 1, take the necessary action
to establish or update the entity.

If the correct entity cannot be found, correspond with the taxpayer. If a complete reply is received, URC 6 both cases to
correct the SSN. If no reply or incomplete, assign an IRSN and send 685C letter. Edit the return with the IRSN. URC 6B the
TC 610 to change TIN and cycle delay 3 weeks. Close TC 150 via URC 8 to Rejects to request they process to IRSN and remove
EITC (if claimed) and personal exemption.

If TC 610 is posted to the correct entity, URC 6 TC 150 to correct the SSN.

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

Establish the entity.

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

URC 6 to correct the SSN and release the TC 150 to post after the TC 610, cycle if necessary.

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

Transfer the TC 610 to the correct entity.

URC 6 to correct the SSN and release the TC 150 to post after the TC 610, cycle as necessary.

3.13.122.10.4
(01-01-2015)If Transaction Code (TC) 610 is Unpostable

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

If found, post the TC 610 to the correct account with the matching TC 150.

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

3.13.122.11
(01-01-2014)Decedent Returns

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

Decedent returns must have a Date Of Death (DOD). If Form 1310, Statement of Person Claiming Refund Due a Deceased Taxpayer,
or a court certificate is not attached to a return (TC 150) claiming a refund, correspond with Letter 12C,Individual Return
Incomplete for Processing: Form 1040, U.S. Individual Income Tax Return Form 1040A, U.S. Individual Income Tax Return and
Form 1040EZ, Income Tax Return for Single and Joint Filers With No Dependents, and suspend the case using CC UPCAS SC.

Note:

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

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 Letter 12C to the return.

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 Letter 12C, Individual Return Incomplete for Processing: Form 1040, U.S. Individual Income Tax Return,
Form 1040A, U.S. Individual Income Tax Return and Form 1040EZ; Income Tax Return for Single and Joint Filers With No Dependents;
to the return.

Joint returns:

If...

And DOD is...

Then...

A. Return has Filing Status 2 with two names on Name Line and claimed dependent children

C. Return has Filing Status 5 and there are no dependent children claimed

more than 2 years

URC 8 and request Rejects change the Filing Status to 1.

D. Return has Filing Status OTHER than 2 with two names on Name Line

within tax period

URC 8 and request Rejects change the Filing Status to 2.

E. Return has Filing Status 5 with only ONE name on the Name Line

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.

Other than JOINT return:

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

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 … "
.

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

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

For additional information on entering information for deceased taxpayers, refer to IRM 3.13.5.118.9.

3.13.122.11.1
(01-01-2015)Locking Decedent Accounts - TC 971 AC 524

1. The TC 971 AC 524 is an identity theft indicator used to lock the account of deceased taxpayers. It prevents a deceased
taxpayer's TIN (SSN or ITIN) from being used as the primary or secondary TIN on a current or subsequent year federal income
tax return. Account locks can be applied both manually and systemically using internal or external information. However, input
of the TC 971 AC 524 is limited and reserved for use by Privacy, Governmental Liaison and Disclosure (PGLD) Identity Protection
Program (IP) and RICS Taxpayer Protection Program (RICS TPP). Refer to IRM 10.5.3.2, IMF Identity Theft for more information.

2. TC 971 AC 524 can be viewed on the taxpayer’s entity using CC's ENMOD or IMFOLE.

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 Servicewide Electronic Research Program (SERP).

3.13.122.12.1
(01-01-2014)Command Code (CC) ENMOD

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

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

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

3.13.122.12.2
(01-01-2014)Command Code (CC) ENREQ/INCHG/IRCHG

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.

CCs NAMES, NAMEE, NAMEI, NAMEB, FINDS, FINDE, and TPIIP 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.

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

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.

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.