5.9.15 Payments in Bankruptcy

Manual Transmittal

December 15, 2017

Purpose

(1) This transmits a revised IRM 5.9.15, Bankruptcy and Other Insolvencies - Payments in Bankruptcy.

Material Changes

(1) Editorial changes were made throughout this section to add, clarify and update citations.

(2) IRM 5.9.15.1 adds subsection to outline internal controls for this section.

(3) IRM 5.9.15.3 adds instructions for MFT 65 payments.

(4) IRM 5.9.15.3.2 clarifies instructions for transferring payments to URF/XSF files.

(5) IRM 5.9.15.3.4 clarifies instructions for returning Trustee Overpayments.

(6) IRM 5.9.15.7.1 adds instructions for utilization of Name Control GII tool.

(7) IRM 5.9.15.7.2 clarifies instructions for multiple refunds.

(8) IRM 5.9.15.13 removed obsolete instructions for RS-PCC.

(9) IRM 5.9.15.15 adds NDC processing steps.

(10) Removed obsolete IRM 5.9.15.15.1, Chapter 13 Payments on Disk.

(11) Removed obsolete Exhibit 5.9.15-1, Virus Scanning.

(12) Removed obsolete Exhibit 5.9.15-4, Preparing Letter 549 C.

Effect on Other Documents

mThis material supersedes IRM 5.9.15, dated August 6, 2015. This revision incorporates Interim Guidance Memorandum SBSE-05-0917-0056, Processing the MFT 65, Individual Shared Responsibility Payment (SRP) Mirror Assessment, in Bankruptcy Cases, effective October 7, 2017.

Audience

Speciality Collection Insolvency.

Effective Date

(12-15-2017)

Kristen Bailey, Director
Collection Policy

Program Scope and Objectives

  1. This IRM section and subsections provide guidance on processing Insolvency/Bankruptcy payments (Bankruptcy Trustee checks) and Insolvency-related payments (checks received from parties other than the Bankruptcy Trustee).

  2. Purpose: To provide step-by step instructions for posting insolvency/bankruptcy and related payments received by the Centralized Insolvency Operation (CIO) located in the Philadelphia Campus and by the local Field Insolvency (FI) offices.

  3. Audience: Insolvency caseworkers and management in Specialty Collection, Insolvency (SCI) are the primary users of this IRM section. Advisors, Revenue Officers (RO), and other SBSE employees may refer to these procedures. Employees in functions other than SB/SE may refer to this section when working with taxpayers that have filed an Insolvency proceeding.

  4. Policy Owner: The Director of Collection Policy is responsible for issuing policy for the Insolvency Program.

  5. Program Owner: The program owner is Collection Policy, Insolvency, an organization within Small Business/Self Employed Division (SB/SE).

  6. Primary Stakeholders: The primary stakeholders are SCI and SB/SE Collection.

  7. Program Goals: To facilitate the efficient posting of payments received by Insolvency caseworkers and to promote timely and effective actions. By following these procedures, Insolvency caseworkers will help to ensure the Government’s interests are protected during the bankruptcy proceedings.

Background

  1. Internal Revenue Manual (IRM) 5.9, Bankruptcy and Other Insolvencies, contains the Service’s position, procedures, information, instructions, guidance, and references concerning bankruptcy cases, stockbroker insolvencies, receiverships, assignments for the benefit of creditors, corporate dissolutions, and bulk sales.

  2. This IRM specifically provides procedures and step-by step instruction for the posting of Insolvency and Insolvency-related payments.

Authority

  1. The Insolvency program operates within the guidelines of the Bankruptcy Code (11 USC), the Bankruptcy Reform Act of 1994 (BRA 94), and the Bankruptcy Abuse Prevention and Consumer Protection Act of 2005 ( BAPCPA).

Roles and Responsibilities

  1. The Director, Speciality Collection Insolvency is responsible for program oversight.

  2. Field Specialists are responsible for preparing payment posting vouchers for payments received by the local Field Insolvency office.

  3. Centralized Insolvency Caseworkers are responsible for preparing payment posting vouchers for payments received at the Philadelphia Campus.

  4. IRM 5.9.1, Bankruptcies and Other Insolvencies - Overview of Bankruptcy, provides a list of titles and responsibilities with an explanation of their roles and authority.

Program Management and Review

  1. IRM 1.4.51, , Resource Guide for Managers, Insolvency, provides guidance for program management and review of Insolvency programs.

  2. Managers are required to follow program management procedures and controls addressed in IRM 1.4.51.4.2, Reviews (Overview),IRM 1.4.51.14, Controls, and IRM 1.4.51.15, Quality.

  3. Operational and Program reviews are conducted on a yearly basis. See IRM 1.4.51.16.2, Operational Review and IRM 1.4.51.16.5, Program Reviews , for more information.

Program Controls

  1. Insolvency caseworkers must ensure payment amounts and posting vouchers balance exactly to the amount of the check.

  2. Insolvency caseworkers must resolve errors on the Unpostable Payment Report prior to forwarding vouchers for processing. See IRM 21.1.7.10.4, Centralized Insolvency Operation (CIO) Payment Processing.

Terms/Definitions/Acronyms

  1. A glossary of terms used by Insolvency can be found in Exhibit 5.9.1-1, Glossary of Common Insolvency Terms.

  2. Common acronyms acceptable are listed in Exhibit 5.9.1-2, Acronyms and Abbreviations.

  3. Acronyms used locally in this IRM section are shown in the table below.

    Acronym Definition
    BizOb Business Objects
    CPM Confirmed Plan Monitoring
    DPC Designated Payment Code
    EFTPS Electronic Federal Tax Payment System
    GII Generalized IDRS Interface
    NDC National Data Center
    POC Proof of Claim
  4. Additional acceptable acronyms and abbreviations are found in the ReferenceNet Acronym Database.

Related Resources

  1. Document 13219, Automated Insolvency System - User Guide.

  2. Title 11 of the United States Code, 11 USC, known as the Bankruptcy Code.

  3. IRM 3.8.44, Campus Deposit Activity.

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

    P.O. Box Street Mailing Address
    P.O. Box 7317
    Philadelphia, PA 19101-7317
    Internal Revenue Service
    Mail Stop 5-Q30-133
    2970 Market St.
    Philadelphia, PA 19104-5016
    Attention: Payment Team
  2. Chapters 11,12, and 15. Payments for Chapter 11, 12, and 15 should be sent to the local FI office 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.

Applying Payments in Bankruptcy

  1. Automated Insolvency System (AIS) Processing. AIS processing is available for most bankruptcy and bankruptcy-related payments. Step-by-step instructions for posting payments are provided in this IRM section. Payment posting vouchers are prepared by FI and routed with the accompanying payments 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 designated payment code (DPC) other than 03 or 11) received by the CIO will be processed by the CIO. CIO will route the payment posting voucher(s) and the accompanying payment(s) to the Philadelphia Campus Support function for posting. IRM 3.8.45.4.3, Remittance Not Payable to United States Treasury, outlines acceptable payee names.

    Note:

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

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

    1. First to earliest assessed secured liabilities;

    2. Then to earliest assessed unsecured priority; and

    3. Lastly, to the claim's earliest assessed unsecured general class.
      See Exhibit 5.9.15-4, AIS Automatic Allocation, for details of automatic allocation.

  3. Dischargeable Liabilities. While payments should usually be applied to the earliest assessment, in some cases it may be in the government's best interest to apply the payment first to the later dischargeable assessments if earlier assessments are non-dischargeable. Payments should be applied to dischargeable liabilities in the same manner as above (earliest assessments first).

    Note:

    If a dischargeable liability has been adjusted at the time the payment is received, the Insolvency caseworker in receipt of the payment, 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.

  4. 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.15, Partially Designated, Semi Automatic, and Manual Payments.)

  5. Individual MFT 35 Liabilities. Beginning in 2015, individuals may be assessed a Shared Responsibility Payment (SRP), under MFT 35. Any payments resulting from lien, levy, or seizure action cannot be applied to the SRP.

  6. Employer MFT 43 Liabilities. With enforcement beginning in 2017, employers may be assessed an Employer Shared Responsibility Payment (ESRP), under MFT 43. Any payments resulting from lien, levy or seizure action can be applied to the ESRP.

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

MFT 31/65 Payments

  1. MFT 31/65 Payment and Credit Applications. Once MFT 31/65 mirror modules have been created, both modules carry a TC 971 AC 110 which causes certain payments and credits to systemically cross-reference from one MFT 31/65 mirrored module to the other. When a credit is posted to one module, IMF will cross reference the related module with TC 290 for .00 and TC 766 ref # 337. This credit will reduce the unpaid balance on the module. The credit is a nonrefundable credit.

    The credits that will systemically 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 IMF 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/65 Credits. Credits with a DPC 31 on an MFT 31/65 mirror module will not cross-reference to the spouse's MFT 31/65 module.

    Note:

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

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 (POC) to protect the government's interests. (See IRM 5.9.13.18.1, Unassessed Claims.) The trustee sends payments to the IRS on the proposed liability based on the Service's claim when:

    1. The debtor has failed to file a tax return, or

    2. An assessment based on an unfiled return is present, or

    3. 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 a proposed assessment is present; or

    2. There is an open Examination or Automated Under Reporter (AUR) indicator for the unassessed claim; or

    3. Examination or AUR does not pursue the assessment of a proposed deficiency, but other balance due periods exist.

  3. Assessment Proposed or No Return Filed. In situations where the Service has an estimated POC because a proposed assessment is present, or the debtor has not filed an original return, the Service may apply the payment(s) to other tax periods with balances due, provided they are of the same claim type (secured, priority, or general). If there are no other balances due of the same claim type, the payment should be deposited to the Unidentified Remittance File (URF) or Excess Collections File (XSF). See IRM 5.9.15.3.2 (5) below.

  4. Open Exam or AUR Indicators. In situations where the Service has an estimated proof of claim and:

    • There is an open Examination or AUR indicator, follow the guidance in IRM 5.9.18.3(2), Caseworker Actions, and IRM 5.9.18.7(2), Initial Credit Balance and Unresolved Credit Balance.

    • An Examination or AUR assessment will not be pursued, the Service may apply the payment(s) to other tax periods with balances due of the same claim type, if they exist, with any remaining balance refunded to the trustee.

    • A proposed deficiency assessment is rescinded because the debtor has provided adequate documentation to Examination, the Service may apply the payment(s) to other tax periods with balances due of the same claim type, if they exist, with any remaining balance refunded to the trustee.

  5. Deposit to Unidentified Remittance File (URF) or Excess Collections File (XSF). If the Service's rights to payment retention apply as described in 5.9.15.3.2(3) above, the payment(s) should be deposited by the Service, posted through AIS, and credited to either the (URF or XSF. The determining factor is the age of the payment.

  6. URF Guidelines. If the IRS received date of the credit is less than one year from the date the caseworker prepares the Form 2424, Account Adjustment Voucher, use of the Fill Forms IAT Tool, will assist the caseworker with completing the form and ensure accuracy, the payment will be deposited to URF by the Accounting Function.

    Note:

    Form 2424, debit processing may take three to six weeks for removal of the credit from Masterfile. DO NOT RESUBMITForm 2424 to URF until 30 days from the original submission to allow the debit to post.

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

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

    • A TXMODA/IMFOLT/BMFOLT screen print showing the availability in the Masterfile and Service Center balance, payment and payment date of the credit to be transferred to URF must be attached to Form 2424,,Account Adjustment Voucher.

    • The form must be annotated, "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.

     

  7. XSF Guidelines. If the IRS received date of the credit is one year or more from the date the caseworker prepares the Form 8758, Excess Collections File Addition use of the Fill Forms IAT Tool will assist the caseworker with completing the form and ensure accuracy, the payment will be deposited to XSF by the Accounting Function.

    • Form 8758 must be completed to move the credit to XSF.

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

    • The form must 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 the taxpayer is required" , so the Service will not try to contact the debtor.

    • A TXMODA/IMFOLT/BMFOLT screen print showing the availability in the Masterfile and Service Center balance, payment and payment date of the credit to be transferred to XSF must be attached to Form 8758. See IRM 21.2.4.3.10.1, Excess Collection File (XSF) for AMRH.

  8. Credit Resolution. When an unresolved credit appears on a tax module for a bankruptcy account, Insolvency caseworkers 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.

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, neither the AIS claim screen nor the plan payment screen is loaded before payments are received by CIO Payment Posting Team. The following steps explain the actions necessary to post payments on these claims. See IRM 5.9.13.3(2), Claims filed on Behalf of IRS.

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

      Note:

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

    2. The Payment Posting Team must advise the assigned FI caseworker of the payment so a claim can be prepared and filed by the IRS.

    3. Regardless of whether the FI 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 a plan payment screen has not been updated by FI by the time a second payment is received, the CIO caseworker 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 to identify this as a claim filed on behalf of the Service.

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. This message does not indicate the IDRS balance due has been overpaid. Overpayments cannot always be identified by AIS. 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.

    Note:

    The overpayment is payable to the debtor and sent in care of 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 marked "VOID" and returned to the trustee accompanied by Form 3699, Return Documents to Taxpayer, explaining the reason the check is 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 non-plan screen and the overpayment monitored to refund 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 Team 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, is the responsibility of the applicable FI 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, FI 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 and requires a manual refund be sent payable to the debtor and in care of the trustee. The caseworker should compare the AIS claim screen to the AIS plan screen. 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 post-petition accrued interest is allowed on the Service's claim;

    6. Research for duplicate check posting;

    7. Research PACER for a claim filed on behalf of the IRS (See IRM 5.9.15.3.3,Payments on Claims Filed on Behalf of IRS); and/or

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

    Caution:

    The "Overpaid 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 FI group to update the plan screen. FI 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. Loading General Unsecured Plans. Unsecured general plans must be loaded for the full amount of the unsecured general liability, not just the dollar amount provided in the plan. This will prevent trustee overpayment errors resulting from estates that generate more money than expected. If the Payment Posting Team identifies a case where the unsecured general plan is not loaded correctly, the caseworker should update the plan for the full amount of the unsecured general liability and continue processing the check.

  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:

    In some instances, BAPCPA allows accrued interest to be paid on priority as well as secured claims. In addition, some plans are providing for accrued interest to be paid on unsecured general claims. The actions provided in this paragraph apply to any claim designation where accrued interest will be collected.


    The AIS master plan screen should indicate if the plan detail screen was loaded correctly to allow for accrued interest as either "Simple" , "IDRS Compounded" , or "Daily Compounded" . If the debtor's plan provides for interest, an interest rate should appear in the "Optional" interest field to indicate the interest rate the trustee is paying on the secured claim. An interest amount should appear in the "13 Priority" field if the Chapter 13 plan provides for interest on the Service's priority claim. If the "Optional" and "13 Priority" interest fields are blank and a potential trustee overpayment has been identified, the caseworker should check the AIS history for documentation indicating any interest amounts being paid. If none is found, the case must be transferred to the appropriate FI office for further research and follow-up actions.

    Note:

    Interest on unsecured general periods will not be calculated on AIS. Refer to IRM 5.9.15.4 (1), Excess Interest, for TC 340 information.

  6. Duplicate Posting. Sometimes, 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 posting 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.

    Step Actions
    1 Access the case on AIS. (See IRM Exhibit 5.9.11-1, Accessing a Case on AIS, steps 1 through 4.)
    2 Click on the "CPM" tab.
    3 From the Plan Screen, select the "Payment Record" tab.
    4 View the Payment Record report that appears on the screen or print a copy of the report to identify duplicate payments.
    5 Analyze the 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, versus check 0831115).

    Note:

    If a duplicate posting is for a check processed by FI, the case must be referred to the appropriate FI group for correction.

    Reminder:

    Payments posted in duplicate are nonrefundable.

  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 IRM 5.9.15.18 , Removing Non Plan Payments. The caseworker who copies a payment from the non plan screen onto 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 Taxpayer Screen, query the docket number in question.

    2. When the case is accessed, select the "Proof of Claim" folder from the Taxpayer Screen.

    3. To determine if more than one type of claim has been filed, click on "Next" on the navigation tool bar at the top of the proof of claim screen. If there is only one type of claim present, a message stating "End of List" will pop up. The claim will be identified by Form Type "Regular" , "Administrative," or "Probate" .

    4. If two types of claim are present, one for a "Regular" claim and one for an "Administrative" claim, determine which plan has a remaining balance due. From the Proof Screen for the "Regular" form type, select the "CPM" tab and view the balance of the plan in the "Plan Totals" field on the Plan Screen. Repeat the process for the "Administrative" claim type.

    5. If the balance is on the administrative plan, from the Taxpayer Screen, select "Payments" from the "Misc Options" menu. The Payment Monitoring Menu will appear.

    6. Select "Post Automatic Payments" on the Payment Monitoring Menu.

    7. Add the case number to the "AIS Case #" or "Court Case #" field and click on the "Load" button. The taxpayer information will populate.

    8. Complete the fields for the date received, check #, amount, and select the radio button for "Administrative" .

    9. Click on the "Save" button. Record is saved.

    10. Select "Exit" to return to the Payment Monitoring Menu.

    11. When all payments have been added, allocate payments by selecting the "Allocate (User's Name) Payments" button.

    12. If the confirmed plan is full paid, enter the current date in the closed plan date field.

    If only the original regular claim exists on the Proof 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 of the court's electronic records ( 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.3.4, Surplus Payments from Trustee. Overpayments identified on bulk checks should be posted on periods found on the plan. (See IRM 5.9.15.7, Proper Application of Payments.) To view the plan periods, the caseworker should follow the steps in Exhibit 5.9.15-2, Accessing the AIS Claim Screen. 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 (cc) 60 or 61 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 might have to be refunded payable to the debtor and sent in care of the trustee. CIO caseworkers must complete a "Monitoring for Payment Posting" follow up sheet and place 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 caseworker 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. The caseworker should review IDRS and input a TC 571 if required. Once the dismissal is processed and the bankruptcy freeze is released, any credit balance remaining will systemically offset to any debit modules or be systemically refunded to the debtor. .

  12. Recomputing the Plan. After all payments which were refunded have been reversed, the plan must be recomputed. See Exhibit 5.9.15-3, Plan Recomputation, for step-by-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.

    Note:

    The payment is refunded payable to the debtor in care of the trustee.

  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.

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. (See IRM 5.9.17.3, Time Frames for Required Actions.) However, in cases where trustees send the 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, Closing Corporate Chapter 7 and Chapter 7 Limited Liability Companies (LLCs), gives instructions on how to process corporate Chapter 7 Asset cases. 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(5), Asset Discharge for Individual Debtor, for procedures for processing final distributions to non-corporate Chapter 7 cases.

Payments Resulting from Litigation

  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 trustee or debtor-in-possession 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. The amount received in the settlement should be posted through the debtor's account on AIS, so Insolvency can receive the credit for collecting the funds.

  2. Restitution Assessments. A taxpayer who has been ordered to pay restitution as a result of conviction for a tax related offense may file bankruptcy. Payments made pursuant to a plan for restitution must be applied to the restitution assessment. If it is necessary to determine how any restitution-designated payment(s) received in bankruptcy should be applied, the Insolvency caseworker should contact the assigned Advisor for guidance.

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.

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 post-petition during the normal operation of the business may be entitled to administrative expense status.

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 result in a credit balance on the account. 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 assessment, in the same amount as the excess interest payment. (See IRM 5.9.15.3.4, Surplus Payments from Trustee.)

  2. Post BAPCPA Interest. The Bankruptcy Abuse Prevention and Consumer Protection Act of 2005 (BAPCPA) amends 11 USC § 511(a) to establish a uniform interest rate on Chapter 11, 12, and 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. Post-Petition Interest. For cases filed on or after October 17, 2005, 11 USC §§ 1222(b)(11) and 1322(b)(10) specifically allow post-petition 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).

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

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, so payments are held 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 Taxpayer Delinquency Investigation (TDI), Insolvency Interface Program (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. CC REQ77 is used for this action. Use Form 3177, Notice of Action for Entry on Master File.

      Example:

      The entity was established on master file in 2009 and the estimated period is for 201112.

    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 IRM Exhibit 2.4.9-2, Command Code ENREQ.) Field Insolvency will prepare Form 2363, Master File Entity Change, 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 2011 and the estimated period is for 200912.

      Reminder:

      This request usually takes three to four cycles to post.


      Once the entity establishment date has been changed, the caseworker must create a dummy module by using CC REQ77 to input TC 520 cc 61 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 IRM Exhibit 2.4.9-2, Command Code ENREQ.) FI must prepare Form 2363 directing CCP to establish the entity on master file for cases in their inventory. Once the entity has been established, the FI caseworker must create a dummy module by using CC REQ77 to input TC 520 cc 61 for the estimated period.

    Note:

    When ENMOD updates and a new module is created with the input of TC 520 through CC 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. FI must ensure TC 520s with appropriate closing codes are entered on all tax modules for which unassessed claims are filed, and

    2. FI caseworkers must establish the module on IDRS prior to receipt of the first payment to allow the CIO Payment Processing Team to post the payment on AIS automatically, avoiding the need for manual application.

    Note:

    When IIP inputs the statistical indicator on a proof of claim period identified as unassessed due to certain proof of claim statements, a TC 520 cc 60 or 61 is systemically input to freeze pre-petition credits from systemically refunding to the taxpayer.

  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:

    • Reopen the case, if the case was previously closed;

    • Input a TC 520 on pre-petition periods;

    • Request input of a TC 570 when posting a payment;

    • Post the payment as non-plan; and

    • Refer the case to FI via e-mail or case reassignment for correction.

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.

    Note:

    CIO posts payments in accordance to the governments best interest.

  2. Avoiding Improper Application. Payments received from the bankruptcy for pre-petition 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, post-petition penalty). BAPCPA adds 11 USC § 524(i), stating that 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, 11 USC § 524(i) does not apply.

Campus Support Error Reports

  1. GII (Generalized IDRS Interface) Tool. CIO caseworkers must use the GII Name Control/Tax Period Validation Tool in order to resolve posting errors prior to submitting the Trustee Plan Payment Log to Campus Support for posting to IDRS. CIO caseworkers must follow the chart below in order to resolve GII Tool errors.

    Note:

    See your Technical Lead for instructions on GII Tool processing.

  2. Correcting Payment Posting Errors. Using payment posting vouchers generated by AIS or the Trustee Plan Payment Log, the IRS Campus Support function posts payments processed by the CIO 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 caseworkers 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 non-debtor spouse TIN 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.

    • Correct the AIS plan screen to show the correct MFT and the debtor's TIN.
    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 FI 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 CC ENREQ, 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 the Exhibit in IRM 2.4.9-10, IMF - Establishment of an Account on the Master File, for additional information.
    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 cc 61 through REQ77.
    the case does not have a confirmed plan loaded, the CIO will transfer the case to FI to input a confirmed plan on the plan payment screen. See Exhibit 5.9.15-1, Posting Non Plan Payments, for additional information relating to posting payments to a case with no confirmed plan present on AIS.
    Note: This includes when a claim has been filed by the debtor or trustee on behalf of the Service.
    Campus Support posts the payment to a pre-petition period, the Payment Posting unit will leave the payment where it has been posted.
    Note: Payments incorrectly posted to pre-petition periods will be worked by exception. Incorrectly posted payments resulting from Field Insolvency errors in loading the plan will be corrected by the appropriate Field Insolvency office.
    Example: Payments will be moved to comply with the plan if the debtor needs exact payoff amount for lien release.
    Campus Support posts the payment to a post-petition period, the Payment Posting Unit will move the payment to comply with the plan.

    Reminder:

    The AIS history must be updated to reflect any corrective actions.

Multiple Refunds

  1. Caseworker Actions. Cases may be identified where more than one systemic refund (TC 846) LTS appears on a specific module. See IRM 5.9.16.2.4, All Other . Not all cases identified are a result of bankruptcy or bankruptcy processes. The caseworker must first determine if bankruptcy is a factor in the issuance of multiple refunds.

    IF... THEN...
    the refund is on a TIN and is not the result of bankruptcy actions , advise the initiator of the notification that bankruptcy is not a factor in the issuance of the refunds.
    the refund is due to payments received in violation of the stay, not previously refunded to the debtor and trustee payments (DPC 03), CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.

    FI Action:
    • Compute the dollar amount of the systemic refunds and deduct the amount from the total of the payments received in violation of the stay.

    • If the dollar amount of the payments received is greater than the amount of the systemic refund, prepare a manual refund for the difference to go to the debtor.

    • Document actions.


    Note: The dollar amount of the systemic refunds should not exceed the dollar amount of the payments received in violation of the stay. If it does, a secondary reason exists for the multiple systemic refunds.
    the refund is due to an adjustment of the balance due or payments received from a non-debtor source and result from trustee payments (DPC 03), CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.


    FI Action:
    • Prepare an Amended claim.

    • Update the CPM Screen.

    • Document actions.

    the refund is due to a claim filed on behalf of IRS by debtor or trustee that exceeds the true balance due or an estimated claim filed by the Service that exceeds the balance due of a return subsequently filed by the debtor, and the refunds result from trustee payments (DPC 03), CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.

    FI Action:
    • Prepare an Amended claim.

    • Update the CPM Screen.

    • Document actions.

    the refund is due to trustee error and result from trustee payments (DPC 03),
    Example: IRS filed an amended claim but the trustee is still paying on the original claim.
    CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.

    FI Action:
    • Prepare an Amended claim.

    • Update the CPM Screen.

    • Document actions.

    the refund isd due to a joint liability and both taxpayers filed individual bankruptcies CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.

    FI Action:
    • Prepare an Amended claim.

    • Update the CPM Screen.

    • Document actions.

    the trustee is paying on the original IRS claim and payments refund in error due to the TC 520 closing code, CIO Action:
    • Input TC 520 cc 81.

    • Update the freeze screen.

    • Reassign the case to FI.

    • Document actions.

    FI Action:
    • Prepare an Amended claim.

    • Update the CPM Screen.

    • Follow erroneous refund procedures see IRM 21.4.5, Erroneous Refunds.

    • Document actions.

Balancing Payments

  1. Discrepancies.Payment amounts and posting vouchers or the trustee plan payment log must balance exactly to the amount of the check. Discrepancies discovered after payments have been received by Insolvency must be handled and resolved by Insolvency.

  2. Insolvency Responsibility. Prior to forwarding bankruptcy payments and vouchers or the trustee plan payment log to remittance processing, Insolvency employees must be precise in preparing checks for final posting. When they leave Insolvency, all payments must be ready for immediate processing and, if appropriate, immediate deposit by the Service.

Time Frames for Processing of Payments

  1. Field Processing of Payments. Insolvency payments must be processed timely and efficiently under strict time frames. Field Insolvency payments and related documents, such as tax returns, must be prepared for shipment to the processing Campus site by close of business on the date of receipt from the debtor, or as soon as possible the next business day.

  2. Campus Processing of Payments. Because bulk trustee checks are deposited upon receipt, the CIO has up to 10 business days to post payments on bulk checks and forward the vouchers to the Campus Support unit. Individual checks must be processed within 48 hours.

Chapter 7 Asset Trustee Checks

  1. Chapter 7 Asset Checks. The Chapter 7 trustee sends payments based on properly filed proofs of claim after the trustee liquidates the debtor's assets. Some claimants may not receive a distribution in a Chapter 7 Asset filing. IRM 5.9.17.9(5), Asset Discharge for Individual Debtor, gives instructions for handling individual Chapter 7 Asset cases while awaiting distribution, and IRM 5.9.17.11, Closing Corporate Chapter 7 and Chapter 7 Limited Liability Companies, explains approved procedures for corporate cases in 7 Asset proceedings.

  2. Payment Application. When the distribution payment from the Chapter 7 trustee is received, the payment is applied based on the trustee's instructions, or:

    IF... THEN...
    the trustee does not specify how the payment is to be applied, follow IRM 5.9.15.3 (2),Bankruptcy - Involuntary Payments.
    the liability has been adjusted, follow IRM 5.9.15.3 (3),Dischargeable Liabilities.

    Once the tax period has been identified, the caseworker should follow the posting procedures in IRM 5.9.15.15.5, Non-Plan Payments. Voucher(s) and check(s) must be sent to the Campus Support function.

Payment Posting Responsibility

  1. Field Payments. AIS systemically inputs the office address of the assigned Insolvency caseworker in the proof of claim box directing where payments for Chapter 11 and Chapter 12 plans should be mailed. If FI caseworkers find Chapter 11 or 12 payments for their cases are being mailed to the CIO, they should contact the payor and ask that future payments be sent directly to them and not to the CIO.

  2. CIO Actions. Centralized Insolvency Operation must process all bankruptcy checks received at the Campus regardless of which Insolvency function is assigned the case, FI or CIO. When a Chapter 7, Chapter 11, or Chapter 12 check is processed for a case assigned to Field Insolvency, the CIO caseworker must advise the FI caseworker assigned the account of the payment receipt by fax, phone, or secure e-mail.

Chapter 13 Trustee Payments

  1. Bulk Checks. These trustee payments, usually dispersed monthly, cover multiple debtors with one check. The dollar amounts and frequency of payments are based on the Service's proofs of claim and provisions in the confirmed Chapter 13 plans.

  2. Individual Checks. Some trustees send individual checks, meaning one check for one debtor. Or, a trustee may have neglected to include a debtor's plan payment on a bulk check, so a supplemental check is remitted as an individual check.

  3. The different posting methods on AIS for Chapter 13 payments are:

    • Automatic

    • Semi-Automatic

    • Partial Designated

    • Manual

    • Non-plan

    See IRM 5.9.15.15, Payment Posting Steps, for instructions on posting methods.

Processing CIO Payments in the Mail Room

  1. Embedded CIO Caseworkers. CIO caseworkers are embedded in the Campus Support mail room to review Insolvency remittance mail and separate single payments from bulk payments.

  2. Electronic Federal Tax Payment System (EFTPS). Funds are transmitted to the Service by the Chapter 13 trustees through a high speed internet connection. The information is downloaded to AIS to create posting vouchers, see IRM 21.1.7.10.4.4, Insolvency Payment Processing with Front End Electronic Federal Tax Payment System (EFTPS).

  3. Paper Check Conversion (PCC). The trustee submits one check for multiple taxpayers and funds are deposited to a suspense account. Payment vouchers are created on AIS and credited to a taxpayer's account on IDRS. Funds are then moved from the suspense account to proper Treasury accounts, see IRM 21.1.7.10.4.2, Processing Insolvency Payment via Paper Check Conversion (PCC).

  4. Single Payments. Payments with one check for one debtor must be posted on AIS without leaving the mail room. Caseworkers scan the trustee checks through the paper check conversion (PCC) system that enters an electronic deposit into Treasury's account. They then load the payments on AIS and generate payment vouchers for processing. The voucher(s) for the one check must add up to the total amount of the check. Checks and vouchers are batched in packets of up to 20 payments to be handed off to the Campus Support unit on an hourly basis for paper check conversion and posting onto IDRS. IRM 5.9.15.15.3, Posting Individual Trustee Checks, gives step-by-step instructions for posting individual checks on AIS.

  5. Multiple Payments. When a Chapter 13 trustee submits one check for multiple debtors, the payments are generally submitted through EFTPS or PCC. After payments from the trustee checks are loaded to AIS, the CIO caseworker generates the Trustee Plan Payment Log. This log is used in lieu of payment posting vouchers. This eliminates the need for CIO employees to batch payments and manually balance the vouchers. The steps in this process are as follows:

    1. Payments from the trustee check are systemically or manually loaded to AIS.

    2. The caseworker generates the " Eureka" or Business Objects (BizOb) report titled Trustee Plan Payment Log.

    3. The caseworker generates the "Eureka" or BizOb report titled Non Plan Payment Log, if applicable.

    4. Process the report through the GII Name Control Tool to resolve errors prior to submitting to Campus Support.

    5. The caseworker prints and saves the Trustee Plan Payment Log.

    6. If the total of the check matches the total on the Trustee Plan Payment Log, a copy of the check is placed with the report and forwarded to Campus Support.

    7. The saved log is forwarded to Campus Support via secure e-mail to ⋆W&I PCC OTC TOOL.

    8. If the totals do not match, the employee must match entries on the report with the voucher listing submitted by the trustee to resolve the error.

    9. Once errors are resolved, the report is corrected and the check is forwarded to Campus Support.

    Note:

    For additional information on the methods used by the CIO to process checks, see IRM 21.1.7.5.6, Centralized Insolvency Operation (CIO) Payment Processing.

Receipt of Bulk Payments

  1. Deposit Ticket. Payments covering multiple debtors will be routed via Form 3210, Document Transmittal, to Campus Support. The Campus Support unit will prepare a deposit ticket containing all payments to go into that day's deposit to Insolvency Suspense Account 4625. Form 784, Recapitulation of Remittances, will list each individual check.

  2. Distribution Copies. The deposit clerk will make copies of the deposit ticket, Form 784, and copies of the check for Insolvency, Accounting, and for the file.

  3. CIO Pick Up. Insolvency caseworkers will pick up a copy of the deposit ticket, bulk trustee check, Form 784, and the paper listing or disk, at least once daily.

Payment Posting Steps

  1. Bankruptcy Payments and AIS. As previously noted in this IRM section, AIS is capable of processing bankruptcy payments through several methods. This subsection deals with differing check scenarios and the proper handling and posting of those payments.

Trustee Checks with Paper Rosters

  1. Bulk Checks . Trustees may send payment rosters for bulk checks as a hardcopy listing of debtors and payment amounts. These payments must be individually added to the AIS payment posting screen. To do so, the CIO caseworker must take the following steps:

    1. Select the "Payments" tab from the AIS home page.

    2. Select "Post Automatic Payments" from the Payment Monitoring Menu.

    3. Click on the "Insert" button on the tool bar and input the docket number in the "AIS Case #" field or input the "Court Case #" .

    4. Select the "Load" button to populate debtor information.

    5. Verify that the case that has been loaded is for the correct debtor.

    6. Complete the required information in the "Payment" field:
      • The "Date Received"
      • The "Check #"
      • The "Amount"
      • The "Plan Type" (Select the appropriate radio button.)
      • The "TRC" (transaction code)

    7. Select the "Save" button on the tool bar.

    8. If the payment has been successfully saved, "Record Saved" will appear in the bottom left hand corner of the screen.

    9. If the payment was not successfully saved, error messages will appear in the bottom left hand corner of the screen. Resolve the error(s) using the information in the following table:

      IF an error message appears stating.... THEN...
      "No Confirmed Plan" Determine if another kind of plan exists (Administrative or Probate). If so, apply the payment to that plan by selecting the respective radio button for the plan type. If no plan exists:
      1. Determine the most appropriate tax period to credit following the posting priority listed in IRM 5.9.15.3, Applying Payments in Bankruptcy;

      2. Post the payment on the non plan screen using the directions in Exhibit 5.9.15-1, Posting Non Plan Payments;

      3. Update the AIS history; and

      4. Send a secure e-mail to the Field liaison to update the "CPM" Screen on the debtor's case.

      "Case/Plan Closed"
      1. Reopen the case and/or the plan;

      2. Apply the payment using steps 2 through 7 above;

      3. Determine if the case and/or plan is truly closed;

        • If so, close the case/plan on AIS.

        • If not, leave the case/plan open.

      "No Confirmation Date"
      1. Input the petition date in the "Confirmed" field on the Taxpayer Screen; and

      2. Post the payment following steps 2 through 7 in IRM 5.9.15.15.1 (1) above.

    10. Once all errors have been resolved and corrections saved successfully, continue posting the payments for the remaining cases listed on the check.

    11. Repeat steps 2 through 7 to post more than one payment, before selecting the "Save" button.

    12. Continue until every docket number and payment amount has been added.

      Note:

      Striking keyboard keys "Shift" and "f5" simultaneously in the date and check number fields will repeat the information in the previous entry.

    13. Follow the steps inExhibit 5.9.15-4, AIS Automatic Allocation, to allocate payments.

Trustee checks via download from National Data Center (NDC)

  1. Trustees submitting bulk payments can provide rosters listing debtors and payment data via the National Data Center (NDC). Special access is required and is granted by the Payment Posting Manager. To upload the information take the following steps:

    1. Access NDC.org via the internet NDC.org

    2. Logon using your user name (SEID) and password

    3. Access "vouchers" on the tool bar

    4. Locate the name of the Trustee using the drop menu

    5. Input the check number, the check will show at the bottom of the page

    6. Select Download

    7. Select Open file

    8. Save the file to "My documents" or a secure folder on your desktop

    9. On AIS, under "Misc Options" select "Payments"

    10. Select "Trustee Download Options"

    11. Select "Load Payment File"

    12. Select "Upload Trustee File"

    13. Locate the Trustee file saved ( select "browse" go to my documents or the secure folder on your desktop) and select "Send"

    14. Return to AIS and select "Refresh list"

    15. Select the list

    16. Update the IRS Received date

    17. Select "Save Payments."

Posting Individual Trustee Checks

  1. Single Checks. Some Chapter 13 trustees send an individual check for each debtor. Chapter 7, 11, and 12 bankruptcy payments are always received as individual checks. When individual checks are received at the CIO, they are input by Insolvency caseworkers embedded in the mail room. (See IRM 5.9.15.13, Processing CIO Payments in the Mail Room.) If a single check is received for an individual debtor, the caseworker must take the following steps:

    1. Select the "Payments" tab from the "Misc Options" menu on the AIS main screen.

    2. Select "Post Automatic Payments" from the Payment Monitoring Menu.

    3. Select the "Insert" tab on the AIS tool bar and input the docket number in the "AIS Case #" field, or input the "Court Case #" .

    4. Click on the "Load" button to download the debtor information.

    5. Verify the account accessed on AIS is for the correct debtor.

    6. Enter the "Date Received" , "Check #" , "Amount" , "Plan Type" (select the appropriate radio button), and "TRC" (transaction code) in the Payment Information area.

    7. Select "Save" on the AIS tool bar to save the payment. If the payment has been saved successfully, "Record Saved" will appear in the bottom left hand corner of the screen.

      Note:

      If the payment does not successfully save, an error message will appear at the bottom of the screen. To resolve common error messages, follow the guidance in the If/Then table in IRM 5.9.15.15.1 (1).

    8. Continue this process until each individual check has been added.

    9. Allocate payments by following the procedures in Exhibit 5.9.15-4, AIS Automatic Allocation.

Partially Designated, Semi Automatic and Manual Payments

  1. Partially Designated Payments. The Partially Designated Payment option is normally used in Chapter 11 cases when the payment is to be applied to:

    1. Non-trust fund taxes;

    2. Trust fund taxes; or

    3. Accrued interest.

  2. Semi Automatic Payments. The Semi Automatic Payment option can be used on any type of bankruptcy case when the payment has been designated for application according to the claim classification, such as a designated payment to a secured claim.

  3. Manual Payments. Payments requiring manual posting are usually Chapter 13 remittances designated for trust fund taxes. A shortcut exists for posting these payments. See paragraph 5 below for procedures.

  4. Posting Steps. To post partially designated payments, manual payments, and semi automatic payments, take the following actions:

    1. From the Taxpayer Screen, select the "CPM" tab.

    2. Click on the "Post Payment(s)" tab on the Plan Screen.

    3. Select the "Insert" option on "Post Payments" pop-up screen.

    4. Select the payment type "Semi Automatic" , "Partial Designated" , or "Manual" by clicking the radio button for the payment type.

    5. Complete the "Payment Data" information including the following:
      • Date (date payment received by the Service)
      • Amount (the amount to be posted)
      • Check #
      • TRC (payment transaction code selected from the drop down list)

    6. For semi automatic and manual claims only, select the "Claim Code" from the drop down menu to select "General" , "Priority" , "Secured" , "Over Secured" or "Manual" claim type.

    7. For partial and manual payments only, fill in the following fields as appropriate:
      • Non-Trust Fund
      • Trust Fund
      • Pre-Petition Penalty
      • Pre-Petition Interest
      • Post-Petition Penalty
      • Accrued Interest

    8. For manual payments only, complete the fields in the box titled "Manual Pymt Information Only" , including:
      • MFT Code
      • Tax Period
      • Assessed
      • TIN
      • Check "Designated" if the payment is designated.

    9. Once all the required information has been entered, select the "Save" button and close the screen.

    10. Return to the Payment Monitoring Menu by selecting "Payments" under the "Misc Options" menu.

    11. Select "Allocate (User's Name) Payments" to allocate the payment(s).

    12. After allocation, the system will prompt the user to print the vouchers.

  5. Manual Payment Shortcut. AIS allows the user to post manual payments simply by clicking on the "CPM" tab on the Taxpayer Screen, selecting the proper tax period from the "Tax Period" section on the Plan Screen, and selecting the "Post Manual Payment" button. The "Manual Payment" screen that appears will be partially completed. The user must complete the "Payment" and "Designated Amounts" fields as appropriate, click the "Save" button, and close the screen. Then the user will go to the payment screen and allocate the payments. After the allocation, the system will prompt the user to print the vouchers.

Non-Plan Payments

  1. Purposes of the Non-Plan Payment Feature. Non-plan payments can be submitted by an individual debtor for a Chapter 13 post-petition liability, or a Chapter 7 pre-petition, non-dischargeable liability. A non-plan payment can also be a final distribution from a Chapter 7A trustee. Occasionally, a mis-routed Chapter 11 payment must be processed through this posting option when the payment is misdirected to the CIO and must be posted, or when a posting error message appears on a Chapter 13 payment being posted by the CIO stating that the case has "No Confirmed Plan" .

  2. Chapter 11 Cases or "No Confirmed Plan" Cases. When a Chapter 11 check is received at the CIO, or when a message appears while posting a Chapter 13 payment stating "No Confirmed Plan" , the CIO caseworker should:

    1. Send a secure e-mail to the Field liaison to advise him/her of the posting problem;

    2. Determine the appropriate tax period to credit, following the posting priority described in IRM 5.9.15.3, Applying Payments in Bankruptcy;

    3. Annotate on the check that it is to be applied via the "Non-Plan Payment" screen; and

    4. Update the AIS history.

  3. Non-Plan Payment Posting Actions. To post a payment to the Non-Plan screen, take the following actions:

    1. Click on the "Post Non-Plan Payments" button on the Payment Monitoring Menu;

    2. Input the "AIS Case #" and click the "Load" button on the "Non-Plan Payment" screen;

    3. Verify the account that has been loaded is the correct case; and

    4. Complete the "Payment" fields with the following information:
      • "Date Received"
      • "Check #" (this field is optional)
      • "TRC 1" (transaction code 670 will appear systemically)
      • "Amount 1"
      • "TRC 2" (if the payment is being split)
      • "Amount 2" (if the payment is being split)
      • "Designation Code" (click on the appropriate radio button)

    5. Complete the "Period" fields with the following information, if appropriate:
      • "Tin"
      • "Name Control"
      • "MFT Code"
      • "Claim Code" (selected from the drop down list)
      • "Tax Period"
      • "Assessment" date (optional)
      • "Comments" field (optional)

    6. Select "Save" to update the payment record.

  4. Limitations of Non Plan Posting. The Non Plan Payment posting does not:

    1. Use the allocate routine;

    2. Access the plan modules;

    3. Retain totals; or

    4. Verify the TIN exists in the AIS TIN table.

Common Payment Posting Errors

  1. Correcting Errors. Some payment posting errors can be easily remedied as the payments are being posted; others require intervention from Field Insolvency. Field Insolvency has 15 business days from the date the CIO notifies them of a payment issue to correct the problem. When the CIO experiences simple posting problems, having CIO caseworkers correct the errors themselves without relying on FI caseworkers can accelerate the bulk processing of trustee payments. The following paragraphs offer instructions on resolving some posting errors.

  2. Missing Plan. This error is generated when a payment is received and one of the following conditions occurs:

    1. The plan has not been loaded.

    2. The plan has been loaded, but all periods have not been verified.

      Reminder:

      When loading confirmed plans, Field caseworkers should ensure all periods are verified.

    3. A proof of claim has not been filed by the Service, but has been filed by the debtor or trustee on behalf of the Service.

    4. A pre-petition "Regular" proof of claim has not been filed by the Service, but an "Administrative" claim has been filed by the Service under § 1305 for post-petition liabilities.

      Note:

      Proofs of Claim filed for post-petition taxes under § 1305 should generally be filed on Form B10, or the "Regular" claim (see IRM 5.9.10.9.2, 11 USC Section 1305 Claims). The liability should be added to the CPM screen as a priority tax.


      When the CIO caseworker cannot resolve the payment posting issue expeditiously, the caseworker should follow the guidance in IRM 5.9.15.15.5, Non-Plan Payments, and load the payment on the Non Plan screen.

  3. No Case Found. Querying the TIN on the AIS "TIN Screen" can sometimes identify cases marked "No Matching Records Found" on AIS. This error may result from one of the two following scenarios:

    1. A case may have erroneously been closed as no liability (NL) when a tax is owed but the balance due falls below the LEM criteria for claim filing. The Service receives payment because the debtor has filed a claim on behalf of the Service. If the case has been moved to the index for closed cases, the case should be reopened by removing the closure date from the "On AIS" field in the "Closing Info & Dates" area on the Taxpayer Screen. After the changes have been saved, the payment can be input as a non-plan payment. After the payment has been posted, the case must be transferred to the Field to add the claim information to the Plan Monitoring screen.

    2. The TIN on AIS differs from the TIN provided by the trustee. The CIO should alert the Field to call the trustee to correct the TIN in his/her database.

  4. Case Closed. Insolvency sometimes does not receive notice from the court that a dismissed case has been reinstated. If a payment is received on a case that has been closed as "dismissed" , the CIO caseworker should check the court's electronic records to determine if the bankruptcy has been reinstated. If the error states "Case Closed" , and the bankruptcy has been dismissed and not reinstated, the payment should be posted to the earliest assessed liability. If the dismissal has been vacated and the case reinstated, the case should be reopened on AIS so the payment can be posted through AIS. If the case was dismissed before the confirmation date, the case must be transferred back to the appropriate Field Insolvency caseworker to complete pre-confirmation work.

  5. Multiple Cases. Errors for multiple cases occur because the system looks for TINs instead of case numbers. Every case associated with the TIN on the payment will be identified. The error will be corrected by the CIO caseworker clicking on "Set Button#" and selecting the correct case number and appropriate radio button for the plan type:

    • Confirmed Plan Payment (Y)

    • Non-Plan Payment (M)

  6. Plan Closed. The "Plan Closed" error message is usually generated for one of the two following reasons:

    1. The case has been discharged and processed through ADS, but closure was prevented by a Discharge Determination Report (DDR) flag. The case has SUP DIS PROCSNG-SA or REG DIS PROCSNG-RA in the method of closure field on the AIS entity screen. The plan must be reopened and the payment posted. The CIO technical unit processing discharges is responsible for resolving the DDR condition if the case is assigned to it. If the case is assigned to Field Insolvency, the FI caseworker must resolve the DDR.

    2. The plans have been closed because of dismissal notice.


    When this error appears, the technician should select the "Confirmed" plan type radio button.

  7. Taxpayer Entity Record Closed. This error is identified when the AIS entity screen has "REG DIS COMPLTE-RC" or "SUP DIS COMPLTE-SC" in the "Closure Method" field and an AIS closing date.

    1. If the payment is received 30 days or less after the AIS closing date, the assumption will be made that the payment represents the final installment from the bankruptcy estate, and should be posted following instructions in Exhibit 5.9.15-5, Posting Payments on a Closed Case.

    2. If the payment is received more than 30 days after the AIS closing date, PACER research is required to determine if the case has been reopened, if the TIN or debtor name is incorrect, or if the discharge was entered on AIS erroneously. If research determines the payment should be posted, the instructions in Exhibit 5.9.15-5 should be followed. If the propriety of the payment is in question, contact with the trustee is necessary.

    3. If PACER indicates a discharge was entered on AIS in error and the case was erroneously closed, the caseworker must:
      1. Input TC 520 with the petition date;
      2. Remove the closed date on the AIS Taxpayer Screen;
      3. Remove the information in the "Closure Method" field; and
      4. Follow normal payment posting procedures.

    4. If the trustee has submitted a payment after the valid entry of a discharge, and the payment is received more than 30 days after the AIS closing date, the caseworker must remove the closed date on the AIS Taxpayer Screen and follow payment posting procedures in Exhibit 5.9.15-5 if there were dischargeable liabilities. If there were no dischargeable liabilities, follow normal payment posting procedures and close the case using the present closing date.

Resolving Payment Posting Errors

  1. Unpostable Payment Report. An error message may appear on the "Allocate" screen, or a list will appear when printing the posting vouchers. Payments that cannot be resolved by the Payment Posting Unit will be applied manually using the "Post Non Plan Payment" screen. The CIO will e-mail the Field Insolvency liaison advising them of the posting problem. A TC 570 request will be added to the posting voucher/balancing report.

  2. For All Errors Except "Admin Plan Found" . The error report identifies payments that AIS is unable to allocate to the bankruptcy plan. Payment errors listed on the Unpostable Payment Report must be corrected and reallocated.

  3. Errors. Types of errors and the function responsible for correction of Chapter 13 payments are shown in the table below. Field Insolvency is responsible for correcting all payment errors on cases other than Chapter 13.

    Error Action Function Responsible
    No Confirmed Plan CIO caseworker contacts the Field liaison by secure e-mail to advise payment has been applied as a non-plan payment. Field loads confirmed plan ensuring money is properly allocated. Actions may include but are not limited to:
    • Loading payment to the Confirmed Plan Monitoring (CPM) screen and removing it from the non plan screen.

    • Preparing credit transfer based on AIS allocation.

    Reminder:

    When loading a plan, ensure all periods are verified and any secured issues are addressed.

    Caution:

    There should be no administrative plan for a Chapter 13 case. All claims filed under USC § 1305 for post-petition taxes should be added to the CPM screen as a priority liability by selecting plan type "Confirmed" from the drop down menu.

    No Valid Case Found (when the trustee has not redacted the SSN) CIO caseworker contacts the Field liaison by secure e-mail to advise payment has been applied as a non-plan payment.
    1. Field contacts the trustee to correct the TIN in their database, and

    2. Updates the AIS history.


    Actions may include but are not limited to:
    • Loading payment to the CPM screen and removing it from the Non-Plan screen.

    • Preparing credit transfer based on AIS allocation.

    Reminder:

    When loading a plan, ensure all periods are verified and any secured issues are addressed.

    No Valid Case Found (when trustee has redacted TIN) CIO caseworkers must locate the case on AIS using the redacted SSN and case number. CIO
    Case Closed See IRM 5.9.15.16 (4), Case Closed. CIO
    Multiple Cases See IRM 5.9.15.16 (5), Multiple Cases. CIO
    Plan Closed See IRM 5.9.15.16 (6), Plan Closed. CIO
    Manually Designated-Amount too large See IRM 5.9.15.3.4, Surplus Payments from Trustee. CIO
    Partially Designated-Amount too large See IRM 5.9.15.3.4, Surplus Payments from Trustee. CIO
    Tax modules for case # plan type XX are not all verified Review the Detail Record for each tax period to ensure plan is verified. Click the "Verified Period" box to verify the period. CIO

    Note:

    CIO must advise Field Insolvency of action taken by telephone, fax or secure e-mail.

    Unable to find master record _plan type CIO caseworker contacts the Field liaison by secure e-mail to advise payment has been applied as a non-plan payment. Field Insolvency reviews the CPM screen to ensure all plans are input. Inputs any missing plan information, loads payment to the CPM screen and removes it from the Non Plan screen.
    Error in the field / Field contains invalid data Input correct data in the highlighted field CIO
    Payment date input is after today's date Correct payment date CIO
    Manual payment posting required Post manual payment CIO
    This field requires an entered value Input the appropriate data in the cursor field CIO
    Semi-Automatic payment amount too large. See IRM 5.9.15.3.4, Surplus Payments from Trustee. CIO
    Missing Confirmation date I
    1. review the Taxpayer Screen and input the confirmation date

    2. If date is not present on the Taxpayer Screen, research PACER

    3. If case is unconfirmed, input the received date of the payment as the confirmation date

    CIO
  4. Valid Payment Field. The cases on the error report will have a bullet next to the invalid payment. This bullet should appear next to the "Confirmed Plan" line or the "Manual Payment" line when the payment has posted correctly. To work the error report, the caseworker should print the "Check Summary Report" and take the following actions:

    1. On the AIS home page, select the "Payments" button.

    2. On the Payment Screen, select the "Trustee Download Options" button to access the "Trustee Payments" screen.

    3. Click on the "Query" tab from the toolbar; input the check number in the "Check Number" field; and click on the "Invalid Payment (N)" radio button found in the lower right quadrant of the screen.

    4. Clicking on the "Execute" button will display all of the corrections that need to be made. If there are multiple results returned, select the "Next" button to move through them sequentially.

      Note:

      After each correction is made, the "Save" button must be selected before going to the next error.

    5. To allocate the payments, select the "Payments" button to access the "Payment Monitoring Menu" .

    6. On the Payment Monitoring Menu, select the "Allocate (User’s Name) Payments" button.

    7. Non-plan payments must be updated with a MFT code, claim code (Oversecured, Secured, Priority, or General) and tax period. Select "Save" so the payment will allocate to the non-plan screen.


    Common unpostable conditions can be corrected by following the If/Then table below:

    If the error message is ... Then the caseworker should...
    Missing Plan Add the claim to Plan Monitoring.
    Manually Designated - Amounts too large Review the Payoff Report for correct amount and input the correct amount.
    Partially Designated payment amount too large Review the Payoff Report and input the correct amount.
    The tax modules for case # Plan type XX are not all verified Review the Detail Record for each tax period to ensure plan is verified. Select the "Verified Plan" box.
    Unable to find master record __plan type__ Review the Plan Monitoring File to ensure all plans are input. All plans must be input before payments can allocate.
    Error in field, field contains invalid data Review the invalid data in the cursor field and input the correct data.
    Payment date input isafter today's date The payment date must be prior or equal to the date of input.
    No Case Found Add the claim information to the Plan Monitoring screen.
    Manual Payment posting required Review the code input to the Payment Monitoring Screen and input the DPC.
    This field requires an entered value Review each screen field for required data and input the appropriate data in the cursor field.
    Invalid Choice Review each case number to ensure data is correct. When case numbers do not match an AIS Taxpayer Data File, input the correct case number and research for missing record if the case number is correct.
    Data doesn't match Review the Payment Monitoring Detail Record to correct payment information.
    Semi-Automatic Payment amount too large Review the Payoff Status Report and input the correct amount.
    Missing Confirmation Date Review the Taxpayer Detail File and input the confirmation date. If not present, enter the petition date.
    Missing Petition date Review the Taxpayer Screen for the petition date and input the petition date.

Dishonored Checks

  1. Prior to Posting on AIS. If Insolvency is advised a payor has stopped payment on a trustee check, or if Accounting advises Insolvency a check has been dishonored before payment has been posted to AIS, the check is not to be posted. If the payments have been posted but the vouchers have not been sent to Campus Support, the payments must be removed from the AIS payment screen and a short AIS history input.

    Example:

    The history may state, "Payment on check # XXXXX removed from plan screen due to dishonored check."

  2. After Posting on AIS. If Insolvency is advised a check has been dishonored after the payment has been posted to AIS and sent to Campus Support, the payments must be removed from the AIS payment screen and a short AIS history input. Accounting must fax the Insolvency office processing the check copies of the front and back of the dishonored check.

    Note:

    Reversed payments from third parties with a bankruptcy DPC are not assessed a dishonored check penalty. However, reversed payments from a debtor-in-possession remain subject to the dishonored check penalty.

Removing Trustee Payments

  1. Removing Plan Payments. Occasions will occur when it is necessary to delete payments from the AIS payment record, for example, in the case of dishonored checks or lost checks. When trustee payments are reversed, confirmed plan payments and non-plan payments are removed, and the trustee check record is removed. Specific payments may be reversed for an individual debtor, or all payments covered by a bulk trustee check can be reversed at one time.

    Reversing a Bulk Payment Check from AIS
    Step Action
    1 Select the "Payments" button on the AIS Home Page.
    2 From the Payment Monitoring Menu that appears, select the "Trustee Download Options" button.
    3 Complete the fields in the Trustee Check Information section of the screen and click on the "Reverse Posted Payments" button.
    4 Type "Y" (yes) to complete reversal of the trustee check.
    5 Remove the check record.
    Reversing Individual Payments from AIS
    Step Action
    1 From the Taxpayer Screen click on the CPM tab.
    2 From the Plan Screen that appears, click on the "Applied Payments" Button.
    3 Click on the "Next" button until the payment to be reversed appears.
    4 Click on the "Reverse this Payment" button.
    5 A prompt will appear asking if the user wants to continue with the reversal. Click on "Yes" .

    Note:

    The assigned Field Insolvency caseworker must recompute the plan on AIS. Recomputing the plan does not bring the overpayment amount to zero.

  2. Removing Non-Plan Payments. When trustee payments have been posted to the non-plan screen because a plan has not been loaded or has been improperly loaded, the CIO should forward the case to FI for plan correction. Upon correcting the plan screen, the FI caseworker must move the payment in question from the non-plan screen to the Confirmed Plan Monitoring screen. To prevent an overpayment error in the future, the caseworker must also delete the payment from the non-plan screen following the steps below.

    Reversing Non Plan Payments
    Step Action
    1 From the AIS Home Page, click on the "Payments" button.
    2 From the Payment Monitoring Menu, click on the "Post Non Plan Payments" button.
    3 Query the docket number to access the case in question.
    4 Select the applicable payment voucher. This can be done by querying the check number, the dollar amount or posting date.
    5 Click on the "Remove" button on the tool bar to delete the payment.
    6 Click "Save" to confirm removal of the payment.

    Note:

    The Field caseworker must then recompute the plan on AIS. (See Exhibit 5.9.15-3, Plan Recomputation.)

Non-Insolvency Checks

  1. Non-Debtor Spouse or Third Party. Checks from parties other than the trustee may be applied toward a period covered by the bankruptcy stay. A non-debtor spouse may make a payment toward a joint tax liability owed by a debtor, or a third party such as a family member may elect to help a debtor pay a tax liability. When it is evident the check is meant to be applied toward a tax debt covered by the bankruptcy proceeding, the caseworker must post the payment through AIS as designated, or if no designation is made, as is outlined in IRM 5.9.15.3 (2), Bankruptcy - Involuntary Payments.

  2. Debtor Payments. Debtors may submit voluntary payments for post-petition taxes, or in some instances, for non-dischargeable taxes, during the pendency of their bankruptcy. IRM 5.9.4.4.2, Post-Petition Payments and Credits, and 5.9.4.19,Installment Agreements and Bankruptcy, give guidance on determining when the Service is allowed to retain voluntary payments.

  3. Posting Responsibilities. Vouchers for the non-Insolvency checks discussed in paragraphs (1) and (2) above must be posted on AIS by the Insolvency function (Field or CIO) receiving the checks.

    1. CIO Processing. Payments related to accounts in bankruptcy that are not remitted by a trustee or debtor-in-possession will be loaded to the AIS Non Plan Screen and a voucher printed. AIS will only allow a DPC of "03" or "11" to be printed on the payment vouchers it generates. The caseworker must cross out the "03" and replace it with "99" . The check and the payment posting voucher will be forwarded to the Philadelphia Campus Support unit for the check to be scanned and the payment credited to the taxpayer's account on master file. An AIS history item must be created explaining the nature of the payment (e.g., "payment rcvd from NDS" or "payment rcvd for post-petition 30-2007" ).

    2. Field Insolvency Processing. Field Insolvency will load these payments to the AIS Non-Plan Screen and print a voucher. AIS will only allow a DPC of "03" or "11" to be printed on the payment vouchers it generates. The caseworker must cross out the "03" and replace it with "99" . Field Insolvency will overnight their payments and vouchers to the Campus assigned to their geographical location. An AIS history item must be created explaining the nature of the payment (e.g., "payment rcvd from NDS" or "payment rcvd for post-petition 30-2007" ).

  4. Estimated Tax Payments. Some plans include the requirement debtors make estimated tax payments on future periods so they do not continue to accrue liabilities post-petition. These payments cannot be processed through AIS. Field Insolvency must prepare Form 3244, Payment Posting Voucher, to be sent along with the payment to the appropriate Campus remittance unit by overnight delivery. Estimated tax payments received erroneously at the CIO will be scanned and loaded on IDRS by Campus Support.

    Note:

    Field Insolvency must advise debtors to send estimated tax payments to the Field Insolvency office address.

Posting Non-Plan Payments

The steps for manually inputting data for non-plan payments and payments for which an error message of "no confirmed plan" appears are as follows:

  1. Verify the debtor account showing on AIS matches the debtor name given by the trustee.

  2. Click the "Payment" button on the Taxpayer Screen. The Payment Monitoring Menu will appear.

  3. Click on the "Post Non Plan Payments" button to access the Non Plan Payment screen.

  4. Input the AIS case number and click the "Load" button immediately following the case number.

    Note:

    The AIS Case Number is a required field. If the record exists on AIS the name and address information is populated systemically, or a list of possible names will drop down so the correct case can be selected. If the account does not exist on AIS, the case must be added in order to post the payment.

  5. In the "Payment" section of the Non-Plan Payment screen, complete the fields for:

    • Payment date

    • Check number

    • Transaction code (defaults to 670)

    • Amount

    • DPC (defaults to 3)

    • TIN

    • MFT

    • Tax Period

    • Assessment date (optional)

    • Comments (optional)

  6. Click on the "Save" button.

  7. Go to the main payment menu and select "Allocate (User's Name) payments" .

  8. Select the "Print Voucher" button.

Accessing the AIS Claim Screen

To view the claim(s) filed by the Service in a particular case, the caseworker should take the following steps.

  1. From the AIS Main Screen, select "Case Files" .

  2. Select "Query" from the navigation tool bar.

  3. Enter the case number in the "AIS Case Number" field.

  4. Select "Execute" on the navigation tool bar.

  5. Click on "Next" on the tool bar until the desired case appears.

  6. Select the "Proof of Claim" folder tab and the Proof Screen will appear.

  7. From the Proof Screen select "Next" to see if there is more than one type of claim filed in a case. Claim types are:

    • Regular

    • Administrative

    • Probate

    Note:

    All claim information for a specific type of claim, such as original claims and amendments, will be with the file for the specific claim type.

  8. The original claim number and filing information will be shown in the field for the "Original" claim. The amended claim number, prepared date, and acknowledgement date for the last amended claim filed will be shown in the "Amended" field.

  9. A copy of the proof of claim can be viewed or printed by selecting "Reference Copy" or the "Previously Filed Claim" when more than one claim has been filed.

Plan Recomputation

The following steps will reallocate all payments after a payment on the AIS plan screen has been successfully reversed.

1 From the Taxpayer Screen, select the "CPM" tab.
2 Select "Next" until the plan type to be recomputed appears.
3 Verify that the tax periods included in the Plan Screen are correct by using the scroll bar in the "Tax Periods" section of the Plan Screen to view them.
4 Click on "Recompute Plan" . A pop-up warning will appear, asking if the user wishes to continue.
5 Select "Yes" to continue.
6 Choose the File Menu and select "Print Review" to view the posting vouchers for possible unpostable payments.
7 Resolve any posting errors using the instructions in IRM 5.9.15.16.1, Resolving Payment Posting Errors.
8 Print the vouchers.

Caution:

Caseworkers should take care not to confuse the "Recompute Plan" and "Reset Plan to Zero" options on AIS.
• The Recompute Plan option should be used when there are changes to the plan; e.g. the confirmation date, the plan effective date, interest options, etc. These changes impact the entire plan, so this option applies the new parameters and automatically re-allocates the payments.
• The Reset Plan to Zero option should be used when there are changes to individual periods or payments on a plan; e.g., to take out payments and apply them another way, to modify the plan by adding or deleting a tax period, to adjust tax amounts, etc.

For detailed information on these functions in AIS, see Document 13219, AIS User Guide.

Overpayments Caused by Recomputing the Plan. A mismatch or overpayment condition can exist when payments are reallocated. Plan payments may not match the reallocated payments on AIS. This can occur when a proof of claim is amended or an Administrative Claim is updated. To correct the mismatch in IDRS and AIS, take the following actions:

Step Action
1 Select a transcript of the account(s) from IDRS.
2 Print an AIS Payment Record from the "Applied Payments" button from the CPM Menu.
3 Match the two records.
4 Prepare appropriate form or input a credit transfer to move the payments on IDRS to match the payment reallocation on the Payment Record.
5 Verify both IDRS and AIS payment records match for the applicable periods.

AIS Automatic Allocation

Secured Periods. AIS payment allocation is based upon the Service's claim and how the plan screen is loaded. Beginning with the earliest assessed secured period, allocation is made by AIS in the following order: 1) non trust fund taxes, 2) trust fund taxes, 3) pre-petition interest, 4) pre-petition penalty, 5) the next oldest secured period following the order just stated, 6) then all accrued penalties for secured periods starting with the oldest period, and 7) finally all accrued interest for secured periods starting with the oldest period.

Unsecured Priority Payments. Beginning with the earliest assessed unsecured priority period, allocation is made by AIS in the following order: 1) non trust fund taxes, 2) trust fund taxes, 3) pre-petition interest, 4) the next oldest unsecured priority period, and 5) finally all accrued interest for unsecured priority periods starting with the oldest unsecured priority period.

Unsecured General Payments. Beginning with the earliest assessed unsecured general period regardless of payment date, allocation is made by AIS in the following order: 1) non trust fund taxes, 2) pre-petition interest, 3) then the next oldest period in the order just stated, and 4) all priority pre-petition penalty periods starting with the oldest period, and 5) finally all other pre-petition penalty periods, starting with the oldest period.

Posting Payments on a Closed Case

If both AIS and PACER confirm a case has been discharged, the TC 604 transaction date (23C date) governs the proper actions to be taken by the Insolvency caseworker.

IF... THEN...
the case has been closed on AIS, remove the closure date from the "On AIS" field on the Taxpayer Screen.
the payment 23C date is prior to the TC 604 23C date, IDRS will generate a systemic TC 605 allowing the caseworker to post the payment by following normal payment posting procedures.
the payment 23C date is after the TC 604 23C date, the caseworker must reverse the abatement manually on IDRS by inputting:
1) TC 520 cc 81 with the petition date;
2) TC 972 AC 031;
3) TC 971 AC 031 (3 cycle posting delay); and
4) TC 521 cc 81 (4 cycle posting delay).
Then follow normal payment posting procedures.

Note:

After the payment posts, the caseworker must input a follow-up to re-input the abatement. The case should be closed on AIS once the payment and all adjustments have posted to IDRS.