5.9.15  Payments in Bankruptcy

5.9.15.1  (04-05-2011)
Payment Addresses

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

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

5.9.15.2  (04-05-2011)
Applying Payments in Bankruptcy

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

    Note:

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

  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 (See IRM Exhibit 5.9.15-6 , AIS Automatic Allocation, for details of automatic allocation):

    1. First to liabilities listed as secured;

    2. Then to unsecured priority; and

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

    Note:

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

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

    Note:

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

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

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

5.9.15.2.1  (03-01-2006)
MFT 31 Payments

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

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

    Note:

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

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

    Note:

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

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

5.9.15.2.2  (04-05-2011)
Payments on Unfiled Returns

  1. Trustee Payments on Unfiled Returns or Unassessed Deficiencies. During a bankruptcy proceeding, the Service may file an unassessed (estimated) proof of claim to protect the government's interests. (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:

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

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

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

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

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

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

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

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

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

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

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

      Note:

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

    • Accounting will add the credit to the URF.

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


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

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

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

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

      Note:

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

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

    Note:

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

5.9.15.2.3  (04-05-2011)
Payments on Claims Filed on Behalf of IRS

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

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

      Note:

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

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

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

    4. If by the time a second payment is received, a plan payment screen has not been opened by Field Insolvency, the CIO payment technician will open a dummy plan screen using the total IDRS balance due up to the petition date for each period as the claim amount. Each period will be listed as " priority" tax. The plan payment amount will be $0.50 to identify this as a claim filed on behalf of the Service.

5.9.15.2.4  (04-05-2011)
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 necessarily indicate the IDRS balance due has been overpaid.) Overpayments cannot always be identified by AIS. Those overpayments may be identified by the DUPREF list, an IDRS report discussed later in this IRM section. ( See IRM 5.9.15.6.2, DUPREF Report) 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 returned to the trustee accompanied by IDRS letter 549C explaining the reason for the check's being returned.

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

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

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

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

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

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

    3. look for the presence of an administrative claim;

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

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

    6. research for duplicate check postings;

    7. research PACER for a claim filed on behalf of the IRS. ( See IRM 5.9.15.2.3, 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 "Over Paid Amt" field on the AIS master plan screen does not necessarily reflect the true amount of an overpayment and may require manual adjustment.

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

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

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

    Note:

    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" interest, "IDRS Compounded" interest, or "Daily Compounded" interest. 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. Interest on unsecured general periods will not be calculated on AIS. Refer to IRM 5.9.15.3(1), Excess Interest, for TC 340 information. 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 Field Insolvency office for further research and follow-up actions.

  6. Duplicate Postings. At times a trustee payment may be posted on AIS more than once. When this occurs the duplicate posting(s) must be removed so only one posting remains on the AIS system. Duplicate 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:

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

  7. Payments Posted on the Non Plan Screen. Payments that have posted to the non plan screen and subsequently moved to the plan screen must be removed from the non plan screen. Instructions for removing a payment can be found in IRM 5.9.15.17(2), 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 button" 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 on the court's electronic records (usually PACER) may be required to determine if more than one claim has been filed for the Service or if the claim filed with the court matches the dollar amount on the AIS plan screen.

  9. Posting Overpayments. Procedures for trustee overpayments received on single checks should be handled according to IRM 5.9.15.2.4 , Surplus Payments from Trustee. Overpayments identified on bulk checks should be posted on periods found on the plan. (See IRM 5.9.15.6,Proper Application of Payments.) To view the plan periods, the caseworker should follow the steps in IRM Exhibit 5.9.15-3, 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 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. An ACTON control base must be opened on the IDRS module where the overpayment will be applied so posting of the payment can be monitored when the check can not be returned to the trustee because the check lists multiple taxpayers. CIO caseworkers must complete a "Monitoring for Payment Posting " follow up sheet and attach a copy of the posting voucher indicating the overpayment amount. The sheet must be placed in the designated follow-up folder.

    Note:

    There is no need to input an ACTON to open a control base on IDRS when the overpayment issue will be resolved the same day it is identified.

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

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

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

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

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

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

    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 if the refund is not made within 45 days of receipt of the overpayment.

5.9.15.2.5  (04-05-2011)
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, Closing a Bankruptcy Case.) However, in cases where trustees send final distribution after the discharge, closing actions need not be initiated until the final payment is posted on AIS. Nonetheless a case may be closed on AIS before final distribution is received. If the case is closed on AIS and an abatement has been completed on IDRS, the abatement should be reversed, and the trustee payment(s) should be applied to the debtor's account.

  2. Chapter 7 Asset Final Distribution. Chapter 7 trustees may remit final distributions months or years after a case has closed. IRM 5.9.17.11, Closing Corporate Chapter 7 and 11 Bankruptcies and Non-Liquidating Partnerships, 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(4),Asset Discharge for Individual Debtor, for procedures for processing final distributions to non-corporate Chapter 7 cases.

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

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

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

5.9.15.2.7  (03-01-2006)
Designated Payment Code

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

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

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

5.9.15.3  (03-01-2007)
Plan Interest Rates

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

    Note:

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

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

    Note:

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

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

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

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

5.9.15.5  (04-05-2011)
Unassessed Liability/No Open Modules

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

    Example:

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

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

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

      Example:

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

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

      Example:

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

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

      Caution:

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

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

    Note:

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

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

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

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

    Note:

    When the Insolvency Interface Program (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 prepetition 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 case previously closed;

    • input a TC 520 on prepetition periods;

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

    • post the payment as non-plan; and

    • refer the case to Field Insolvency for correction.

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

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

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

    Note:

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

5.9.15.6.1  (04-05-2011)
Campus Support Error Reports

  1. 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 technicians must take the following actions to resolve posting errors identified by the Campus Support function.

    IF... THEN...
    the name control on the plan payment screen is incorrect, the CIO will update the name control on the TIN screen.
    the TIN on the plan payment screen is obviously incorrect, the CIO will
    • correct the TIN on the plan payment screen
    • add non-debtor spouse SSN on AIS entity screen if necessary
    • complete credit transfer if necessary.
    the primary taxpayer on IDRS is deceased, but the secondary taxpayer on IDRS is the debtor, and the CSED has expired, the CIO will:
    • take actions to ensure the payment is not systemically refunded
    • create an MFT 31 mirror for the account if the criteria for mirroring are met
    • remove the payment from the decedent's MFT 31 account if appropriate
    • correct the AIS plan screen to show the correct MFT and the debtor's SSN
    the tax period is obviously incorrect per IDRS,
    Example: 30 200204
    the CIO will correct the tax period on the plan payment screen.
    an unassessed period is
    • on the plan payment screen;
    • no dummy module has been created; and
    • the entity has not been established on master file,
    the CIO will transfer the case to Field Insolvency to
    • request CCP establish the entity on master file through ENREQ;
    • create a dummy module; and
    • input a confirmed plan on the plan payment screen.
    an unassessed period
    • is on the plan payment screen;
    • no dummy module has been created; and
    • the unassessed module is for a period falling prior to the establishment of an entity on master file,
    using command code 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 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 through REQ77.
    the case does not have a confirmed plan loaded, the CIO will transfer the case to Field Insolvency to input a confirmed plan on the plan payment screen. See IRM Exhibit 5.9.15-2, 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 prepetition period, the Payment Posting unit will leave the payment where it has been posted.
    Note: Payments incorrectly posted to prepetition 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 postpetition 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.

5.9.15.6.2  (04-05-2011)
DUPREF Report

  1. Multiple Refunds. The DUPREF report identifies cases where more than one systematic refund (TC 846) appears on a specific module. Not all cases on the report 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 multiple refunds on a TIN are not a result of bankruptcy actions or the bankruptcy freeze code, advise the initiator of the report that bankruptcy is not a factor in the issuance of the refunds.
    the multiple refunds on a TIN result from bankruptcy actions or the bankruptcy freeze code, determine the underlying cause of the systemic refunds:
    • Payments received in violation of the stay
    • Adjustment of balance due (TC 291, TC 301, TC 766, TC 768)
    • Payments received from non-debtor source, such as non- debtor spouse
    • Claim filed on behalf of IRS by debtor or trustee
    • Estimated claim
    • Trustee overpayments due to trustee error
    the refunds are due to payments received in violation of the stay, not previously refunded to the debtor and result from trustee payments (DPC 03), 1) compute the dollar amount of the systemic refunds and deduct that amount from the total of the payments received in violation of the stay.
    2) if the dollar amount of the payments received is greater than the amount of the systemic refunds to the debtor, prepare a manual refund for the difference to go to the debtor.
    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 refunds are due to an adjustment of the balance due or payments received from a non-debtor source and result from trustee payments (DPC 03), 1) input TC 520 cc 60 or 61 on the module to prevent further systemic refunds IRM 5.9.5.6.1(6) , "Older" Closing Codes;
    2) transfer the case to Field Insolvency to prepare an amended claim, send a credit letter to the trustee, or withdraw the claim; and
    3) send Letter 549C to the trustee explaining $X.XX has been systemically refunded to the debtor.
    the refunds are 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), 1) input TC 520 cc 60 or 61 on the module to prevent further systemic refunds ;
    2) transfer the case to Field Insolvency to prepare an amended claim, send a credit letter to the trustee, or withdraw the claim; and
    3) send Letter 549C to the trustee explaining $X.XX has been systemically refunded to the debtor .
    the refunds are due to trustee error and result from trustee payments (DPC 03),
    Example: IRS filed an amended claim. However, trustee is still paying on the original claim.
    1) input TC 520 cc 60 or 61 on the module to prevent further systemic refunds; and
    2) send Letter 549C to the trustee explaining $X.XX has been systemically refunded to the debtor.
    the trustee is paying on the original IRM claim and payments refund in error due to the TC 520 closing code, 1) input TC 520 cc 60 or 61 on the module to prevent further systemic refunds;
    2) check IDRS for current cycle pending refunds (TC 846) and intercept via NOREF if necessary; and
    3) follow erroneous refund procedures for previously issued refunds.

  2. Timeframes for Actions on the DUPREF Report. Caseworkers must acknowledge receipt of the "DUPREF Report" via Form 3210, Document Transmittal, faxed to Accounting at (859) 669-2439 within five days of receipt. The report must be worked within two days of receipt and retained for six months.

  3. TC 971 ac 663 Input to IDRS. When an employee becomes aware that an erroneous refund has been issued through the DUPREF Report or otherwise, the employee must input a TC 971 action code 663 to the module on IDRS that contains the erroneous refund. (IRM Exhibit 21.4.5-1, TC 971 ac 663 - Identifying Erroneous Refunds.) Generally, employees will use Erroneous Refund "Category D" and Responsible Function "Oth" (Other) for erroneous refunds on cases assigned to Insolvency. See IRM 21.4.5, Erroneous Refunds , for additional information.

5.9.15.7  (04-05-2011)
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.

5.9.15.8  (03-01-2006)
Timeframes for Processing of Payments

  1. Field Processing of Payments. Insolvency payments must be processed timely and efficiently under strict timeframes. 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.

5.9.15.9  (04-05-2011)
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(4), 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 11 Bankruptcies and Non-Liquidating Partnerships, 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.2 (2), Bankruptcy - Involuntary Payments.
    the liability has been adjusted, follow IRM 5.9.15.2(3), Dischargeable Liabilities.

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

5.9.15.10  (03-01-2006)
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 Field Insolvency specialists or advisors 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 must process all bankruptcy checks received at the Campus regardless of which Insolvency function is assigned the case, Field or CIO. When a Chapter 7, Chapter 11, or Chapter 12 check is processed for a case assigned to Field Insolvency, the CIO technician must advise the Field Insolvency specialist assigned the account of the payment receipt by fax, phone, or secure E-mail.

5.9.15.11  (04-05-2011)
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 follow:

    • Automatic

    • Semi- Automatic

    • Partial Designated

    • Manual

    • Non-plan

    See IRM 5.9.15.14, Payment Posting Steps, for instructions for posting methods.

5.9.15.12  (04-05-2011)
Processing CIO Payments in the Mail Room

  1. Embedded CIO Technicians. CIO bankruptcy technicians are embedded in the Philadelphia Campus mail room to review Insolvency remittance mail and separate single payments from bulk payments. Payments are generally processed by the CIO by one of three ways:

    • EFTPS, Electronic Federal Tax Payment System. 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;

    • PCC, Paper Check Conversion. 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" to proper Treasury accounts; or,

    • RS - PCC, Remittance Strategy-Paper Check Conversion. Individual checks for a single taxpayer are scanned and posted to a taxpayer's account on IDRS at the same time. This is possible because the CIO has employees embedded in Campus Support that can determine posting information immediately.

  2. Single Payments. Payments with one check for one debtor must be posted on AIS without leaving the mail room. Technicians 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.14.3, Posting Individual Trustee Checks, gives step instructions for posting individual checks on AIS.

  3. 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 technician 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 loaded to AIS;

    2. The technician generates the "MyEureka" report titled, "Trustee Plan Payment Log" ;

    3. The technician prints the "Trustee Plan Payment Log" ;

    4. 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 following local procedures.

    5. 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; and,

    6. Once errors are resolved, the report is regenerated 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.

5.9.15.13  (04-05-2011)
Receipt of Bulk Payments

  1. Deposit Ticket. Payments covering multiple debtors will be routed via Form 3210 to the Campus Support unit which 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 file.

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

5.9.15.14  (03-01-2006)
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.

5.9.15.14.1  (04-05-2011)
Chapter 13 Payments on Disk

  1. Payments Received on Disk. Some Chapter 13 trustees use an automated download program. The trustee download program systemically posts multiple payments from one trustee check to various cases using a floppy disk. Using the trustee download disk feature allows large volumes of payments to be processed efficiently. AIS applies these payments per IRM 5.9.15.2(2), Bankruptcy - Involuntary Payments. However, if the order confirming the plan or a court order specifies a specific tax period where the payments are to be applied, the Service must abide by the plan or order. These payments must be applied using the Post Semi-Automatic Payment selection on AIS.

  2. Uploading Chapter 13 Payments from Disk. The following actions should be followed for uploading payments to AIS from disk:

    1. Receive disk and copy of trustee check.

    2. Sign onto AIS (see IRM Exhibit 5.9.11-1, Accessing a Case on AIS, steps 1 through 9) and minimize the screen.

    3. Insert disk and scan for viruses (see IRM Exhibit 5.9.15-1, Virus Scanning).

    4. Maximize AIS; select the "Payments" button from the AIS Home Page.

    5. Select the "Trustee Download Options" from the AIS Payment Monitoring Menu.

    6. Select "Load Payment File " on the Trustee Payments screen to retrieve the trustee data from the diskette. AIS creates a filed named "dsbser" when the data is retrieved from the diskette. The "dsbser" extension consists of the current date and the user's processing number.

    7. Click on the "Upload Trustee file" on the Trustee File Processing screen. The Upload Trustee screen will pop-up.

    8. From the Upload Trustee screen, select "Browse" and open the file.

    9. Confirm the file found is the file that should be downloaded, and select the "send" button.

    10. The response from the Trustee File Processing Screen will appear, and the trustee download should appear with the check in one of the boxes

    11. Select Option 2a, "Refresh List" .

    12. Highlight/Select "User and date Upload" file.

    13. Select Option 2b, "Select Payment File" . The current check information should automatically populate with the current check information. Verify information is correct.

    14. Select Option 3, "Received on* date" and fill in the date to reflect the IRS received date.

    15. Select Option 4, "Save Payments'" button which returns the screen to the Trustee Payments. The check information is listed on the top of the screen.

    16. To generate an error report, select the "Check Summary Report" .

    17. The Trustee Payment report can be generated to identify either "Invalid Payments" , "Valid Payments" or "All Payments" and selecting "Run Report" . The employee can either print the report or view it electronically.

    18. Work the error report. (See IRM 5.9.15.15, Common Payment Posting Errors.

    19. When all errors are corrected, click the "Move Payments " button.

      Note:

      A message box will appear explaining the consequences of failing to make all corrections.

    20. Select the "YES" button.

    21. Click the button showing the user's name to allocate payments.

    22. A window will appear stating the number of payments that have posted and unposted.

    23. Print the unpostable listing.

    24. A Partial Overpayment Summary report is generated if any are identified.

    25. Print the Partial Overpayment Summary, if generated, and correct all errors.

    26. Generate the "Balancing Report" to verify it balances with the check payment amount.

      Note:

      If a message appears, "interest rate not current, " the interest rate must be updated on AIS. Each quarter (April 1, July 1, October 1, and January 1) the interest rate must be updated on AIS by a Level 1 User.

  3. Updating the Interest Rate. The interest rate must be updated on AIS at the beginning of each quarter. To update the interest rate, the user must:

    1. From the AIS home page, click on the "Payments" button from the list under "Misc. Options" .

    2. On the "Payment Monitoring Menu" select "Interest Rates" under the Support Options to display the interest rates for each interest period. Beginning and ending dates will appear with corresponding interest rates.

    3. Click on the "Insert" button on the navigation tool bar to bring up the next sequential interest period. The rate of interest will be missing in the interest rate field.

    4. Input the number signifying the current interest rate in the missing field following the interest period.

    5. Select "Save" to add the interest rate to AIS.

5.9.15.14.2  (04-05-2011)
Trustee Checks with Paper Rosters

  1. Bulk Check Not on Disk. Trustees, who do not send electronic (disk) payment rosters for bulk checks, may send 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 technician 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 the 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.2, Applying Payments in Bankruptcy;;

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

      3. update the AIS history; and

      4. send a secure E-Mail to the Field liaison to update the "CPM" 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 are truly closed

      4. if not, leave the case and/or plan open; or

      5. if so, close the case and/or plan.

      "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 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 clicking 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 given in IRM Exhibit 5.9.15-6,AIS Automatic Allocation, to allocate payments.

5.9.15.14.3  (04-05-2011)
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 technicians embedded in the mail room. (See IRM 5.9.15.12, 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 the "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.14.2(1).

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

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

5.9.15.14.4  (04-05-2011)
Partially Designated, Semi Automatic and Manual Payments

  1. Partially Designated Payments. The Partially Designated Payment option is normally used on 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 the "Secured" claim.

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

  4. Posting Steps. To post partially designated payments, manual payments, and semi automatic payments, the following steps should be followed:

    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 the "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 requisite 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 Short Cut. 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.

5.9.15.14.5  (04-05-2011)
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 postpetition liability, or a Chapter 7 prepetition, 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 technicians 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 post priority described in IRM 5.9.15.2, 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, the user should:

    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:
      •the "Date Received"
      •the "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:
      •the "Tin"
      •the "Name Control"
      •the "MFT Code"
      •the "Claim Code" (selected from the drop down list)
      •the "Tax Period"
      •the "Assessment" date (optional)
      •the "Comments" field (optional)
      •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.

5.9.15.15  (04-05-2011)
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 the CIO technicians correct the errors themselves without relying on Field 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 prepetition "Regular" proof of claim has not been filed by the Service, but an "Administrative" claim has been filed by the Service under § 1305 for postpetition liabilities.

      Note:

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


      When the CIO technician cannot resolve the payment posting issue expeditiously, the technician should follow the guidance in IRM 5.9.15.14.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 find 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, in fact, a tax is owed but the balance due falls below the LEM criteria for claim filing. The Service receives payments 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 "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 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 technician 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 oldest outstanding 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 technician clicking on the "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 usually is 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 SA or 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 Field specialist 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" or "SUP DIS COMPLTE" 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 the payment represents the final installment from the bankruptcy estate and should be posted following instructions given in IRM Exhibit 5.9.15-7,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, 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 given in IRM Exhibit 5.9.15-7 should be followed. If the propriety of the payment is in question, contact with the trustee is indicated.

    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 given in IRM Exhibit 5.9.15-7. 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.

5.9.15.15.1  (04-05-2011)
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 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 technician 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 USBC § 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 technician 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 technicians must locate the case on AIS using the redacted SSN and case number. CIO
    Case Closed See IRM 5.9.15.15.(4) CIO
    Multiple Cases See IRM 5.9.15.15(5) CIO
    Plan Closed See IRM 5.9.15.15(6) CIO
    Admin Plan Found No action not worked
    Manually Designated-Amount too large See IRM 5.9.15.2.4 CIO
    Partially Designated-Amount too large See IRM 5.9.15.2.4 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 technician 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. Input any missing plan and 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.2.4 CIO
    Missing Confirmation date Input the petition date as the confirmation date; then, contact the Field liaison by secure E-mail to advise that the payment has been received.

    Note:

    If a second payment is received and the confirmation date has not been updated, the case should be reassigned from the CIO to the appropriate Field Insolvency specialist.

    • CIO uses the petition date as the confirmation date so the payment can be processed expeditiously.

    • Field Insolvency must secure the confirmation date and update the Taxpayer Screen with the date found on PACER.

  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."
    To work the error report, the caseworker must 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. They can be accessed sequentially by selecting on the "Next" button.

      Note:

      After each correction is made, the "Save" button must be clicked 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 [caseworker's name] Payments" button.

    7. Non plan payments must be updated with a MFT code, claim code (O, S, SP or G) and tax period. Click on "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 - Input the correct amount
    Partially Designated payment amount too large Review the Payoff Report - 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 - input the correct data
    Payment date input is after today's date The payment date must be Prior to 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 - input the designated payment code
    This field requires an entered value Review each screen field for required data - 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 - input the correct amount
    Missing Confirmation Date Review the Taxpayer Detail File - Input the confirmation date. If not present, enter the petition date.
    Missing Petition date Review the Taxpayer Screen for the petition date - input the petition date

5.9.15.16  (03-01-2007)
Dishonored Checks

  1. Prior to Posting on AIS. If Insolvency is advised a payor has stopped payment on a trustee check or 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 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 designated payment code are not assessed a dishonored check penalty. However, reversed payments from a debtor in possession remain subject to the dishonored check penalty.

5.9.15.17  (04-05-2011)
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 Field Insolvency for plan correction. Upon correcting the plan screen, the Field Insolvency 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 Field 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 Follow by clicking "Save" to confirm the removal of the payment.

    Note:

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

5.9.15.18  (04-05-2011)
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.2 (2),Bankruptcy - Involuntary Payments.

  2. Debtor Payments. Debtors may send payments for postpetition taxes based on an informal installment agreement established between the debtor and Field Insolvency. In some instances debtors may remit payments for non-dischargeable taxes during the pendency of their bankruptcy. Or debtors may send voluntary payments to Insolvency simply because they do not know where else to send them. IRM 5.9.4.4.2,Postpetition Payments and Credits, and 5.9.4.18, Installment Agreements and Bankruptcy, give guidance to determine 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 designated payment code (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 postpetition 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 designated payment code (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 postpetition 30 2007).

      Note:

      Debtors should be directed to send informal installment agreement payments to their local Insolvency office rather than to the CIO payment address.

  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 postpetition. These payments cannot be processed through AIS. Field Insolvency must prepare Form 3244 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.

Exhibit 5.9.15-1 
Virus Scanning

When working with a diskette provided by a source outside of the Service, such as a bulk payment disk sent with a bankruptcy trustee check, the user must scan the disk for viruses through the following steps:

  1. Access Windows Explorer by right clicking the start button at the bottom left of the computer screen.

  2. Select "Explore" with a left mouse click.

  3. Open the 3 1/2 Floppy (A) drive with a left mouse click.

  4. Highlight the file name.

  5. Right click Scan for Virus.

IF... THEN...
no virus is found, proceed with processing.
a virus is found, contact Information Technology.

Exhibit 5.9.15-2 
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

    • designated payment code (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.

Exhibit 5.9.15-3 
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 the button for "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.

Exhibit 5.9.15-4 
Preparing Letter 549C

Returning a Trustee Check. When an individual check is received from a trustee for a claim that is full paid, the check must be returned to the trustee with IDRS letter 549C. To generate an LPAGE screen on IDRS without a taxpayer name or address (since the letter is going to a trustee):

Step Action
1 Access the proper letter on IDRS by inputting
LETER
549C
KM
2 Type in the trustee's name and address using all upper case letters.
3 In paragraph G (fill-in #19) type, "The Internal Revenue Service is returning your payment of $[dollar amount] because the claim for John Doe, case number XX-XXXX, has been full paid. This refund is being sent under separate cover." or
"The Internal Revenue Service is returning your payment of $[ dollar amount] because no prepetition tax liability is owed by John Doe, case number XX-XXXX. This refund is being sent under separate cover."
Note: If an amended claim should be filed (for example to amend an estimated claim to $0.00), the case must be transferred to the Field office or the CIO unit responsible for claim amendments.

Exhibit 5.9.15-5 
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 the periods included in the plan.
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.15.1, Resolving Payment Posting Errors.
8 Print the vouchers.

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:

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.

Exhibit 5.9.15-6 
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 oldest secured period, automatic allocation is made by AIS as follows:
For payment dates on or before June 19, 2000: 1) non trust fund taxes, 2) prepetition interest, 3) prepetition penalty, 4) the next oldest secured period following the order just stated, 5) then all accrued penalties for secured periods starting with the oldest period, 6) all accrued interest for secured periods starting with the oldest period, and 7) finally all trust periods starting with the oldest period.
For payment dates after June 19, 2000: 1) non trust fund taxes, 2) trust fund taxes, 3) prepetition interest, 4) prepetition 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 oldest unsecured priority period, allocation is made by AIS as follows:
For payment dates on or before June 19, 2000: 1) non trust fund taxes, 2) prepetition interest, 3) the next oldest unsecured priority period following the order just stated, 4) all accrued interest for unsecured priority periods starting with the oldest unsecured priority period, and 5) finally trust fund periods starting with the oldest unsecured priority period.
For payment dates after June 19, 2000: 1) non trust fund taxes, 2) trust fund taxes, 3) prepetition interest, 4) the next oldest unsecured priority period, 5) and finally all accrued interest for unsecured priority periods starting with the oldest unsecured priority period.

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

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


More Internal Revenue Manual