The purpose of Error Resolution is to resolve validity errors, field errors, consistency errors, and math errors in deposit tickets (DTs), debit vouchers (DVs) and other documents for posting to the Master File. Records fall out in ERS due to the Generalized Mainline Framework (GMF). The entries from transcription are transferred to ERS fields, and electronic submissions are contained in the Remittance Transaction Research System (RTRS).

The GMF programming causes records to fall out to the Error Resolution System (ERS) if they do not meet certain criteria, including (but NOT limited to):

Processing of Documents Processed as Revenue Receipts:

The following Submission Processing (SP) campuses process Revenue Receipts:

Program Goals: The program goals are to process cases correctly in a timely manner.

Authority for these procedures is found in the following sections of the Internal Revenue Code (IRC) and their corresponding Treasury regulations:

These instructions will be used by Input Correction Operations, Error Resolution System (ERS) Department, when resolving processing errors on revenue receipt forms and documents.

Taxpayer Services (TS) and Small Business/Self-Employed (SB/SE): The following employees are responsible for the activity(s) provided in this IRM, including the employee responsibilities and management responsibilities.

The Director, Submission Processing Campus checks operational performance for the Submission Processing campus.

The Operations Manager checks their operation’s performance.

The team manager/lead checks unit performance and ensures employees have the most current, updated procedures, tools and training to perform their duties.

The team employees follow IRM instructions, perform ERS terminal corrections and research on payment transactions, and maintain updated IRM procedures.

Program Goals: Correct any errors that are found, using the Error Resolution System (ERS).

Program Reports: See IRM 3.12.37, Error Resolution - IMF General Instructions, and/or IRM 3.12.38, BMF General Instructions.

Program Effectiveness: is measured by the following:

Annual Review: Federal Manager Financial Integrity Act (FMFIA).

The reports for the Control Data Analysis are on the Control-D/Web Access services, which has a login program control. Program criteria regarding and documents processed as Revenue Receipts and related information are decided by our Accounting and Tax Payments Branch, Accounts Management, and Compliance counterparts.

The following table has a list of terms, acronyms, and/or abbreviations used throughout this IRM Section.

This manual is your main source of information in correcting the record on the screen and the related document. Also, research within the following IRM manuals to find procedures to correct errors:

The following other manuals, or documents, may be used as resources:

IRM deviations must be given in writing following instructions from IRM 1.11.2.2.4, When Procedures Deviate from the IRM, and elevated through proper channels for executive approval.

The individual Revenue Receipt document processed as part of the Error Resolution System (ERS) can be found by its specific document code. The following table lists those forms (by document code) which are transcribed directly through the ISRP (Integrated Submissions and Remittance Processing) system (see also IRM 3.24.10, ISRP System - Revenue Receipts, for more information). Refer to Exhibit 3.12.10-1, Valid Tax Class-BMF/IMF MFT Code - Tax Period Tables, for a list of those Master File Tax (MFT) codes for other tax and related forms for which the proper transactions are posted to the Master File.

The specific documents codes and related forms are:

The Error Resolution System will identify errors according to type and priority. The record heading will show the type of error, and this IRM will furnish the solution for the displays of the errors.

Records will be placed into the Error Inventory or the Workable Suspense Inventory for correction. Once the Error Resolution Tax Examiner accesses the record and it is displayed on the screen, you must resolve the error by either:

Corrections will include correcting errors resulting from editing or transcription.

This manual is your main source of information in correcting the record on the screen and the related document. Also, research within the following IRM manuals to find procedures to correct errors:

See also IRM 3.12.10.1.7, Related Resources, for other manuals or documents which may be used as references.

Throughout this IRM, forms may be referred to by numbers only. The titles of such forms may not be used. The chart below shows the form number, title, and use.

ERS records are divided into three inventories.

ERS will identify errors according to the type and priority. The record heading will show the type of error.

The types of errors are:

Records for the documents in the Error Resolution System are controlled by status codes. The status is updated when the record is placed in a specific inventory. The following is a list and brief explanation of these status codes:

The final two positions of the status code will consist of the first two positions of the action code. This will put similar work together on the workable suspense inventory.

If a record has been selected to be held for Quality Review, the second and third positions will be "QA" . For example, "1QA" , "3QA" , "4QA" .

Records for which the suspense period has expired before being activated are automatically moved from status 2XX to status 3XX.

A five-character command code (CC) must be entered with every screen transmission. The CC will indicate what function is to be performed. Except for CRECT, the data accompanying the CC will be validity checked for format and content.

The CCs needed for correcting ERS records in the Error and Workable Suspense Inventory are explained in the following IRMs:

There are five types of CCs used for correcting the error inventory and the workable suspense inventory. These codes are:

The IDRS and ERS command codes needed are briefly described in the tables provided below:

The ERS Action Code (AC) indicates that specific information is missing or that the record is to be suspended or rejected from processing.

Document Perfection tax examiners will assign a three-digit code to numbered returns when they decide that the document, in its present form, is unprocessable. The AC assigned by Document Perfection will be transcribed into the record of the document.

The AC will have sufficient detail to indicate if correspondence is to be sent to the taxpayer, if research is required, or if other action is required.

The presence of a valid AC other than 001 or 999, will place the record in the suspense inventory, either workable or unworkable.

If the AC assigned by Document Perfection is invalid or incomplete, the record will be assigned to the error inventory for correction or deletion of the code.

Only one AC may be assigned at a time to record. The priority of the ACs will be 310, 6XX, 4XX, 3XX, 2XX.

An ERS Tax Examiner may enter an AC on a record, delete or correct an invalid code, or may overlay the present AC with another to resuspend or reject from ERS. This is done by entering a valid AC with CC SSPND, RJECT, or NWDLN.

An ERS tax examiner entering a valid AC with CC SSPND will be clearing the record from the screen and placing the record in either workable or unworkable suspense.

An ERS tax examiner entering a valid AC with CC RJECT will be rejecting the record from ERS. Generally, SCCF will be automatically updated for the rejected records.

The letter "C" is used as a Clear Code on an error code where the error condition is such that the resolution does not require a change or correction to the record as displayed. The display will include a Clear Field labeled "CL" to indicate the possible need of a Clear Code. CC CRECT is used to enter the "C" .

Error codes indicating the possible need of a Clear Code are cleared by either correcting the condition or entering a "C" to indicate no correction is needed.

Clear Code "C" is also used for clearing the action code (AC) from the screen after corrections have been completed. With AC 410 and AC 700, the AC must be cleared initially so that other errors in the record can be resolved.

CC SSPND will cause all "C" Clear Codes for error codes to be cleared.

The program will erase all "C" Clear Codes for error codes and ACs for the new days error inventory and workable suspense inventory. Unfinished records from the previous day will contain none of the "C" Clear Codes that were assigned to a record that was not completely worked.

Clear Code "C" will prevent any other corrections to the record to accompany Clear Code "C" . If a correction must be entered and transmitted, it must be done prior to entering and transmitting Clear Code "C" .

The "000" is also used as a Clear Code when deleting action codes. It will only be used when the ACs are invalid or erroneous, and you have decided that there is no valid reason to suspend the record.

When perfection of a record is not possible and it is necessary to correspond, perform in-house research, or refer the document to another area of the campus, the record will be suspended, and the required action taken.

A non-ADP document is a document being processed for a tax period that ended before the ADP (Automated Data Processing) system was in place for the document.

For IMF documents the non-ADP tax period is prior to 196212.

For BMF documents the non-ADP tax period is prior to 196112. See the following exceptions below:

When a document is for a non-ADP period, the record will be rejected from ERS and processed as Non Master File (NMF).

If the IMF/BMF Name Control underprint is XXXX, research using NAMES, NAMEI and/or TPIIP for IMF and NAMEE and NAMEB for BMF.

If a different TIN is not found on INOLE for an SSN/EIN, SSPND 320 for Entity.

If "No Record Found" on INOLE for an SSN/EIN, SSPND 320 for Entity.

If a different TIN is not found through research and one is not found on INOLE for an SSN/EIN, SSPND 320 for Entity.

If through research a different SSN is found, edit the TIN in the entity area. Circle out any incorrect information. If not found on BMF, SSPND 320.

Occasionally, taxpayers may designate a specific TIN for a payment being made. This specific TIN may be different from the name on the check. Payment vouchers are sometimes prepared using the designated TIN and the check entity, which may cause a mismatch between the Name Control and TIN.

To prevent erroneous refunds and to confirm proper application of payments, a review of the tax module MUST be made before correcting invalid Name Control/TIN mismatches.

If another TIN is found, research IDRS to review the tax module. Research BMFOLT/IMFOLT for record of payments (if similar amounts posted accept).

If an extension is filed with a foreign address or an indication that the taxpayer is out of the country, living abroad or qualifies for the foreign income exclusion, the extension MUST be forwarded to the Austin Campus.

The following addresses are not considered as foreign and MUST be processed as domestic addresses:

When transshipping extensions to another campus, do not send Letter 86C, Letter (Referring Taxpayer Inquiry/Forms to Another Office). Extensions are exempted from AC 61, which requires the 86C Letter.

For further instructions regarding transshipping extensions, see IRM 3.11.212 (Returns and Documents Analysis - Applications for Extension of Time to File).

Installment Agreement User Fees (IAUFs) are processed through the pipeline as revenue receipt data. The tax and fee payments will be separate transaction records.

IMPORTANT (Effective July 1, 2024 (CY 2024)): The Office of Chief Counsel informed us in August 2024 that Collection changed Installment Agreement User Fees (IAUF) again. The new Installment agreement user fees changed again, effective July 1, 2024. As directed by Chief Counsel, we copied the following information from Collection’s subsection IRM 5.14.1.2(10), from IRM 5.14.1, Installment Agreements, Securing Installment Agreements.

The current new rates (effective July 1, 2024), as described under Paragraph (10) under IRM 5.14.1.2, entitled, Installment Agreements and Taxpayer Rights, are shown in the following table:

IMPORTANT (beginning with Calendar Year 2024 (CY 2024)): The Office of Chief Counsel informed us (during Calendar Year 2023) that some of the dollar amounts in this subsection are outdated. We added their chosen text under IRM 5.19.1.6.4.6(5) to this subsection that, for Installment Agreements (IAs) entered into on or after April 10, 2018, IA user fees will be reimbursed to low-income taxpayers who are unable to make electronic payments through a debit instrument upon completion of the IA.

The Current User Fee Rates listed below provide the money amounts for Installment Agreements from April 10, 2018, to the present (see Paragraphs (6) through (11), below):

Origination User Fee (Manual):

Online Payment Agreement (OPA):

OPA Regular origination:

Reinstatement/Restructuring User Fee (Manual):

Online Payment Agreement (OPA):

All other reinstatement/restructuring:

IMPORTANT: The Prior User Fee Rates listed in Paragraphs (13) through (16) below provide the (former) money amounts for Installment Agreements User Fees (IAUFs) prior to April 10, 2018. Unless we are informed otherwise, the IAUF fees in the following paragraphs are Prior User Fee Rates only, and will NOT be used.

Installment Agreement User Fees (IAUFs) are processed through the pipeline as revenue receipt data. The tax and fee payments will be separate transaction records.

The Installment Agreement User Fees (IAUFs) data will be input from the source document (tax payment). The taxpayer’s payment will usually be split between the tax and fee transactions (split/multi blocks). A duplicate document may or may not be created to record the IAUF data. If the source document is used for both transactions, the volume on the ERS-1340 will be twice the volume of the documents present. Do not SSPND for missing unless the source document is not present.

The Primary and Secondary Transaction Amounts (Fields 01TA> and 01SA>) will contain the same amount: $31 or $43 or $89 or $107 or $149 or $225.

If an entity correction is made on the source document record, make the same correction on the user fee record.

Form 1041ES remittances often involve split payments. A single check with a listing attached may contain numerous taxpayer identification numbers, names, and applicable payment amount.

If entity problems exist for at least one of the TINs on the list, the Lockbox Bank will figure out if further research by IRS is warranted.

Lockbox Banks contact Deposit Payment Perfection Unit (PPU) to research missing entity information. Research requests are faxed to PPU to figure out if payment can be processed to the correct tax account, or as an Incomplete transaction.

If the research by PPU does not provide sufficient information to process, the Lockbox Bank will send the payment and listing to the SPC as Unprocessable. See IRM 3.12.10.3.7, Lockbox Unprocessables Reduction: Basic Manual IDRS Research for Payment Perfection (special Payment Perfection procedures).

If the above action does not result in the ability to correctly process the payment, they will continue processing.

These records will require more research by the ERS examiner and must be referred to Entity if no record is found. (Error Code 004 will generate for "no account present" .)

If Entity is unable to figure out the correct name control and taxpayer identification number, the record MUST be sent to Unidentified.

The Remittance Transaction Research (RTR) system is a researchable database that holds remittance processing data and images from the Integrated Submissions and Remittance Processing (ISRP) system and Lockbox Bank processing sites. Refer to IRM 3.5.10, Accounts Services---Remittance Transaction Research (RTR) System, for specific instructions on using the system.

RTR provides three years of images online for immediate retrieval. Images more than 3 years old are stored offline. These can be retrieved through an online request, which is retrieved and made available by the next business day.

Historical data and images in both the old RTR and InfoImage systems will be converted and made available. Historical data and images from the Lockbox Banks will not be made available. Requests for historical images from banks may still be necessary.

RTR users can query the RTR database to access remittance transaction data and images, print reports, and add notes to transactions.

A note must be added to the RTR System when a correction is made to the Name, TIN, Tax Period, Transaction Codes, Plan Number and/or anytime a correction is made to a payment, or a suspense initiated.

The Taxpayer Advocate Service (TAS) is an independent organization within the IRS whose employees assist taxpayers who are experiencing economic harm, who are seeking help in resolving tax problems that have not been resolved through normal channels, or who believe that an IRS system or procedure is not working as it must. TAS criteria include economic burden, systemic burden, best interest of the taxpayer, and public policy (as determined solely by the National Taxpayer Advocate (NTA)). TAS is responsible for assisting taxpayers who have unresolved problems with the IRS. See IRM 13.1.7, Taxpayer Advocate Service (TAS) Case Criteria, if more information is required.

While the IRS is continually working to serve customers in a quality manner, some taxpayers still have difficulty getting solutions to their problems or getting timely and right responses to their inquiries. Per IRC 7803(c), Congress established the office of the National Taxpayer Advocate (NTA) and its functions within the IRS to assist these taxpayers. TAS has identified criteria that qualify taxpayers for TAS help. The Case Advocate will conduct an independent review of actions that have been taken or need to be taken to resolve the problems taxpayers are experiencing.

Employees must not view TAS Case Criteria as a means of excluding taxpayers from TAS, but rather, as a guide to TAS case acceptance. The criteria under which TAS accepts a case must not govern whether a taxpayer is entitled to relief.

The Taxpayer Bill of Rights (TBOR) lists rights that already existed in the tax code, putting them in simple language and grouping them into 10 fundamental rights. Employees are responsible for being familiar with and acting in accord with taxpayer rights. See IRC 7803(a)(3), Execution of Duties in Accord with Taxpayer Rights. For additional information about the TBOR, see https://irsgov.sharepoint.com/:u:/r/sites/IRSSource/SitePages/Taxpayer-Bill-of-Rights.aspx.

For more information about the Taxpayer Bill of Rights, see https://www.irs.gov/taxpayer-bill-of-rights.

Throughout the text of this IRM, procedures have been written to verify specific fields.

Criteria Used for Forcing Lockbox Records to Campuses for Research/Correction: Records processed through this program contain invalid data to force records containing, missing, invalid, or illegible records to Error Resolution for correction. The following three (3) fields are used by Lockbox to force records to Campus Error Resolution for research and correction:

Lockbox informed us that two types of payments may be received from the taxpayer:

See also IRM 3.12.10.3.5.2 Integrated Automation Technologies (IAT), for procedures for using the Integrated Automation Technologies (IAT) tool for payment perfection and IDRS research. You may find information at https://irsgov.sharepoint.com/sites/IAT/SitePages/Job-Aids.aspx for a complete list of available tools and User Guides.

The Integrated Automation Technologies (IAT) Tool for Payment Perfection (formerly known as the IDRS Decision Assisting Program (IDAP) Tool for Payment Perfection) will be utilized to perform IDRS research. This section provides general guidance for only a few basic scenarios relative to Payment Perfection IDRS research. Refer to these instructions in the absence of the IAT macro for payment research. Also, in this section are a few IDRS command codes that are required to be researched to apply a payment accurately. This is not an all-inclusive list. It is intended only to provide a basic point to begin payment research.

There will be situations when more extensive research may be required, for example, the procedures outlined in IRM 3.8.45.11.2, Analysis of PPU Presearch, in IRM 3.8.45, Deposit Activity - Manual Deposit Processing. Refer to ADP/IDRS handbooks, referenced IRMs and Job Aids for complete information. There is also much information on SERP: https://serp.enterprise.irs.gov/. The job aids on this site are viewable and easily printed.

Always check cross-referenced TIN to ensure proper posting.

See also IRM 3.12.10.3.7.2 entitled, Lockbox Unprocessables: Reject Procedures, for more information.

The IRMs for the above-mentioned IDRS Command Codes are as follows:

See also IRM 3.12.10.3.7.2 entitled, Lockbox Unprocessables: Reject Procedures, for more information.

Returns and documents suspended from normal processing are Rejects. Work may be included in the suspense/rejects inventory for any of the following reasons:

Remittance information scanned or transcribed from the transaction documents (i.e., deposit tickets, debit vouchers, Lockbox records, MeF documents, etc.) failing to clear the Generalized Mainline Framework (GMF) validation runs, they fall out to the Error Resolution System (ERS) function for correction. At some point, these documents may require suspension (using Command Code SSPND, with the proper AC) from processing either for more research, review, handling or processing by another function. Sometimes correspondence with the originator or preparer of the original document/transaction is required. The purpose of these suspense operations is to retrieve information to perfect these documents for GMF validation, posting later to Master File.

Following taxpayer intent and Masterfile requirements, extensions that would require renumbering may be input directly by ERS to avoid transshipment of documents.

Priority III Errors will display as Field Errors or validity checks.

The AFD, field length (maximum length for variable fields) and the field title are shown below:

This is a four-position field that must be present.

For BMF documents with an EIN, the Name Control is invalid if:

For IMF and BMF documents with SSN, the Name Control is invalid if:

The Check Digit is invalid if:

Correct Field 01NC using the following procedures:

This is a nine-position field that must be present.

BMF documents may contain either an SSN or EIN.

This field is invalid if:

Correct Field 01TIN using the following procedures:

If IDRS Research Command Codes are not available SSPND 351 (TIN Research), or SSPND 352 (Name Research), or SSPND 320 (Entity Control), or follow local procedures.

For Rejects/Suspense Correction:

Verify and correct coding and transcription errors.

The TIN Type Indicator is a one-digit position field. Valid entries are "0" (a zero (IMF)) or "2" (BMF).

BMF documents may contain either an SSN or EIN.

Also refer to procedures in IRM 3.12.10.4.3 for correcting Field 01TIN (Taxpayer Identification Number), above.

Compare Field 01TIN with the document or archive record to find out whether the TIN is an EIN or an SSN.

If the entry in Field 01TIN has an EIN, but the TIN Type is found to be an SSN, correct Field 01TTI by changing the "2" to "0" (zero).

If the entry in Field 01TIN has an SSN, but the TIN Type is found to be an EIN, correct Field 01TTI by changing the "0" (zero) to "2" .

This is a six-position field that must be present.

Correct Field 01TXP using the following procedures:

See also IRM 3.12.10.3.7 for procedures for using the Integrated Automation Technologies (IAT) Tool for Payment Perfection and IDRS research, including Command Code SUMRY.

See also IRM 3.12.10.5.9.1, Integrated Automation Technologies (IAT), for procedures for using the Integrated Automation Technologies (IAT) tool for payment perfection and IDRS research.

This is a two-position field that must be present.

Correct Field 01MFT using the following procedures:

If the type of form cannot be found, research via IDRS as follows:

The Plan Number is a three-digit number assigned by the employer/sponsor for each plan. The Plan Number is only valid with MFTs 74, 75, and 76.

The Report Number is a three-digit number used to identify each Form 8038 (Tax Exempt/Private Activity Bonds) Series and Form 8328 Bond Issuances. The Report Number is only valid with MFT 46, 84, 85, and 86.

If the MFT in Field 01MFT is not 46, 74, 75, 76, 84, 85, or 86, delete the entry in Field 01PN.

For MFT 74 or For MFT 75, CP 213 (I) or (N) notice or Pre-Paid Payments and CP 283 Notice Payment Voucher, when a payment is received and the Plan Number is not in the valid range of 001-999 or is not found on the payment voucher, correct Field 01PN, using the following procedures:

For MFT 76, correct Field 01PN, using the following procedures:

For MFT 46, MFT 84, MFT 85, or MFT 86, correct Field 01PN using the following procedures:

This is an eight-position field that must be present.

Correct Field 01TDT using the following procedures:

IMPORTANT: If a Form 4868 (Application for Extension of Time to File) has no transaction date, see IRM 3.11.212.6 and IRM 3.12.212.6 to find the correct date. (Also see Error Code 107 instructions under IRM 3.12.10.5.9.)

This field is a three-position field that must be present.

Correction Field 01TC using the following procedures:

This is a 13-position field that must be present.

Correct Field 01TA> using the following procedures:

This is a three-position field that may be present.

Correct Field 01STC using the following procedures:

This is a 13-position field that must be present, if the Secondary Transaction Code is present.

Correct Field 01SA> using the following procedures:

This is a three-position field that may be blank.

Correct Field 01TTC using the following procedures:

Compare Field 01TTC with the input document. Correct any transcription errors.

If 01TTC was transcribed correctly, find the correct Tertiary Transaction Code. See Exhibit 3.12.10-3, Valid Transaction Codes by MFT. Enter the code in Field 01TTC.

If it can be decided that a Tertiary Transaction Code must not be entered, blank field 01TTC.

If the correct code cannot be found, SSPND 343 (Other Accounting) or 360 (Other In-House Research) either for further research or for contact with the originator for information needed to correct the transaction/document. Correct all errors.

For Reject/Suspense Correction:

This is a 13-position field that must be present, if the Tertiary Transaction Code is present.

Correct Field 01TT> using the following procedures:

For Rejects/Suspense Correction: Tertiary Transaction Amounts are not valid for IMF MFT 29 records. If a Tertiary Transaction Amount is present, SSPND 343 (Other Accounting) or 360 (Other In-House Research) for further research or for contact with the originator for information needed to correct the document. Correct all errors.

This is a one-position field that may be present.

Correct Field 01SI using the following procedures:

This is a one-position field that may be present.

Correct Field 01BPI using the following procedures:

This is a one-position field that may be present.

Correct Field 01MSC using the following procedures:

This is a nine-position field that may be present.

Correct Field 01XTN using the following procedures:

Verify and correct coding and transcription errors.

The Cross-Reference (x-ref) TIN Type Indicator is a one-digit position field. Valid entries are "0" (zero (IMF)) or "2" (BMF).

BMF documents may contain either an SSN or EIN.

Compare Field 01XTN with the document or archive record to decide whether the x-ref TIN is an EIN or an SSN.

If entry in Field 01XTN has an EIN, but the X-ref TIN Type has a "0" (zero), correct Field 01TTX by changing the "0" to "2" .

If entry in Field 01XTN has an SSN, but the x-ref TIN Type has a "2" , correct Field 01TTX by changing the "2" to "0" (zero).

This is a two-digit field which may be present. Field 01XMT must be numeric.

Correct Field 01XMT using the following procedures:

This is a three-position field that may be present.

Correct Field 01XPN using the following procedures:

This is a six-position field that may be present.

Correct Field 01XTP using the following procedures:

This is a two-position numeric field that may be present.

DPC 64 is valid for tax periods 201712 and later and may be input when MFT is either 02, 05, 06, 30, 34, or MFT 82 or MFT 83.

DPC 70 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 71 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 72 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 73 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 74 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 75 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

DPC 76 is valid for tax periods 201712 and later and may be input when MFT is 02, 05, 06, 30, and 34.

Correct Field 01DPC using the following procedures:

The following table describes unique DPC relationships requiring special handling. These Master File Tax Account (MFT) codes may require unique conditions to pass validation.

The following DPCs are valid for revenue receipt processing:

This is a five-position alpha-numeric field.

This field cannot be all blank nor contain blanks (if the Transaction Code is TC 840 (Manual Refund)).

This field cannot contain all zeroes.

IMPORTANT: This field cannot be blank if there is a TC 840 transaction on either of the following forms: Form 3753 (Manual Refund Posting Voucher), Form 12857 (Refund Transfer Posting Voucher), or Form 5792 (Request for IDRS Generated Refund).

This is a five-position alpha-numeric field.

This field cannot be all blank nor contain blanks (if the Transaction Code is TC 840 (Manual Refund).

This field cannot contain all zeroes.

IMPORTANT: This field cannot be blank if there is a TC 840 (Manual Refund) transaction on the following forms: Form 5792 (Request for IDRS Generated Refund), Form 3753 (Manual Refund Posting Voucher), and Form 12857 (Refund Transfer Posting Voucher):

This is a one-position numeric field.

This field cannot be blank (if the Transaction Code is TC 840 (Manual Refund).

These are the values of the BOD Code listed on the Form 3753 (Manual Refund Posting Voucher) and the Form 12857 (Refund Transfer Posting Voucher):

IMPORTANT: Although Accounting revised the Form 3753, Manual Refund Posting Voucher, to accept these values, the program could not be updated to accept BOD Codes 8, 9, and 0. Refer to instructions in IRM 3.12.10.4.26.1, Correction Instructions, for workaround procedures if any of these codes are received on any transactions received in error.