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.6  (01-01-2014)
Processable/Unprocessable Returns

  1. For purposes of computing interest on overpayments on returns and the 45 day interest-free period, a return is not treated as filed until it is filed in processable form. A return is in processable form for purposes of the rules for interest on overpayments if:

    1. the return is filed on a permitted form;

    2. the return contains the taxpayer's name, address, identification number, required signature; and

    3. sufficient information (whether on the return itself or on required attachments) to permit mathematical verification of the tax liability shown on the return.

  2. The test for whether a return is "processable" is set forth in the IRC itself (at § 6611(g)). An unprocessable return may start the period of limitations on assessment; however, that period will not start if the return is "invalid" (the test for invalidity has been developed through case law).

    Note:

    The test for processibility is stricter than that for validity. Generally, the former test requires information allowing verification, a factor that takes into account the Service's processing tasks; i.e., a return that is missing Schedules A, B, C, D, or E will not be processable, but it will be valid.

  3. A Received Date is required on returns that are:

    1. Amended

    2. Delinquent

    3. Prior Year

    4. Early Filed Decedent

    5. Short Year Tax Returns

    6. Fiscal Year Returns (IMF only)

    Note:

    Caution should be taken to determine when a return was filed or became processable since interest will be allowed only from one of the dates.

  4. Thoroughly research the available documentation and IDRS because a change to the received date may generate a notice to the taxpayer.

  5. Determine the received date in the following priority:

    1. IRS received date stamp
    2. U.S. Postal Service, Army Post Office (APO), U.S. Embassy or Consulate postmark date, or official postmark of a foreign country.
    3. Private Meter postmark
    4. Service Center Automated Mail Processing System (SCAMPS) digital date
    5. Revenue officer signature date
    6. Signature Date (Current Year Returns)
    7. Julian Date minus 10 days in the DLN

    Caution:

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

  6. For further information, refer to IRM 3.10.72, Receiving, Extracting, and Sorting, IRM 3.30.123; Processing Timeliness: Cycles, Criteria, and Critical Dates; and/or Document 6209.

    Note:

    Late replies initiated by another area (i.e., Entity, Accounts Management, Exam) should be routed to the appropriate area to correct the Return's processing date. Do not forward to Files.

  7. Master File has the capability to maintain and display two dates. The first date will be the "Return Received Date" and the second the "Return Processable Date(RPD)" . The "Return received date" will be used to determine the statute dates while Return "Processable-Received Date" will be used to compute interest on overpayments.

3.12.179.9.6.1  (01-01-2014)
Unpostable Correspondence Returns Requirements

  1. If a timely filed return is being processed, and the Julian Date is 155 or later, enter the return due date as the return received date.

  2. If a late reply (correspondence was received after return due date) is received:

    1. Edit the Return Processable Date (RPD), also known as the Correspondence Received Date (CRD), in the lower left hand corner of the return or edit sheet. Determine the RPD in the following priority order:

        1. IRS Date Stamp (date the reply was received)
        2. Postmark on reply envelope
        3. Current Date

    2. URC 8 to request Rejects enter the CRD.

  3. If a reply is not received, ensure that Computer Condition Code (CCC) 3 is entered into the record. The CCC 3 suppresses credit interest from generating at Master File.

3.12.179.9.7  (01-01-2014)
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-2014)
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-2014)
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-2014)
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 TC 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-28-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 6 pm local time) to prevent the refund transaction from generating.

    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.

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

  6. 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-2014)
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 to 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-2014)
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 correct form and forward to Accounting for corrective action to the XSF, DCF, or URF. Use Form 8758 for payments with transaction dates over a year old going to Excess Collections (XSF). Use Form 2424 for payments under 1 year old to be transferred to Unidentified (URF). These forms 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-2014)
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 SSN.

    2. To the wrong MFT.

    3. To the wrong tax period.

    4. With the wrong transaction date.

    5. To the wrong name control.

    6. To the wrong transaction code.

    7. With the wrong money amount.

      Note:

      Form 4251 can be used as a closing tool. Check off all seven factors above before closing L7 cases.

  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 6XX (TC 610, 640,670, 660) compatible with Doc Code 24 should be transferred with Doc Code 34 when possible.

    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 Direct Debit Installment Agreement (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-2014)
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-2014)
Category Y–1 Criteria: Category Y–1 consists of the following unpostable transactions

  1. IMF TC 150 transactions with an RPS indicator of "S" (i.e. IMF returns with an RPS remittance). The most common Unpostable Code is 140, but Category Y-1 includes other codes when the unpostable condition is unrelated to the remittance.

    1. When working these cases, research thoroughly to locate the TC 610 payment..

    2. If the TC 610 is found, ensure that it posts correctly with the return.

  2. IMF TC 150 transactions without an RPS indicator of "S" , where the module contains an unreversed RPS TC 610 with DOC Code 19, 70, or 76. Unpostable Code is 140, Reason Code 2.

  3. IMF current-year TC 610 transactions (payment with return) that are not Doc Codes 24, 34, 45, 48, 58, or 87. Unpostable Code is 151.

3.12.179.12.1.1  (01-01-2014)
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-2014)
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 correct 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 correct entity is established,

    1. Transfer the TC 610 to the correct entity.

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

3.12.179.12.1.3  (01-01-2014)
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-2014)
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-2014)
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-2014)
"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-2014)
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-2014)
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 "017" if the return is being processed BEFORE the Program Completion Date (PCD), approximately mid-May of the current processing year.

    2. Use Closing Code "018" 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-2014)
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-2014)
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-2014)
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-2014)
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 Return Due Date (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-2014)
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-2014)
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-2014)
Posting Transactions—Input Timing

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

3.12.179.14.1  (01-01-2014)
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-2014)
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-2014)
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). See Document 6209 Section 8B for explanation of Resequence Codes.

    2. The following account resequence transactions (TC 011, TC013, TC040, TC041) 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, and credit offsets 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-2014)
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-2014)
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-2014)
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. Always cycle when a transaction you input (for example, name change, TC 013) will change the account from valid to invalid, or vice versa. Cycle so that the name change will go into effect and the account will have changed validity before the return or other unpostable posts.

    4. 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-2014)
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-2014)
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-2014)
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-2014)
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-2014)
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-2014)
Scheme Development

  1. Effective October 1, 2010, the Integrity & Verification Operation (IVO) 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-2014)
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-2014)
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-2014)
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-2014)
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 Request Tracking System (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 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.

  4. If an exact match cannot be found, IMF completes a proximal match on the taxpayer's Name Control (N/C) and TIN.

    1. In order for IMF to obtain a "proximal match" on the taxpayers IMF N/C and TIN, the following conditions must be met:

      IF And Then
      First letter of the IMF N/C matches the first letter of name control(s) found on DM-1 associated with this TIN. Any two of the remaining three letters are equal to the same two relative positions of the NC(s) found on DM-1. OR Any two adjacent positions when interchanged, are equal to the same two relative positions of the NC(s) found on DM-1 and the remaining position of IMF NC is equal to the same relative position found on the DM-1. Proximal match occurs.

      Example:

      If DM-1 N/C is VASQ, a proximal match will occur for VAZQ

    2. If a proximal match is obtained, the transaction is given a validity digit of "0" , and it is directed to the valid segment of Master File for posting. This proximal match process corrects many typographical errors.

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

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

    ..

3.12.179.17.1.1  (01-01-2014)
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-2014)
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-2014)
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-2014)
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 his/her 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 on 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. If an exact match is not found in the TIN validation process, IMF attempts to find a proximal match on the DM-1 or accretion files. The proximal match process corrects typographical errors. A transaction that obtains a proximal match with the DM-1 will be directed to the valid segment of IMF.

  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. 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-2014)
Social Security Numbers (SSNs) Out of Valid Range

  1. GUF has implemented validity checks to prevent tax 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 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-2014)
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.

3.12.179.17.3.2  (01-01-2014)
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 an IRSN.

  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 an IRSN

  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 an IRSN.

  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 an 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 an IRSN.

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

  1. Any errors observed in the taxpayer's entity indicated from a return (TC 150) or taxpayer correspondence should be corrected.

  2. If a TC 150 for the same tax period is already posted to both the invalid and valid taxpayer's account , 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-2014)
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-2014)
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.

      Note:

      For FSC 2 taxpayers with the same last name for primary and spouse, enter the last name only once. (example, John & Mary<Jones)

    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 taxpayer on valid side has changed his name and not notified SSA (no matching name control with SSA), input TC 013 on the valid side, URC 0 and later cycle.

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

      Note:

      Document will need to be perfected if correcting the name control to a name not found in the Entity portion of the return (e.g. if the taxpayer signed with the valid DM-1 name, but a different name was typed into the Entity section of the return.

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

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

      Note:

      Later cycling is necessary any time the account will change from valid to invalid, or from invalid to valid.

  4. If the transaction is intended for a BMF account, close with URC 8 with instructions to renumber the document. Exception: UPCs 198 and 305 can be closed to post to an IMF account and transferred at the same time to a BMF account. Input TC 570 to prevent an erroneous refund.

    1. If the document is a return, attach page one of the correct form (1041, 1065, 1120, etc.), with the entity section completed. Provide instructions to renumber to BMF and correct EIN, MFT, tax period, and/or name control.

    2. If the transaction is a payment, other than UPC 198 or 305, prepare a "dummy doc", noting the necessary corrections. Notate the Trace ID on the "dummy doc"

    .

  5. 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 unless Schedule SE or Form 5329 is present for the primary taxpayer. If either is present, correct with URC 8.

      Note:

      If return has an amount entered for line reading “Additional tax on IRAs, other qualified retirement plans, etc. Attach Form 5329 if required”, check CC TRDBV to see if Form 5329 has been "dummied in". If so, correct with URC 8.

    3. If primary SSN and secondary SSN are reversed or both are incorrect, check for any SE Schedule(s) or Form(s) 5329. 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-2014)
Correcting TINs when Schedule SE or Form 5329 is present

  1. If any SE Schedule(s) or Form(s) 5329 are present (may be dummied in by ERS, check TRDBV) and the SSN for the primary is incorrect on the return, and/or incorrectly transcribed by the IRS,

    1. perfect the document.

    2. Close with URC 8 with instructions to correct the TIN on the entity record and Schedule SE and/or Form 5329.

  2. If the Schedule SE or Form 5329 is for the secondary taxpayer:

    1. If the TIN on the Schedule SE or Form 5329 is correct, close with URC 6 to correct primary TIN. Perfect the document.

    2. If the TIN on the Schedule SE or Form 5329 is incorrect, close with URC 8. Request Rejects to correct primary TIN and to correct Schedule SE or Form 5329. Perfect the documents.

3.12.179.17.6.2  (01-01-2014)
SE Schedule(s) or Form(s) 5329 are not present.

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

    1. perfect the document,

    2. correct SSN using URC 6.

3.12.179.17.6.3  (01-01-2014)
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 URC 8 to have Rejects correct the 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 2 or 3, enter the correct NL from the unpostable record.

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

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

    Note:

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

3.12.179.17.6.4  (01-01-2014)
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 (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).


More Internal Revenue Manual