Part 3. Submission Processing

Chapter 12. Error Resolution

Section 179. Individual Master File (IMF) Unpostable Resolution (Cont. 1)

3.12.179  Individual Master File (IMF) Unpostable Resolution (Cont. 1)

3.12.179.9 
Correspondence Guidelines and Unprocessable Information and Procedures

3.12.179.9.7  (01-01-2012)
Campus Addresses

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

    ADDRESS CITY/STATE ZIP CODE
    IRS AUSTIN, TX 73301
    IRS CINCINNATI, OH 45999
    IRS FRESNO, CA 93888
    IRS KANSAS CITY, MO 64999
    IRS OGDEN, UT 84201

3.12.179.10  (01-01-2012)
Credit Transfers, Offsets and Refunds (Erroneous, Canceled or Undeliverable)

  1. This subsection contains information for Credit Transfers, Offsets and Refunds.

3.12.179.10.1  (01-01-2012)
Offsets and Transfers

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

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

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

    1. Determine if the unposted payment was the missing payment which caused TC 760 to be input. If it was, post the payment and input TC 570 to hold the money. Notify Accounts Management for a possible TC 760 reversal.

    2. Computer offsets cannot be made to or from tax modules which contain TC 760, but refunds and balance due notices can be generated. Both the payment and TC 762 must be posted in the same cycle if the tax module is not frozen.

    3. CC STAUP should be input to a module if it is in a balance due condition.

3.12.179.10.2  (01-01-2012)
Credit Transfers and Transfer Vouchers—Doc Codes 24, 34, 48 and 58

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

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

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

    1. Doc Code 24—Use Doc Code 24 to transfer credits between Master Files when a secondary TC (other than 570) is needed, or when changing the TC or date on a posted transaction. The debit and credit portions post separately. These TC's are compatible: 170, 180, 200, 270, 280, 360, 472, 570, 610, 620, 640, 650, 660, 670, 680, 690, 700, 730, 790, 820, 824, 850, 890, and their respective reversal codes. Do Not Use a Doc 24 for transfers which can be input with Doc 34. Doc Code 24 may be input via IDRS (CC ADC 24, CC ADD 24 and CC DRT 24) or Form 2424, Account Adjustment Voucher via ISRP. See Figure 3.12.179-3 for an example of Form 2424.

    2. Doc Code 34 may be input only via IDRS (CC ADC 34 or CC ADD 34 to generate FRM 34). Doc Code 34 transfers credits between modules within a Master File, when no secondary TC is required other than TX 570. See Figure 3.12.179-4 for an example of FRM34.

      Note:

      Do not use a Doc Code 34 when transferring user fee payments.

    3. Doc Code 48—Doc Code 48 transfers an overpayment credit elect, a refund repayment, a substantiated credit allowance or withholding credit. A secondary TC may also be used. The compatible TCs are 270, 360, 410, 472, 510, 710, 720, 742, 760, 770, 800, 830, 841, and their respective reversal codes. Doc Code 48 may be input via IDRS or on paper via ISRP. See Figure 3.12.179-5 for an example of DRT48.

    4. Doc Code 58—Doc Code 58 transfers special accounts. The compatible TCs are 280, 360, 570, 660, 681, 690, 694, 700, 710, 730, 820, 824, 850, and their respective reversal codes. Doc Code 58 may be input via IDRS or paper via ISRP. See Figure 3.12.179-6 for an example of Form 3809.

    Figure 3.12.179-3
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 3.12.179-4
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 3.12.179-5
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 3.12.179-6
    This image is too large to be displayed in the current screen. Please click the link to view the image.

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

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

  6. See IRM 3.17.220, Excess Collections File, for additional information on the preparation and use of these forms.

3.12.179.10.3  (01-01-2013)
Erroneous Refunds

  1. During their normal work, Unpostable examiners may detect erroneous refunds. Erroneous refunds are most likely to occur with the following IMF UPC's:

    • UPC 168

    • UPC 175

    • UPC 189

    • UPC 194

    • UPC 196

  2. Most of these unpostable documents will be the debit side of the doc codes 24, 48, or 58 that did not post because the credit refunded or offset to another module.

  3. With accelerated refund processing for IMF, under certain conditions, accounts will not reflect the refund transaction (TC 846) upon settlement of the account. IMF will systemically apply a refund hold for a specified period before systemically generating the refund transaction (TC 846).

    1. A refund hold will be applied when the account meets Priority Refund Transcript criteria (Refund, Refund-E, Refund-S, $1M, and $10M). The accounts will reflect a TC 971 AC 805 and a TC 570 with blocking series “55555” indicating the refund hold has been applied. The hold will systemically expire 4 business days after the TC 971 AC 805 date.

    2. A refund hold will be applied when the account meets criteria to issue CP 12, 16, 21, or 24. These accounts will be processed during the weekly processing on Thursday. The accounts will reflect a TC 971 AC 804 and a C- freeze. The hold will systemically expire 7 calendar days after the TC 971 AC 804 date.

  4. If the credit side of the transfer has posted, and an erroneous refund is in the process of being issued, but a TC 846 is not posted:

    If... And... Then
    1. The account has a TC 570 with blocking series “55555”, A TC 971 AC 805 is also posted on the module indicating a refund transcript has generated,

    1. Input another TC 570 up to 3 business days after the systemically generated TC 570 transaction date (up to 6pm local time) to prevent the refund transaction from generating. OR

    2. Input NOREFP put on the third business day after 6pm or the fourth business day before 6pm local from the systemically generated TC 570 transaction date to request IMF reverse the refund and stop the refund information from going to FMS.

    2. The account has a C-freeze A TC 971 AC 804 is also posted on the module indicating a CP 12, 16, 21, or 24 has been issued,

    1. Input TC 570 input up through 6 pm the following Wednesday (6 calendar days after the systemically generated TC 570 transaction date to prevent the refund transaction from generating. OR

    2. Input NOREFP on the Wednesday after 6 pm or Thursday before 6 pm local to request IMF reverse the refund and stop the refund information from going to FMS.

    1. Correct the unpostable to debit the module where the credit posted.

    2. Advise the originator that the transfer was reversed and explain why.

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

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

    1. If the transaction should have posted to a different Master File, release using URC 8 attach all research and route to Rejects.

    2. If unable to determine where the original 840/846 posted, follow procedures in 3.12.179.10.4(2).

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

    1. Reverse the credit using URC 6 or 8.

    2. Notify the originator noting "Erroneous Refund."

3.12.179.10.4  (01-01-2013)
Canceled or Undeliverable Refund (TC 841/740)

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

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

    1. Forward a print of CC UPRES to Refund Inquiry.

    2. Place the case in "suspense" status and enter remarks explaining why the case is in suspense.

    3. Add "History" item on IDRS.

    4. If the Refund Inquiry function is unable identify where the refund should be posted, the credit should be transferred to Account 4970, Unapplied Refund Reversal, using Form 3809.

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

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

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

    1. Forward a print of UPRES and a transcript of the module to the Accounting function.

    2. If Doc Code 45, close with URC 1. If Doc Code 48, close with URC 8.

    3. Add a "History" item to IDRS.

3.12.179.10.5  (01-01-2012)
Excess Collections, Dishonored Checks and Unidentified Remittances

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

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

  3. Complete all research on the case.

    1. If you can determine the corrective action (i.e., correct transaction code, correct date, etc.), correct the item(s) and close with an URC 6. Transfer the completed information onto the Form 11358 and forward to Accounting for corrective action to the XSF, DCF, or URF. The Form 11358 should be forwarded on a weekly basis.

    2. If the credit amount is INCORRECT or UNAVAILABLE for transfer, URC 8 to Rejects as usual.

3.12.179.11  (01-01-2013)
Category Code L-7 (Credit Transfers and Bad Checks)

  1. Unpostables receives unposted credit transfers as workable inventory and must input credit transfers to correct an unpostable transaction.

  2. Taxpayer credits (transactions) can post:

    1. To the wrong tax period.

    2. As the wrong transaction code.

    3. To the wrong Master File.

    4. To the wrong taxpayer.

  3. Credit transfers are input to move transactions to the correct tax account module. When they are incorrectly transferred they will unpost in Category Code L-7.

  4. Unpostables in the L-7 category are considered high priority work because they can cause erroneous credits and refunds.

  5. Whether correcting an unpostable credit transfer (Category L-7) or inputting a transfer in the course of correcting an unpostable transaction, follow the accounting equation (debits must equal credits).

  6. Erroneous credits, which sometimes result in erroneous refunds, occur when the debit side of a transfer is unpostable and the credit side posts.

  7. If the debit cannot post to the module it is addressing, the credit side cannot remain posted. To avoid this situation, the unpostable debit is posted to the same module that the credit posted to. This action reverses the credit transfer. One transaction (the debit) is cancelling out or reversing the other (the credit).

  8. When reversing a credit transfer, the transaction code and date of the unpostable transaction must match the posted side or additional unpostables will be created.

  9. Document Codes 24, 34, 45, 48, 58, and 87 unpost in the GUF L-7 category.

  10. The debit and credit sides of Doc Codes 24, 48, and 58 carry a separate Document Locator Number (DLN) and a document is generated for both. In addition, the debit and the credit post separately.

  11. It is possible for the debit to unpost and the credit to post creating an erroneous credit and possible erroneous refund.

  12. The debit and credit are separate transactions. Always check both sides to ensure:

    1. If both the debit and the credit are unpostable, determine if both sides can be corrected. If both sides can be corrected, release using the appropriate URCs. If both sides cannot be corrected, release both sides using URC 8 to wash the debit and credit and notify the originator.

    2. The credit will not release an erroneous refund.

  13. Document Code 24 - When a secondary transaction code (other than 570) is needed or when transferring credits between Master Files, use Doc Code 24.

    Note:

    Do not use a Doc Code 24 for transfers that can be input with Doc Code 34.

  14. Document Code 34 - Transfers credits between modules within a Master File.

    1. The Doc Code 34 input format allows Tax Examiners to move up to four credits having no secondary TC other than TC 570.

    2. Any TC compatible with Doc Code 24 can be transferred with Doc Code 34.

    3. Input Doc Code 34 via IDRS using CC ADD34/ADC34/FRM34.

    4. Both the debit and the credit side of the transfer carry the same DLN and only one document generates.

    5. The debit must post in order for the credit to post.

  15. Advantages to using the Doc Code 34 format include the following:

    1. It enables Tax Examiners to input up to four transaction codes.

    2. An Electronic Deposit Indicator (EDI) will generate when needed.

    3. Erroneous refunds are seldom associated with Doc Code 34 since the credit does not post until one week after the debit has posted.

    4. If the debit unposted because the transaction date or tax period is incorrect, the unpostable can be resolved using URC 6.

    5. If the unpostable debit cannot post, or is a duplicate of a prior transfer, the unpostable can be resolved using URC 2 to originator.

  16. Document Code 48 - transfers the following actions:

    1. an overpayment credit elect,

    2. a refund repayment,

    3. a substantiated credit allowance, or

    4. withholding credit

    A secondary TC may be used. Doc Code 48 may be input via IDRS using CC ADD48/ADC48/FRM48 or on paper using Form 3809, Miscellaneous Adjustment Voucher, via ISRP. The Doc Code 48 format is similar to the Doc Code 24 format.

  17. Document Code 58 - Transfers special accounts. The compatible transaction codes are listed in the following chart:

    Compatible TCs
    280 360 570 660 700 820
          681 710 824
          690 730 850

    Note:

    The respective reversal codes are included.

  18. Document Code 87 - Reverses a payment submitted by check that the bank did not honor.

    Example:

    A posted credit TC 660 is reversed by a TC 661 indicating a dishonored check.

3.12.179.11.1  (01-09-2012)
Installment Agreement (IA) User Fees

  1. IA User Fees are systemically transferred from the tax module (MFT 30) to the User Fee Module (MFT 55/13). The transfer consists of a debit TC 672 and a credit TC 694 with secondary TC 360.

    DPC User Fee Type Amount
    47 Reduced origination fee $43.00
    48 Reduced DDIA origination fee $43.00
    49 New DDIA origination fee $52.00
    50 New agreement origination fee $105.00
    51 Reinstated agreement fee $45.00

  2. If the user fee unposts on the MFT 55 account, correct as follows:

    If... Then...
    TC 694 on MFT 55 URC 6, and change to TC 670, MFT 30, oldest balance due, DPC 99
    TC 360 on MFT 55 Delete with URC D

    Note:

    TC 694 may unpost alone or with a matching TC 360.

  3. User Fee reversals - TC 672 may be unposting because of a dishonored check (TC 671) or an automated attempt to transfer a duplicate user fee.

    1. If TC 672 is unposting on MFT 30 and there is no unreversed TC 670 with matching date, then check XREF MFT 55 for TC 694 with matching date and amount.

    2. If match found, then URC 8 to Rejects to change the TC 672 to TC 695, MFT 55, appropriate tax period (20XX01) and add the designated payment code (DPC).

    3. Any matching TC 360 on MFT 55 must also be reversed. Request Rejects enter TC 361 to post in same cycle as the TC 695.

  4. If TC 695 is unposting and no matching TC 361, URC 8 to Rejects. Request Rejects enter the TC 695 and TC 361 to both post in the same cycle.

    Note:

    TC 361 may be entered by Unpostables as long as it is coordinated to post with the TC 695.

3.12.179.12  (01-01-2012)
Category Codes Y–1 and Y–2 (ISRP and Payments other than Doc Codes 24, 34, 45, 48, 58, and 87)

  1. This subsection contains information for Category Y–1 and Y–2.

    Note:

    The TC 150 must post in the same cycle or subsequent cycle of the TC 610 to prevent erroneous notices.

3.12.179.12.1  (01-01-2012)
Category Y–1 Criteria

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

    1. Payments processed via ISRP or Lockbox banks will contain a Doc Code 70 or 76.

    2. "Input System Source Code" of "R" (ISRP Input Record). This code is contained in the block header data for With-remittance (ISRP) records.

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

3.12.179.12.1.1  (01-01-2012)
If TC 150 and TC 610 are Unpostable

  1. Associate both cases and research for different entity.

    1. If entity is established, post the transaction.

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

3.12.179.12.1.2  (01-01-2012)
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 not posted to the correct entity and the 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.12.179.12.1.3  (01-01-2012)
If TC 610 is Neither Posted nor Unpostable

  1. Refer to IRM 3.12.179.37 to find missing TC 610 payments (UPC 140 research chart).

    Note:

    Thoroughly research to locate and post the associated TC 610, prior to posting the TC 150.

3.12.179.12.1.4  (01-01-2012)
If TC 610 is Unpostable

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

    1. If found, use appropriate instructions to 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.12.179.12.2  (01-01-2012)
Unpostable Category Code Y–2

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

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

3.12.179.12.2.1  (01-01-2012)
"Looping" Conditions

  1. If the Unpostable is UPC 140, establish or update the account prior to closing the unpostable.

3.12.179.13  (01-01-2012)
Taxpayer Delinquent Investigation (TDI) and Notice Delay Information

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

3.12.179.13.1  (01-01-2013)
Erroneous TDI's—IMF and IRAF (TC 599s)

  1. Erroneous TDI's (Form TDI–14) 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 transition 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 reinput to the same tax module within six weeks after the Return Due Date (RDD). Input a TC 599 with closing code 17 or 18 unless otherwise directed.

  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 TDI's, 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), approximately mid-May of the current processing year.

    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.

    1. Use CC FRM49

    2. Use CC TDINQ to research any unpostable TC 59X.

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

3.12.179.13.2  (01-01-2012)
CC-STAUP and TC 470—Notice Delay

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

    1. Notice issuance does not start until the return (TC 150) posts; therefore it is not necessary to input STAUP or TC 470; and

    2. All IDRS notice issuance is automatically suspended when an unpostable record (other than TC 150) is shown on IDRS for the same module.

      Note:

      This unpostable notice freeze is released when the unpostable condition is corrected. The type of notice issued is determined by the status of the module when the unpostable is corrected.

3.12.179.13.2.1  (01-01-2012)
Delay IDRS Notice Output

  1. If it is necessary to input CC STAUP or TC 470 to delay IDRS notice output, complete the following:

    1. Input STAUP (not to exceed 8 cycles) the same cycle the unpostable record is corrected, if the unpostable record was input to the wrong Master File (except for status 60) and TC 470 or STAUP is not already on the correct module. Notify Notice/Output Review to pull first notice after inputting "STAUP" For other than first notice, notify SCCB.

    2. Input STAUP (not to exceed 3 cycles) the same cycle the unpostable record is corrected. If the unpostable was input to the wrong TIN name control and/or tax period and TC 470 or STAUP is not already on the correct module, or a STAUP notice freeze is about to expire.

3.12.179.13.2.1.1  (01-01-2012)
Payments Only

  1. Payments Only—Review TXMOD, check for a prior CC STAUP or TC 470, a posted TC 150 and a balance due.

    1. If a TC 150 is posted and is in balance due status but no STAUP or TC 470 is present, input STAUP (not to exceed 8 cycles) to delay notice issuance until the unpostable payment can be corrected and posted.

    2. If unpostable module is not on IDRS ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ or in TDA status (22, 53, 60, or 72), STAUP cannot be input. Instead input TC 470 to delay notice issuance; or use CC ACTON to establish the module on IDRS and then input STAUP (not to exceed 8 cycles). Notify Notice/Output Review to pull first notice after the input of "STAUP" or TC 470. For other than first notice, notify SCCB.

3.12.179.13.2.2  (01-01-2012)
Inputting CC STAUP or TC 470

  1. When inputting CC STAUP or TC 470, the number of cycles the IDRS notices is delayed should be kept at the minimum necessary. Excessive cycle delays can result in unnecessary penalty and interest accruals when the unpostable credit does not reduce the balance to zero.

    1. CC STAUP generates suspense status 48 and freezes notice activity for up to 15 cycles and specifies the next notice to be issued. Status 48 will be released at the end of this specified suspense period. STAUP cannot be used to delay Master File first notices.

    2. TC 470 with no closing code suspends IDRS notices and/or TDA's on a module for up to 15 cycles. TC 470 may be input to tax modules in IDRS status 19 (if RDD is reached), 20, 21, 56, and 58.

    3. See the TC 470 Analysis Chart in Document 6209, to determine the IDRS status after input of the TC 470. The next notice will be issued after the TC 470 is either released or the number of cycles have expired. TC 470 should not be used to delay Master File first notices because when the return posts this notice is issued.

3.12.179.13.2.3  (01-01-2012)
Transferring Out Cases

  1. Cases being transferred out of Unpostable's inventory must have at least four weeks remaining on the notice delay transaction. If not, input a new STAUP or TC 470. Indicate on routing slip a new STAUP or TC 470 was input and the number of cycles the notice was delayed.

3.12.179.13.2.4  (01-01-2012)
TC 470 or CC STAUP Already on Module

  1. If a TC 470 or CC STAUP is already on the module and will not expire before completion of the unpostable action, DO NOT re-input or update STAUP or TC 470.

3.12.179.14  (01-01-2012)
Posting Transactions—Input Timing

  1. This subsection contains information for Posting, Resequencing and Cycling—In Transactions.

3.12.179.14.1  (01-01-2012)
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 improper cycling. All Doc Code 47 (Exam) and most Doc Code 54 (DP) Adjustment transactions require a return be posted. Reversal transactions require the related original transaction to be present. After all transactions have posted, analyses are made, new status and freeze conditions are set, (released or changed) and notices, TDA's and refunds etc. are issued. The length of time needed to post a transaction varies.

3.12.179.14.1.1  (01-01-2012)
Background

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

  2. Computer analysis of the transaction (to change Master File status, module balance, filing requirement, to freeze or release a freeze, or to set, release or change an indicator) is made after all transactions are posted.

  3. Computer analysis for the issuance of notices, Taxpayer Delinquent Accounts (TDA's) is made after all transactions are posted.

  4. Computer analysis for the posting of a transaction based on the presence of prerequisite transactions, status codes, condition codes, FR and module balance, is made when the transaction attempts to post.

3.12.179.14.1.1.1  (01-01-2012)
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 the payment posts, whichever is earlier.

3.12.179.14.1.2  (01-01-2012)
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) Accounts Management held up for review, will be transmitted to its Master File on the same schedule (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 not appear on the Reject Register until after the next GUF weekly update.

3.12.179.14.1.3  (01-01-2012)
CADE2 Daily Transaction Posting

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

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

  3. 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 command codes on the Saturday following the Thursday processing run. Transactions will be viewable on IDRS command codes Monday following the Thursday processing run.

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

  5. 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:

    1. 01 = Friday

    2. 02 = Monday

    3. 03 = Tuesday

    4. 04 = Wednesday

    5. 05 = Thursday

    Note:

    BMF transaction posting dates will continue to reflect YYYYCC. YYYY will indicate the year. CC will indicate the posting cycle

3.12.179.14.1.4  (01-01-2013)
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.

    3. Cycling should be calculated by using the current ECC-MTB 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 Service Center updates to ECC-MTB/ECC-MEM. 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.

  2. Do not cycle-in transactions if—

    1. Posting sequence isn't necessary.

    2. Prerequisite transaction will post first anyway.

3.12.179.14.2  (01-01-2012)
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. 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.12.179.14.2.1  (01-01-2012)
Pre-journalized Credit Transfers

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

    1. The posting delay code 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.

3.12.179.14.2.2  (01-01-2012)
Dual Debit/Credit Transfers

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

    1. The posting delay code is entered only for the debit transaction.

    2. The credit transaction is not created until the debit posts to the Master File; hence, a posting delay code is not necessary.

3.12.179.14.2.3  (01-01-2012)
General Instructions

  1. Tax examiners may have to input a posting delay code 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 the Master File will be deferred until the indicated number of posting cycles has passed.

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

  3. The posting delay code will not post with the transaction or be shown with the IDRS pending transaction. The projected ECC-MTB posting cycle on the IDRS 'PN' (status pending) transaction will be extended to account for any PDC impact on the transaction.

3.12.179.14.3  (01-01-2012)
Trace ID Number

  1. All payment deposits are assigned a 20 digit Trace ID number. When tax examiners process unpostable payment transactions, the Trace ID number may not be already transcribed on the payment document.

  2. Unpostables will be required to ensure that the Trace ID number is on all payments that are nullified using URC 1 or sent to Rejects using URC 8. This includes any payments that have to be renumbered or reprocessed. The Tax Examiners (TEs) will have to identify the Trace ID number and notate it on the document, even if a dummy document is created. The Trace ID will not be viewable or correctable in GUF.

  3. The Trace ID number for a payment can be identified on IDRS using TXMOD. If the payment is from ISRP, RPS or Lockbox, use Remittance Transaction Resource System (RTR) to find the Trace ID. Once the Trace ID is identified, it must be transcribed onto the payment document.

3.12.179.15  (01-01-2012)
Scheme Development

  1. Effective October 1, 2010, the Accounts Management Taxpayer Assurance Program (AM-TAP) will have responsibility for working cases that previously fell under Fraud Detection criteria. The Fraud Detection Centers have been renamed Scheme Development Centers (SDCs).

3.12.179.15.1  (01-01-2012)
Scheme Development, Statute, and Bankruptcy Issues

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

    1. Scheme Development—A1 or A2.

    2. Statute—C1, C2, or C3.

    3. Bankruptcy—Z1.

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

3.12.179.16  (01-01-2012)
Instructions for Creating Name lines and Assessing Non-Return Civil Penalties

  1. The term Non-Return Related Civil Penalties refers to civil penalties not assessed in a return tax module using the tax return MFT Codes. The Non-Return Related Civil Penalties are assessed on the IMF Master File in the regular taxpayer account using a unique Civil Penalty MFT Code (MFT 55 for IMF). The Civil Penalty tax modules are additional tax modules in an account sharing the same taxpayers' entity information with the tax return modules in the account.

  2. All penalties assessed Non-Return Related Civil Penalties on IMF should be assessed against the individual responsible. MFT 55 does not accept joint assessments. The penalty for filing a frivolous return may be assessed on MFT 55 if the frivolous return was filed by a single person. If the frivolous return was filed jointly, the penalty must be assessed jointly using Non-Master File procedures.

  3. To establish a separate penalty name line, use an IMF entity change (CC INCHG to generate a TC 013) with the special civil penalty name line input procedures. When using this special procedure, only the civil penalty name line change may be input. No other entity change information is permitted. Information to otherwise update the entity, such as an address change, should be input before establishing the civil penalty name line. When using this procedure, the Civil Penalty Name line and Master File Name line must be an exact match including first, middle (if applicable), and last name. This means that if the name does not show on IDRS, thorough research will be necessary.

3.12.179.17  (01-01-2012)
IMF—Data Master One (DM–1) Valid/Invalid Segments

  1. This subsection contains information for DM–1, Valid/Invalid Segments.

3.12.179.17.1  (01-01-2012)
DM–1 Validation Processing

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

    • Social Security Administration (SSA)

    • IRS valid processing

    • Individual Taxpayer Identification Number (ITIN) File

    Note:

    ITIN applications may be viewed on the ITIN RTS.

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

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

    1. Transactions that obtain a proximal match on the IRS valid name control are given a validity digit of "0" (IMF). These transactions are directed to the valid segment of Master File for posting.

    2. If the TIN and name control that was added this quarter match, the transaction will be given a validity digit of "1" (IMF) which is directed to the invalid segment of the Master File.

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

    1. The account will be considered valid for processing purposes.

    2. The account will display the literal NEW SSA NC under CC INOLE.

    3. This literal prevents entity notices from generating.

    4. This literal allows refunds to generate to the taxpayers.

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

3.12.179.17.1.1  (01-01-2012)
Match on Accretion File

  1. If a match is found on the Accretion file, it is given an Accretion File Indicator that will:

    1. Prevent Entity notices from generating

    2. Allow refunds to generate to taxpayer

    Note:

    An account with an accretion file indicator is a valid account although it is directed to the Invalid Segment.

3.12.179.17.1.2  (01-01-2012)
No Match on Accretion File

  1. If no match is obtained, the transaction is directed to the invalid segment of the Master File.

    1. If an account is already on the invalid segment with identical information, the transaction will post.

    2. If an account is already on the invalid segment with a different name control, the transaction will unpost for name control mismatch.

    3. If there is no account present on the invalid segment, it will unpost if it is not an account-establishing transaction.

3.12.179.17.1.3  (01-01-2013)
ECC-MTB—Quarterly Merge

  1. ECC-MTB performs a quarterly merge of all accretion tapes into the DM–1. The following dates are approximations:

    1. January 15

    2. April 15

    3. July 15

    4. October 15

  2. The account will reside on the invalid side of Master File until the quarterly DM-1 merge is accomplished.

  3. The accounts with an accretion file indicator are then merged to the valid segment of the Master File.

  4. All transactions remaining on the invalid segment are compared to the new DM-1 tape.

    1. If a match is obtained, the account is resequenced to the valid segment.

    2. If no match is obtained, the account is returned to its original slot on the invalid segment. See Figures 3.12.179-7, Long Entity, and 3.12.179-8, Chart of Validity Segments.

      Note:

      The DM-1 can carry more than one name control for an SSN. Example: One year the taxpayer's name is Susan Birch (000–00–0123). Susan Birch changes her name to Susan Redwood. She updates her name with SSA to reflect her new last name. The DM-1 will carry both names for the SSN.

    Figure 3.12.179-7
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 3.12.179-8
    This image is too large to be displayed in the current screen. Please click the link to view the image.

3.12.179.17.2  (01-01-2012)
Valid and Invalid Segment of the IMF for SSNs

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

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

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

  4. The most common reasons for an invalid account number are:

    1. The taxpayer did not properly update their name with SSA.

    2. Transcription errors made by IRS.

  5. Master File is segmented according to SSN validity.

    1. Valid numbers will be in SSN sequence followed by invalid numbers in SSN sequence.

    2. Two taxpayers can be on the Master File under the same SSN. One taxpayer appears on valid side of number. One taxpayer appears on invalid side of number.

    3. The same taxpayer can be both the valid and invalid segment of Master File. This occurs when the taxpayer has different name controls for different tax periods and has not notified SSA of the name change.

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

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

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

    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 used, prioritized in that order

    6. Any additional Names Used

    7. Citizenship

    8. Sex

    9. Date of Birth

    10. Place of Birth

    11. Mother's Maiden Name

    12. Father's Name

3.12.179.17.3  (01-01-2013)
Social Security Numbers (SSNs) Out of Valid Range

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

    Exception:

    A secondary SSN can be 000–00–0001 and greater.

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

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

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

  5. Under no circumstances should a taxpayer ASSIGNED an IRSN receive a personal exemption and/or EIC.. Send a 685C letter informing the taxpayer of the assignment of the IRSN and URC 8 to Rejects. Request Rejects to remove the taxpayer's personal exemption and/or EIC claimed.

3.12.179.17.3.1  (01-01-2013)
Secondary SSN's

  1. When a Secondary SSN (S-SSN) is out of the valid range, perform all in-house research. If a valid SSN, invalid SSN, or IRSN is found, correct the secondary SSN using URC 6. If no other number is found, reassign the case to Entity Control for assignment of a temporary number.

  2. Entity Control will send the secondary taxpayer a letter (1825C, 257C, 2615C or 685C) notifying him/her of the assignment of a temporary IRSN. They will explain to the taxpayer that the number shown on their return is out of the range numbers assigned by SSA. Include instructions to the taxpayer to go to SSA to obtain verification of the number they used on their return.

3.12.179.17.3.2  (01-01-2013)
Form W-7 Attached, ITIN Procedures (AUSPC Only)

  1. Tax returns received with a Form W-7 attached require special handling regardless of the Unpostable condition.

  2. URC 8 the return to Rejects, with instructions to forward to the ITIN office when a Form W-7 is attached for the Primary, Secondary, and/or Dependent(s) and:

    1. The Primary, Secondary, and/or Dependent(s) TIN is blank.

    2. The Primary, Secondary, and/or Dependent (s) TIN edited in red ink is invalid.

    3. There is no indication that the return was worked by the ITIN unit (red ITIN number, ITIN rejected stamp, or no W-7 notated).

  3. If the document has the Primary TIN area edited (illegible or not) with a red ITIN that does not match the name on IDRS or does not show on the valid or invalid side of INOLE:

    1. Correct any coding or transcription errors pertaining to the name control or TIN.

    2. Research the ITIN RTS and NAMEI for the correct ITIN.

    3. If valid TIN is not found, suspend the document and forward the return to Entity for a temporary SSN.

  4. If the document does not have an indication of a W-7 for the Primary taxpayer, suspend the document and forward the return to Entity for a temporary number.

  5. If the document has a "Rejected" stamp from ITIN for the Primary taxpayer, check NAMEI and ITN RTS for a valid TIN. If a valid TIN is not found, suspend the document and forward the return to Entity for a temporary number.

  6. If the Primary, Secondary, or Dependent(s) TIN is blank and research using ITIN RTS shows the W-7 is in status S or U, assign a IRSN and resolve the unpostable condition,..

    Note:

    Attach the ITIN RTS screen print showing the status.

  7. If the Primary TIN is blank and research using ITIN RTS shows the W-7 in status R2 (rejected; taxpayer has previously assigned ITIN), continue ITIN RTS research for the correct previously assigned ITIN.

  8. If the Primary TIN is altered (whited out) by ITIN or written illegibly, research using ITIN RTS and NAMEI for a valid number. If a valid number is not found, suspend the document and forward the return to Entity for a temporary number.

3.12.179.17.4  (01-01-2013)
Entity Changes (Name and Address)

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

    Note:

    Do not change any entity or an address from telephone inquiries. Request Form 8822, Change of Address, or a letter from the taxpayer.

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

3.12.179.17.5  (01-01-2012)
Entity Codes (ECs) and Filing Status Codes

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

    UPC 148 UPC 156 UPC 176
    UPC 151 UPC 163 TC 140
    UPC 152 UPC 166 TC 150
    UPC 153 UPC 171 TC 430

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

    Entity Code Values Meanings
    EC 1 = LONG ENTITY Complete name(s) and address changes entered on a preprinted label or handwritten name and address information.
    EC 2 = SHORT ENTITY Check Digits or Name Control entered.
    EC 3 = INTERMEDIATE ENTITY Street address, City, State and ZIP entered.
    EC 4 = REPEAT UP Results from adding a name line to a prior EC 2 unpostable case.
    EC 5 = PARTIAL ENTITY Complete name(s) entered. May also include a second name line.
    BLANK Entity code not significant.

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

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

    FSC Description
    FSC 0 Single, Filing Declaration of Estimated Income Tax
    FSC 1 Single Taxpayer
    FSC 2 Married Taxpayer filing Joint Return
    FSC 3 Married Taxpayer filing a Separate Return (Spouse exemption is NOT claimed)
    FSC 4 Head of Household (Claiming Dependent)
    FSC 5 Widow(er) with a Dependent Child
    FSC 6 Married Taxpayer filing a Separate Return (Spouse exemption IS claimed)
    FSC 7 Head of Household (Dependent is NOT Claimed)

3.12.179.17.6  (01-01-2012)
IMF Entity Resolution Procedures

  1. Establishing an account

    1. EC 1—Release case after correcting any other unpostable conditions. Long entity entered at ISRP, establishes an account.

    2. EC 2, 4 or 5—Input TC 000 to establish account and release in same cycle TC 000 is input.

    3. EC 3—If TC 150 or 430, add the name line with URC 6. If other than TC 150 or 430, input TC 000 and release case in the same cycle.

  2. Correcting name on Unpostable record

    1. EC 1, 4, or 5 (TC 140, 150, or 430 only), correct the name line and name control using URC 6.

    2. EC 2 or 3—If name control caused the unpostable, correct the name control using URC 6. If Check Digit caused unpostable to go against valid segment of IMF erroneously, correct document by circling out the Check Digit; enter appropriate Name Control. Release the case using URC 6.

  3. Correcting name on IMF residing on VALID segment:

    1. If both IMF and unpostable name line are incorrect, input TC 013 to correct IMF. Follow previous correction procedures.

    2. If TC 150 or 430, add name line (if EC 2 or 3) release using URC 5.

    3. If other than TC 150 or 430, input TC 013 and release unpostable case with URC 0 cycling as appropriate.

  4. Correcting the SSN on Unpostable record.

    1. Before changing the taxpayer's SSN research to verify the "new" number.

    2. If only the primary SSN is incorrect, correct SSN using URC 6 unlessIf Schedule SE is present for the primary taxpayer, then correct with URC 8.

    3. If primary SSN and secondary SSN are reversed or both are incorrect, check for any SE Schedule(s). If you determine the secondary SSN is in error, ensure all necessary corrections are made to the account.

3.12.179.17.6.1  (01-01-2013)
SE Schedule(s) are present.

  1. If any SE Schedule(s) are present (may be dummied in by ERS, check TRDBV),

    1. perfect the document,

    2. release using URC 8 and input TC 599 cc 17/18 (See IRM 3.12.179.13.1(14).

    3. request Rejects correct the SSN's on the record and correct the SE Schedule(s).

3.12.179.17.6.2  (01-01-2012)
SE Schedule(s) are not present.

  1. If no SE Schedule(s) are present,

    1. perfect the document,

    2. correct both SSN's and input name line using URC 6.

3.12.179.17.6.3  (01-01-2013)
First Name Lines

  1. First Name Lines (NLs):

    1. First Name Lines may be changed using URC 6 if the unpostable record contains EC 1, 4 or 5, or the FSC change is NOT from single to joint or vice versa.

    2. If the IMF Name Line (variable data) is correct, enter this name line data for the unpostable record.

    3. If the IMF Name Line is not the correct name line for the transaction, enter the correct name line for the unpostable record. See IRM 3.13.5, Individual Master File (IMF) Account Numbers, for Name Line validity criteria.

    4. NC Change—When one or more of the first four characters of the last name are changed, a corresponding change must be made to the NC.

    5. FSC match—If the name on the return indicates a single taxpayer, do not change the name line to a joint name line. Do not change a joint return name line to a single NL, correct the unpostable and reject the return with the correct name line and FSC. For example: a return name line PHILLIP WILLOW must NOT be changed to PHILLIP & SHARON WILLOW except for UPC 166.

    6. Maximum length of NL is 35 characters. When a name change is necessary and space allows, all available information, including middle initial(s), should be entered.

    7. A NL can be added to IMF if the unpostable transaction is a TC 150 or 430 with EC 2 or 3 and the UPC is 151, 157, 166 or 188. Enter the Name Line with URC 6.

    8. IMF Account incorrect—If it is determined the name on the IMF account is incorrect and is UPC 152, 153, 156 or 157 use URC 5. For EC or 2 or 3, enter the correct NL from the unpostable record.

    9. For others, input TC 013 for correction if on same segment of IMF.

    10. If on the opposite segment of the IMF, transfer an account from the valid segment of the IMF with TC 011.

    Note:

    Before inputting TC040/041 verify that all modules have same name and check UPTIN for related cases.

3.12.179.17.6.4  (01-01-2012)
Editing IMF Name Lines

  1. If the primary and/or secondary name(s) exceed the 35 character/space limit, use the information following as a guideline to reduce the taxpayer(s) name to fit the allowable 35-character length:

    1. Use initials only for middle or second name(s).

    2. Delete middle initial of secondary taxpayer.

    3. Delete middle initial of primary taxpayer.

    4. Use initials only for secondary taxpayer’s first name.

    5. Use initials only for primary taxpayer’s first name. .

    6. Use initials only for primary and secondary taxpayers first name(s) If their last name(s), total characters exceed the 35 characters/spaces limit.

    7. Abbreviate the secondary taxpayer surname. Abbreviate the surname by removing the vowels (begin with the vowels at the end of the secondary taxpayer’s surname first).
      Example: O'Sullivan becomes OSullivn or OSullvn (if necessary).

      Note:

      Do not remove any of the first four characters of the secondary taxpayer’s surname.

    8. If further reduction of the name line is needed, abbreviate the primary taxpayer surname.

    9. Abbreviate the primary taxpayer’s surname as the last step. Abbreviate the surname by removing the vowels (begin with the vowels in the end of the primary taxpayer’s surname).
      Example: Sorrentino becomes Sorrentino or Sorrntn (if necessary)

      Note:

      Do not remove any of the first four characters of the primary taxpayer’s surname.

      Note:

      Do not intentionally shorten taxpayer’s names if their name(s) fit within the 35 character/space constraints.

  2. If it is necessary to further reduce the number of characters to fit the name line than shown in paren 2 above, improvise with the name line abbreviations.

  3. See IRM 3.13.5, Individual Master File (IMF) Account Numbers, for additional instructions to correctly "shorten" the taxpayer’s name(s).

3.12.179.17.7  (01-01-2012)
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.12.179.17.8.

  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's Name Line field must never exceed 35 characters/spaces . It is imperative the name line information is contained in the FIRST NAME LINE ONLY. When space allows, all available information, including middle initial(s), should be entered.

    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

    The ampersand (&) indicates to Master File that the information following is the Secondary taxpayer's name.
    The brackets ([ ]) indicate to Master File that the information contained within is the Primary taxpayer's surname on 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, Individual Master File (IMF) Account Numbers, or the Name Control Job Aid, Document 7071, for additional information.

3.12.179.17.8  (01-01-2013)
IMF Name Changes TC 040 and TC 041

  1. Generally TC 040 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. Often used to move new ITINs to the valid segment before the DM-1 quarterly merge.

  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 MFTRA U 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. Spouse's SSN if present

    7. Description of change in the REMARKS field.

    Refer to 3.12.179.17.7 for additional information on Name Changes.


Prev Next

More Internal Revenue Manual