AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 5. Collecting Process

Chapter 9. Bankruptcy and Other Insolvencies

Section 15. Payments in Bankruptcy

5.9.15  Payments in Bankruptcy

5.9.15.1  (05-20-2008)
Payment Addresses

  1. Chapter 7 and Chapter 13. Trustees have been instructed to send all Chapter 7 and Chapter 13 payments to the Centralized Insolvency Operation (CIO). The proper mailing address for these checks is Insolvency Remittance, Post Office Box 21125, Philadelphia, PA 19114-0325.

  2. Chapters 11,12 and 15. Payments for Chapter 11 and Chapter 12 cases should be sent to the local Field Insolvency offices assigned to the cases. If a Chapter 11, 12, or 15 check is inadvertently mailed to the CIO, the CIO Payment Processing Unit must post the check as required by Campus procedures.

5.9.15.2  (05-20-2008)
Applying Payments in Bankruptcy

  1. Conversion to Oracle. Current IRM 5.9 instructions for accessing information and inputting data on the Automated Insolvency System (AIS) are based on the Informix database system which is being phased out. For AIS databases that have converted to the Oracle operating system, users must consult the AIS Oracle user guide for instructions.

  2. AIS Processing. AIS processing is available for most bankruptcy and bankruptcy-related payments. Step instructions for posting payments are provided in this IRM section. Payment posting vouchers prepared by Field Insolvency and the accompanying payments are routed to the delegated Campus for posting. Bankruptcy payments remitted by the bankruptcy estate and received by the CIO are processed at the Philadelphia Campus. (Only Chapter 7 and Chapter 13 trustee checks should be going to the CIO.) Bankruptcy-related payments not being paid by the bankruptcy estate (payments with a DPC other than 03 or 11) received by the CIO will be scanned and posted by the Philadelphia Campus Support function. If, for some reason, payments cannot be scanned, the remittance will be processed in accordance with Campus Support guidelines. IRM 3.8.44.4.3 outlines acceptable payee names and payee names that require overstamping.

    Note:

    To resolve payment posting problems, Insolvency employees must familiarize themselves with all aspects of AIS, including the AIS User's Guide, AIS Alerts, and AIS enhancements.

  3. Bankruptcy – Involuntary Payments. Payments received through the bankruptcy proceeding are considered involuntary payments. Absent court orders or confirmed plan designations to the contrary, bankruptcy payments are applied as follows ( See Exhibit 5.9.15-9 for details of automatic allocation.):

    1. First to liabilities listed as secured;

    2. Then to unsecured priority; and

    3. Lastly, to the claim's unsecured general class.

    Note:

    It may be in the government's best interest in some cases to apply the payment first to the general unsecured liabilities if other liabilities are nondischargeable and may be collected from the debtor's after acquired property.

  4. Dischargeable Liabilities. Payments should be applied to dischargeable liabilities in the same manner as above.

    Note:

    If a dischargeable liability has been adjusted at the time the payment is received, Insolvency should readjust the account and apply the payment to the discharged liability before applying it to the non-discharged liability on the proof of claim or according to local guidelines.

  5. Court Designation. If a confirmed plan or a court order defines payment designation, the payment will be manually applied as directed. ( See IRM 5.9.15.14.5. )

  6. Counsel Guidance. When complex or unusual concerns arise, Counsel should be consulted.

5.9.15.2.1  (03-01-2006)
MFT 31 Payments

  1. MFT 31 Payment and Credit Applications. Once MFT 31 mirror modules have been created, both modules carry a TC 971 ac110 which causes certain payments and credits to cross reference from one spouse to the other. When credits are posted to one of the accounts, IMF will cross reference the other module with TC 290 for .00 and TC 766 ref # 337. This credit will reduce the unpaid balance on the module, but is a nonrefundable credit.

    The credits that will cross reference are:
    TC 610 TC 64X TC 66X TC 67X TC 68X TC 69X
    TC 79X TC 72X TC 73X TC 76X TC 80X TC 82X

    Note:

    When master file cross-references these credits, it bypasses unpostable reviews for freeze conditions related to bankruptcy, offers in compromise, innocent spouse, Taxpayer Assistance Orders, and Examination.

  2. Non-Transferable MFT 31 Credits. Credits with a designated payment code (DPC) 31 on an MFT 31 mirror module will not cross-reference to the spouse's MFT 31 module.

    Note:

    DPC 31 is used only on MFT 31 mirror modules to prevent credits from cross-referencing.

  3. MFT 31 Refunds. If a refund is issued on a module with a posted TC 766 reference number 337, a REFMFT 31 transcript generates. These transcripts are worked by Accounts Management. Insolvency will continue to receive litigation transcripts cases with open -V freezes.

5.9.15.2.2  (05-20-2008)
Payments on Unfiled Returns

  1. Trustee Payments on Unfiled Returns or Unassessed Deficiencies. During a bankruptcy proceeding, the Service may file an unassessed (estimated) proof of claim to protect the government's interests. The trustee sends payments to the IRS on the proposed liability based on the Service's claim:

    1. when the debtor has failed to file a tax return; or

    2. when an SFR assessment or an assessment for a tax deficiency has been proposed.

  2. Payment Retention - Exception Allowed for Bankruptcy. Because of the bankruptcy, the Service is allowed to retain trustee payments based on the IRS’s unassessed claims even though the case has unmatched payments (e.g., unresolved credits) if:

    1. the Service's claim has been estimated, and the debtor has not filed an original return; or

    2. Examination does not pursue the assessment of a proposed deficiency, unless Exam advises Insolvency the debtor has provided adequate documentation to rescind the proposed deficiency.

  3. Deposit to URF or XSF. Such payment(s) will be deposited by the Service, posted through AIS, and credited to either the Unidentified Remittance File (URF) or to the Excess Collections File (XSF). The determining factor is the age of the payment.

  4. URF Guidelines. If the IRS received date of the credit is less than 11 months from the date Insolvency prepares the form for processing the credit, the payment goes to URF accompanied by Form 2424, Account Adjustment Voucher.

    • This two-part form authorizing the credit to be moved to the Unidentified Remittance File (URF) must be used when a credit is less than 11 months old.

    • Form 2424 must be prepared indicating the credit side to the URF account.

    • A separate form must be completed for each credit being moved.

    • Verification (Integrated Data Retrieval System (IDRS) or Corporate Files On Line (CFOL) prints) must be attached to prove the current status of the credit and to show the date of payment.

      Note:

      Annotation on the form should read: "This credit is a bankruptcy payment and should not be refunded or applied." Also, the form must indicate, "NO FOLLOW-UP ACTION WITH TAXPAYER IS REQUIRED" so the Service will not attempt to contact the debtor.

    • Accounting will add the credit to the URF.

    • When the payment reaches 11 months of age, it automatically rolls over to the XSF.


  5. XSF Guidelines. If the IRS received date of the credit is 11 months or more from the date Insolvency prepares the form for processing the credit, the payment is forwarded to XSF using Form 8758, Excess Collections File Addition.

    • Form 8758 must be completed to move the credit to the Excess Collections File.

    • A separate form is required for each credit being transferred.

    • Verification (IDRS or CFOL prints) must be attached to prove the existence of the credit to be transferred to XSF and to show the date of payment. (See IRM 21.2.4.4.15.1, Excess Collection File.)

      Note:

      The form should be annotated, "This credit is a bankruptcy payment and should not be refunded or applied." The form must also state, "NO FOLLOW-UP ACTION WITH TAXPAYER IS REQUIRED," so the Service will not try to contact the taxpayer.

  6. Credit Resolution. When an unresolved credit appears on a tax module for a bankruptcy account, Insolvency employees must exhaust all efforts to resolve the credit prior to its transfer to either URF or XSF.

    Note:

    If a payment has been transferred to the Excess Collections File, and a return is subsequently filed by the debtor, the payment can usually be retrieved from the XSF and applied to the account.

5.9.15.2.3  (05-20-2008)
Payments on Claims Filed on Behalf of IRS

  1. No Plan Loaded. When the Service does not file a claim in a bankruptcy proceeding, and the debtor or trustee files a claim on behalf of the IRS without the Service’s knowledge (see IRM 5.9.13.3(2),Claims Filed on Behalf of IRS), neither the AIS claim screen nor the plan payment screen is loaded before payments are received by CIO Payment Posting unit. The following steps explain the actions necessary to post payments on these claims.

    1. When the first payment is received on a claim filed by the debtor or trustee on behalf of the IRS, the payment posting technician must apply the payment to the non-plan screen so the payment can be processed.

      Note:

      If the case is not on AIS, the technician must retrieve case information from the court's electronic records (usually PACER) and load the case onto AIS prior to applying the payment.

    2. The Payment Posting Unit must advise the assigned Field Insolvency caseworker of the payment so a claim can be prepared and filed by the IRS should that be the local practice.

    3. Regardless of whether the Field Insolvency caseworker files a claim, (s)he will be responsible for establishing a plan payment screen on AIS and moving the payment from the non plan screen to the plan payment screen within fifteen business days of notification by the CIO.

    4. If by the time a second payment is received, a plan payment screen has not been opened by Field Insolvency, the CIO payment technician will open a dummy plan screen using the total IDRS balance due up to the petition date for each period as the claim amount. Each period will be listed as " priority" tax. The plan payment amount will be $0.50. This dollar amount will permit an optional report to be generated identifying uncorrected plans.

5.9.15.2.4  (05-20-2008)
Surplus Payments from Trustee

  1. Trustee Overpayments. When the dollar amount on the AIS plan screen has been overpaid, AIS generates an overpayment message on the payment voucher advising the user of the overpayment. Overpayments cannot always be identified by AIS. Those overpayments may be identified by the DUPREF list, an IDRS report discussed later in this IRM section. ( See IRM 5.9.15.6.2.) If a trustee remits a payment that is more than the unpaid balance of a claim against a debtor, the surplus payment amount, or the entire check, if appropriate, should be returned promptly to the trustee.

    1. If a check from a trustee is for a single debtor and the claim has previously been full paid, the check should be returned to the trustee accompanied by IDRS letter 549C explaining the reason for the check's being returned.

    2. If a check from a trustee is for a single debtor and only a portion of the remittance is needed to full pay the claim, the payment should be applied to the account and the overpayment refunded to the trustee.

    3. If an overpayment of a claim (either full or partial) has been received from a trustee on a check for multiple debtors, the actions in paragraph (2) below must be followed. The CIO Payment Processing Unit is responsible for determining the cause of the overpayment and posting the payment accompanied by a request for input of TC 570 to prevent the overpayment from being refunded to the debtor.

    4. Correcting the underlying cause of an overpayment, such as an incorrect plan screen or lack of an amended claim or credit letter, remains the responsibility of the applicable Field Insolvency office. If the payment identified by AIS as an overpayment is not to be refunded to the trustee because it is not a true overpayment, Field Insolvency must ensure the payment is posted to the correct module. This may require a credit transfer and/or moving the payment from the AIS non plan screen to the plan screen and adjusting the dollar amount on the "overpayment" field on the master plan screen.

  2. Working Overpayment Errors. Not every overpayment error identified by AIS is a true overpayment. IDRS, AIS, and PACER research may be required. The following check list can help in determining if the overpayment is genuine requiring a manual refund be sent to the trustee. The caseworker should compare the AIS claim screen and the plan screen on AIS. If the dollar amount of the claim does not equal or exceed the dollar amount of the plan screen, the caseworker should, as necessary:

    1. check the first page of the claim screen to determine if a dollar amount has been input in the offset field. This amount should not be included on the plan, because this is money the trustee will not be sending the Service;

    2. determine if the claim has been amended, but the plan screen has not been updated accordingly;

    3. look for the presence of an administrative claim;

    4. determine if general unsecured plans have been correctly loaded;

    5. determine if postpetition accrued interest is allowed on the Service's claim;

    6. research for duplicate check postings;

    7. research PACER for a claim filed on behalf of the IRS. ( See IRM 5.9.15.2.3); and/or

    8. review prior AIS history for indication of BMF liabilities being paid through the plan.

    Caution:

    The "Over Paid Amt" field on the AIS master plan screen does not necessarily reflect the true amount of an overpayment and may require manual adjustment.

  3. Amended Claims. If a claim has been amended, a number appears in the amended claim field with a date below the number on the AIS master claim screen. The caseworker should compare the amended claim amount and the plan amount. If the amount on the amended claim screen is larger than the plan screen, the caseworker should compare the detail screens of both to determine where to post the overpayment. Then the case must be transferred to the appropriate Field Insolvency group to update the plan screen. Field Insolvency must correct the plan, move the payment from the non-plan screen to the appropriate period, and then remove the payment from the non-plan screen within 15 business days of notification by the CIO.

  4. Incorrectly Loaded General Unsecured Plans. Plans often give the percentage the debtor will pay toward unsecured general claims. Rather than load the entire tax liability for this claim classification, some offices load only the dollar amount provided in the plan. For example, if the plan proposes to pay 17% on general unsecured claims and the total balance of the general unsecured claim is $1,000, the plan is loaded for $170 instead of $1,000. If the estate generates more money than expected, more will be paid to unsecured general creditors resulting in a trustee overpayment error. For this reason unsecured general plans must be loaded for the full amount of the unsecured general liability. If the Payment Posting Unit identifies a case where the unsecured general plan is not loaded correctly, the caseworker should post the payment to the non-plan screen and transfer the case to Field Insolvency for correction. Field Insolvency must correct the plan, move the payment from the non-plan screen to the appropriate period, and then remove the payment from the non-plan screen.

  5. Interest Not Shown on the Plan. If the claim screen and the plan screen match, the caseworker should determine if any periods have been classified as "secured" on the claim. The Service may be entitled to interest on a secured claim.

    Note:

    Some courts are allowing accrued interest to be paid on priority as well as secured claims. For courts where accrued interest is allowed on priority claims, the actions provided in this paragraph should also be taken relative to priority periods.


    The AIS master plan screen should indicate if the plan detail screen was loaded correctly to allow for accrued interest. If the "Interest Code" field on the master plan screen is D or S, a number should appear in the "Optional Int" field to indicate the interest rate the trustee is paying on the secured claim. Refer to IRM 5.9.15.3(1) for TC 340 information. If the period classified as "secured" has no Interest Code/Optional Int field, the caseworker should check AIS history for documentation indicating the interest amount. If none is found, the case must be transferred to the appropriate Field Insolvency office for further research and/follow-up actions.

  6. Duplicate Postings. At times a trustee payment may be posted on AIS more than once. When this occurs the duplicate posting(s) must be removed so only one posting remains on the AIS system. Duplicate postings can be identified through the Plan Monitoring Payment Record report. To generate this report for a specific docket number, the caseworker must take the following steps.

    1. Access the proper AIS database.

    2. From the AIS Main Menu, select option 6, Payment Monitoring.

    3. From the menu that appears, select option14, Plan Reports.

    4. From this menu, select option 2, Payment Record.

    5. Input the correct docket number.

    6. Confirm the account accessed is the account with the payment issue.

    7. Select Y for Laser Printer or 2 for Auxiliary Printer.

    8. Analyze the printed report for duplicate payments by looking for two or more identical check numbers, identical dates, and/or identical dollar amounts. Also consider possible typographical errors (e.g., check 083115 vs check 0831115).

      Note:

      This report must accompany any manual refunds originating at the CIO to return trustee overpayments. If a duplicate posting is for a check processed by Field Insolvency, the case must be referred to the appropriate Field Insolvency group for correction.

  7. Payments Posted on the Non Plan Screen. Payments that have posted to the non plan screen and subsequently moved to the plan screen must be removed from the non plan screen. Instructions for removing a payment can be found in Exhibit 5.9.15-3. The caseworker who moves the payment from the non plan screen to the plan screen must also remove it from the non plan screen.

  8. Administrative Plan. If the claim screen and the plan screen reflect identical amounts and no periods have been classified as secured, the caseworker should determine if an "administrative plan" has been loaded. The step list below provides guidance for identifying an administrative claim and correctly posting administrative payments.

    1. From the AIS Main Menu, select option 6,Payment Monitoring.

    2. From the menu that then appears, select option 1, Payment Monitoring Data.

    3. Query the docket number in question.

    4. When the case is accessed, determine if more than one row is listed by looking at the bottom left hand corner of the AIS screen display.

    5. If two rows are present, one for a confirmed plan and one for an administrative plan, determine which plan has a remaining balance due.

    6. If the balance is on the administrative plan, from the Payment Posting Menu select option 4, Post Automatic Payment, and change the plan type to A(dministrative) rather than C(onfirmed).

    7. If the confirmed plan is full paid, enter today's date in the closed plan date field.

    8. If no administrative plan appears on the plan screen, determine if an administrative claim has been filed but not loaded by checking the AIS master claim screen. (See Exhibit 5.9.15-4.)

    If only one claim (shown as "one row" ) exists on the master claim screen and an amended claim has not been filed, the caseworker must read the AIS history to determine if a reason can be found for the overpayment. Research on the court's electronic records (usually PACER) may be required to determine if more than one claim has been filed for the Service or if the claim filed with the court matches the dollar amount on the AIS plan screen.

  9. Posting Overpayments. Procedures for trustee overpayments received on single checks should be handled according to IRM 5.9.15.2.4, Surplus Payments from Trustee. Overpayments identified on bulk checks should be posted on periods found on the plan. (See IRM 5.9.15.6,Proper Application of Payments.) To view the plan periods, the caseworker should follow the steps in Exhibit 5.9.15-4. From the plan screen a period can be selected and the payment posted to it. If a case is open on AIS, a TC 520 with closing code 81 should be posted to the case before the payment is posted. If the overpayment is for a case that has been full paid, dismissed or discharged, a request for a TC 570 must accompany the payment. This will prevent the overpayment from systemically refunding to the debtor.

  10. Monitoring for Overpayment Posting at the CIO. The caseworker must input an AIS history explaining where the payment was posted along with an annotation that the payment must be refunded to the trustee. An ACTON control base must be opened on the IDRS module where the overpayment has posted so posting of the payment can be monitored. CIO caseworkers must complete a "Monitoring for Payment Posting " follow up sheet and attach a copy of the posting voucher indicating the overpayment amount. The sheet must be placed in the designated follow-up folder.

  11. Working Follow-ups. After a true overpayment from a bulk trustee check has posted, it must be refunded. A CIO technician will be assigned to work the overpayment follow-up folder weekly. IDRS must be accessed to determine if the payment has posted. If not, the caseworker will set the follow up for one additional week. Once the payment has posted, AIS must be checked for case disposition and the following actions should be taken:

    1. Discharged Cases. The caseworker should call the trustee before refunding the payment. Because the trustee may have to reopen the case to distribute the money, (s)he may ask the Service to refund the overpayment to the debtor

    2. Dismissed Cases. Once the bankruptcy freeze is released on a dismissed case, any credit balance remaining on the dismissed modules will systemically offset to any debit modules or be systemically refunded to the debtor. No manual actions are required unless a TC 570 has frozen the overpayment. In that case a TC 571 must be input..

    3. Open Cases. If a determination is made to refund a payment to the trustee, the caseworker must send Letter 549C to the trustee explaining why the payment is being returned. Because of the logistics of sending the refund check and the letter together, Letter 549C should explain the refund will be sent "under separate cover."

  12. Recomputing the Plan. After all payments which were refunded have been reversed, the plan must be recomputed. See Exhibit 5.9.15-8 for step instructions on plan recomputation.

  13. Request for Return of Payment. A trustee may send the Service a payment in error and ask for its return. The Service will honor the trustee's request. Once the payment has posted to the debtor's account, a manual refund must be prepared for the trustee and the payment backed out of the AIS plan payment screen.

  14. No Interest Computation. If a payment is sent by a trustee in error (e.g., the Service is not entitled to any payment on the distribution scheme, or the Service has been paid out of turn), the trustee will not receive interest on the refund. However, if a trustee's payment is in excess of the Service's claim, the amount of the excess may be an overpayment, and the trustee may be entitled to interest if the refund is not made within 45 days of receipt of the overpayment.

5.9.15.2.5  (05-20-2008)
Payments Received after AIS Discharge Closure

  1. Chapter 13 Final Distribution. Some Chapter 13 trustees hold the final distribution of funds to creditors until the case has been closed by the court. Generally the IRM requires closing actions on a case be initiated within 30 calendar days of notification of a discharge, dismissal, or non-discharge. However, in cases where trustees send final distribution after the discharge, closing actions need not be initiated until the final payment is posted on AIS. Nonetheless a case may be closed on AIS before final distribution is received. If the case is closed on AIS and an abatement has been completed on IDRS, the abatement should be reversed, and the trustee payment(s) should be applied to the debtor's account.

  2. Chapter 7 Asset Final Distribution. Chapter 7 trustees may remit final distributions months or years after a case has closed. IRM 5.9.17.11 gives instructions on how to process corporate Chapter 7 Asset cases if a distribution is anticipated. Non-corporate Chapter 7 Asset cases cannot be closed as currently not collectible while the Service awaits a possible distribution from the trustee. See IRM 5.9.17.9(4),Asset Discharge for Individual Debtor, for procedures for processing final distributions to non-corporate Chapter 7 cases.

5.9.15.2.6  (03-01-2006)
Payments Resulting from DOJ Negotiation

  1. Negotiated Settlement. When Insolvency requests a referral for an objection to a plan, the Department of Justice (DOJ) files the objection on behalf of the Service. DOJ and the debtor may arrive at a negotiated settlement of the tax claim. If a settlement is reached, DOJ sends the check to the IRS lockbox for the payment to post to the debtor's account on IDRS with a designated payment code of 99.

  2. Credit for Insolvency. The amount received by DOJ in the settlement should be posted through the debtor's account on AIS so Insolvency can receive credit for collecting the funds through its efforts.

5.9.15.2.7  (03-01-2006)
Designated Payment Code

  1. Payment Codes. DPC 03, should be used for most bankruptcy payments. When a confirmed plan provides for designation to trust fund taxes, DPC-11 must be used. Document 6209 provides information on designated payment codes.

5.9.15.2.8  (03-01-2006)
Taxes Owed by Bankruptcy Estate

  1. Admin Expenses. Taxes paid by a trustee or a debtor-in-possession, as an administrative (admin) expense, are credited only against the taxes incurred by the bankruptcy estate. Non-pecuniary loss penalties that relate to taxes paid by the trustee are also an administrative expense. Penalties that do not relate to any tax but which were incurred postpetition during the normal operation of the business may be entitled to administrative expense status.

5.9.15.3  (03-01-2007)
Plan Interest Rates

  1. Excess Interest. For cases with petition dates prior to October 17, 2005, the interest rate of the plan may exceed the usual rate of interest charged by the government (as prescribed in IRC § 6621). This excess interest may cause a credit balance account as an outcome. These credits must not be refunded to the debtor or transferred to any other modules. To resolve the excess interest payment, Insolvency must input TC 340, restricted interest, in the same amount as the excess interest payment. ( See IRM 5.9.15.2.4.)

    Note:

    For large corporate underpayments, IRC § 6621(c) provides a rate that is two percentage points greater than the normal underpayment rate.

  2. Post BAPCPA Interest. The Bankruptcy Abuse Prevention and Consumer Protection Act (BAPCPA) amends 11 USC § 511(a) to establish a uniform interest rate on Chapter 11, 12, or 13 tax claims or administrative expense taxes using the interest rate being charged by the IRS as determined by IRC § 6621. For taxes being paid through a confirmed plan, the rate of interest is determined as of the calendar month the plan is confirmed.

    Note:

    For large corporate underpayments the interest rate is two percentage points greater than the normal underpayment rate.

  3. Postpetition Interest. For cases filed on or after October 17, 2005, 11 USC §§ 1222(b)(11) and 1322(b)(10) specifically allow postpetition interest on claims that are not dischargeable under 11 USC §§ 1228(a) and 1328(a). The Service may be able to obtain interest on those taxes to the extent they are provided for in the plan, but only if the debtor has sufficient disposable income to pay the interest after full payment of all allowed claims. This provision does not affect the Service's right to interest under the "best interest of creditor's test" set forth in 11 USC § 1325(a)(4).

5.9.15.4  (03-01-2006)
Non-Pecuniary Loss Penalty Payments

  1. Punitive Penalty Rule. A non-pecuniary loss penalty is a punitive penalty, or "fine, " such as a failure to file or a failure to pay penalty. The priority of payments made in a Chapter 7 case is set forth in 11 USC § 726. Because general unsecured claims are paid ahead of any claims for non-pecuniary loss penalties, payments should not be applied to non-pecuniary loss penalties until all other general unsecured claims are paid.

5.9.15.5  (05-20-2008)
Unassessed Liability/No Open Modules

  1. Establishing Modules for Pending Assessments. Insolvency sometimes receives payments on a bankruptcy case when the Service's proof of claim reflects a liability not yet assessed, and no modules or filing requirements are open on IDRS. Dummy modules must be established on IDRS when the proof of claim is prepared to hold payments until assessments have posted.

    Example:

    A tax module is set up on IDRS in preparation for a pending assessment of a Trust Fund Recovery Penalty (a pecuniary loss penalty assessment), or for a secondary (debtor) spousal situation, the spouse having now filed a separate return after filing jointly for prior year(s).

  2. Procedures for Creating New (Dummy) Modules. Payments received on an estimated claim cannot post unless a valid entity has been established on master file and a corresponding module appears on IDRS. If the estimated claim covers a period currently appearing on IDRS, such as a TDI, IIP will input a systemic TC 520 on the period allowing payments to post. However, if a module does not appear on IDRS, a new module (sometimes referred to as a "dummy" module) must be created prior to receipt of the trustee’s first payment. In jurisdictions where trustees routinely remit payments prior to confirmation, dummy modules should be created upon initial case review. In all events dummy modules must be created prior to transferring cases with estimated claims to the CIO. Three scenarios must be considered in creating dummy modules:

    1. Entity with Valid Established Date. If the entity on master file was established prior to the estimated claim period, a dummy module is created by inputting a TC 520 with the appropriate closing code on IDRS for the estimated period. Command code (cc) REQ77 is used for this action.

      Example:

      The entity was established on master file in 1999 and the estimated period is for 200112.

    2. Entity with No Valid Established Date. If the entity on master file was established after the date of the estimated period, the entity establishment date must be post dated to include the estimated period. Without this master file change, payments to the estimated period will go unpostable. The CIO will complete the necessary actions on-line using cc ENREQ for cases initially in their inventory. (See the exhibit in IRM 2.4.9-6.) Field Insolvency will prepare Form 2363 directing Centralized Case Processing (CCP) to move the entity establishment date to an earlier period for cases initially in their inventory.

      Example:

      The entity was established on master file in 2001 and the estimated period is for 199912.

      This adjustment usually takes three to four cycles so the caseworker must follow up to monitor the completion of the entity assessment. Once the entity establishment date has been changed, the caseworker must create a dummy module by using cc REQ77 to input TC 520 for the estimated period. The caseworker will know the establishment date has been changed when the "Name Line Yr" on ENMOD reflects the requested date.

      Caution:

      Attempting to input the TC 520 with a posting delay before the entity has been changed will cause the TC 520 to unpost.

    3. Entity Not Established on Master File. If the debtor has never filed a return or has always filed as a secondary taxpayer with a primary spouse (for joint returns filed prior to January, 2001), the debtor will not have an entity established on master file. (For joint returns filed on or after January, 2001, entities are established systemically for secondary spouses.) Without an established entity, payments made toward an estimated claim will go unpostable. The CIO will complete the on-line actions necessary to establish the entity using cc ENREQ for cases initially in their inventory. (See the exhibit in IRM 2.4.9-6.) Field Insolvency must prepare Form 2363 directing CCP to establish the entity on master file for cases initially in their inventory. Once the entity has been established, the Field Insolvency caseworker must create a dummy module by using cc REQ77 to input TC 520 for the estimated period.

    Note:

    When ENMOD updates and a new module is created with the input of TC 520 through REQ77, the new module will not be identified on IDRS as "dummy."

  3. Field Prevention of Unwarranted Refunds. To avoid systemic refunds when trustee payments are received on unassessed claims:

    1. Field Insolvency must ensure TC 520s with appropriate closing codes are entered on all tax modules for which unassessed claims are filed, and

    2. Field Insolvency caseworkers must establish the module on IDRS prior to receipt of the first payment to allow the CIO Payment Processing Unit to post the payment on AIS automatically, averting the need for manual application.

  4. CIO Prevention of Unwarranted Refunds. When trustee payments are received on unassessed claims or on cases that have closed as no liability (NL), the CIO must:

    • input a TC 520 on prepetition periods;

    • post the payment as non-plan; and

    • refer the case to Field Insolvency for correction.

5.9.15.6  (03-01-2006)
Proper Application of Payments

  1. Plan Guidelines. Insolvency must apply payments appropriately and in accordance with the terms and conditions of a plan or court order. Payments received must be applied only to the tax periods covered under the bankruptcy.

  2. Avoiding Improper Application. Payments received from the bankruptcy for prepetition taxes must not be applied to any part of a tax period for which a proof of claim has not been filed, or any component of a tax liability that is not allowed or not payable under the particular provisions of the bankruptcy chapter (for example, postpetition penalty). BAPCPA adds 11 USC § 524(i) stating a willful failure to credit payments received under a confirmed plan in a manner required by the plan that causes material injury to the debtor is a violation of the discharge injunction and may subject the Service to damages and attorney's fees under IRC § 7433(e). Insolvency should correct any misapplication of payments as soon as the error is brought to the Service's attention.

    Note:

    If a case is dismissed, the order confirming the plan is revoked, the plan is defaulted, or the Service has not received payments required under the plan, § 524(i) does not apply.

5.9.15.6.1  (03-01-2007)
Campus Support Error Reports

  1. Correcting Payment Posting Errors. Using payment posting vouchers generated by AIS, the IRS Campus Support function posts payments to IDRS. When the period on the payment voucher does not reflect any open module on IDRS, the Campus Support workers post the payment to any balance due on the account or on a cross reference account without regard to the bankruptcy status of that module. Generally these posting errors result from incorrectly loaded AIS plan payment screens. CIO payment posting technicians must take the following actions to resolve posting errors identified by the Campus Support function.

    IF... THEN...
    the name control on the plan payment screen is incorrect, the CIO will update the name control on the TIN screen.
    the TIN on the plan payment screen is obviously incorrect, the CIO will
    • correct the TIN on the plan payment screen
    • add NPS SSN on AIS entity screen if necessary
    • complete credit transfer if necessary.
    the primary taxpayer on IDRS is deceased, but the secondary taxpayer on IDRS is the debtor, and the CSED has expired, the CIO will:
    • take actions to ensure the payment is not systemically refunded
    • create an MFT 31 mirror for the account if the criteria for mirroring are met
    • remove the payment from the decedent's MFT 31 account if appropriate
    • correct the AIS plan screen to show the correct MFT and the debtor's SSN
    the tax period is obviously incorrect per IDRS,
    Example: 30 200204     		the CIO will correct the tax period on the plan payment screen.
    an unassessed period is
    • on the plan payment screen;
    • no dummy module has been created; and
    • the entity has not been established on master file,     		the CIO will transfer the case to Field Insolvency to
    • request CCP establish the entity on master file through ENREQ;
    • create a dummy module; and
    • input a confirmed plan on the plan payment screen.
    an unassessed period
    • is on the plan payment screen;
    • no dummy module has been created; and
    • the unassessed module is for a period falling prior to the establishment of an entity on master file,     		using command code ENMOD, the CIO will establish the entity name line for the earliest unassessed period on the POC. This action will appear as a TC 013 on ENMOD.
    See Exhibit in IRM 2.4.9-4.
    an unassessed period
    • is on the plan payment screen,
    • no dummy module has been created, and
    • the unassessed module is for a period falling after the entity for the taxpayer was established on master file,     		the CIO will create a dummy module for the unassessed period on IDRS by inputting a TC 520 through REQ77.
    the case does not have a confirmed plan loaded, the CIO will transfer the case to Field Insolvency to input a confirmed plan on the plan payment screen. See Exhibit 5.9.15-5 for additional information relating to No Confirmed Plan.
    Note: This includes when a claim has been filed by the debtor or trustee on behalf of the Service.