Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

3.42.5  IRS e-file of Individual Income Tax Returns

Manual Transmittal

September 09, 2011

Note:For Calendar Year 2012, IRS e-file Processing of Individual Income Tax Returns begins January 13, 2012.

Purpose

(1) This transmits revised IRM 3.42.5 Electronic Tax Administration, IRS e-file of Individual Income Tax Returns.

Material Changes

(1) Editorial changes including dates, reference materials and IRM number changes were made throughout this section of the IRM.

(2) IRM 3.42.5.2.1.2(2), Deleted to a federal return.

(3) IRM 3.42.5.3(3), Revised (10) to ten.

(4) IRM 3.42.5.3(7), Revised date to November 15, 2011.

(5) IRM 3.42.5.3.1.1(2), Revised 2 to two.

(6) IRM 3.42.5.3.1.1(2), Revised processing year to 2012.

(7) IRM 3.42.5.3.1.1(2), Revised "10" to "11" .

(8) IRM 3.42.5.3.1.1(2), Revised Tax Year to 2011.

(9) IRM 3.42.5.3.2.2(2), Revised 2 to two.

(10) IRM 3.42.5.5.1.1(2), Revised PAT15 to PAT15XX.

(11) IRM 3.42.5.7(4), Revised Tax Year to 2011.

(12) IRM 3.42.5.7.1(1) note, Revised year to 2012.

(13) IRM 3.42.5.16.1.1(1), Revised year to 2011.

(14) IRM 3.42.5.16.1.1(2), Revised Tax Year to 2010.

(15) IRM 3.42.5.16.1.4(3), 3rd bullet, Revised IRM reference to 3.42.5.16.19.

(16) IRM 3.42.5.16.4(1), Revised link to http://www.irs.gov/pub/irs-utl/charstatety10fs11.pdf.

(17) IRM 3.42.5.16.5, Revised the Tax Years in the title to 2004 and 2010.

(18) IRM 3.42.5.16.5.2(1) note, Revised tax year example to 201012.

(19) IRM 3.42.5.16.5.3, Revised Tax Year in the title to 2010.

(20) IRM 3.42.5.16.8.1.2(1), Revised Form to 9856.

(21) IRM 3.42.5.16.18(1), Add new paragraph one for acceptable attachments to be associated with Tax Year 2011.

(22) IRM 3.42.5.16.18(2), Add Tax Year 2010.

(23) IRM 3.42.5.18.1.1(1), Revised link to http://www.irs.gov/pub/irs-utl/charstatety10fs11.pdf.

(24) IRM 3.42.5.22(1), Deleted bullets 1-5, 8, 9, 11, 12, 18-24, 27-29.

(25) IRM 3.42.5.22(1), Add bullet for Form 9856 Attachment Alert.

(26) IRM 3.42.5.22(2), Deleted bullets 1, 2, 17, 18, 21-39.

(27) IRM 3.42.5.22(2), Add bullets for ELF6140, ELF6143 and ELF6145.

(28) IRM 3.42.5.22(3), Deleted bullets 2, 4, 10, 15, 17, 20 and 23.

(29) IRM 3.42.5.23(1), Deleted last bullet, its a duplicate.

(30) IRM 3.42.5.23.1(3), Revised to read: The MeF e-File Program is transmitted electronically using the following two transmission methods.

(31) IRM 3.42.5.23.2(1), Revised to read: The first phase of 1040 MeF began February 2010 and included Form 1040, Form 4868 and 21 most common filed Form 1040 related forms and schedules to the MeF platform.

(32) IRM 3.42.5.23.2(2), Revised to read: The second phase of 1040 MeF began in January 2011 and included additional volume of the same forms as the first release, additional hardware and MeF code optimization.

(33) IRM 3.42.5.23.3(1), Deleted in January 2010, 1040 MeF will accept only Tax Year 2009.

(34) IRM 3.42.5.23.5(2), Revised to read: Access to RRD is based on portal-defined permission by requesting the OL-5081 user role MEFHLP_PR.

(35) IRM 3.42.5.23.5(2), Deleted bullets 1, 2, 3 and 4.

(36) IRM 3.42.5.23.5(2), Deleted & MEFHLP (Testing) in chart.

(37) IRM 3.42.5.23.5(2), Deleted last three rows from bottom of chart.

(38) IRM 3.42.5.23.5(3) note, Revised to read: The most current RRD User Guide is posted on SERP web site and is also posted on EPSS web site.

(39) IRM 3.42.5.23.5(3) note, RRD User Guide is linked to current version.

(40) IRM 3.42.5.23.5, Add new paragraph four.

(41) IRM 3.42.5.25.3(1), Add to bullet list RRD Training Course 29749.

(42) IRM 3.42.5.25.4(1), Revised to add On-line Filers.

(43) IRM 3.42.5.25.4(2), Revised paragraph.

(44) IRM 3.42.5.25.8(2), Revised date to October 31, 2011.

(45) IRM 3.42.5.25.8(2), Revised Tax Year to 2011.

(46) IRM 3.42.5.25.8(6), Revised date to October 31, 2011.

(47) IRM 3.42.5.25.13(8), Revised to add chart for Form 1040A.

(48) IRM 3.42.5.25.13(9), Add new chart for Form 1040EZ.

(49) IRM 3.42.5.25.13(10), Add new chart for Form 1040PR.

(50) IRM 3.42.5.25.13(11), Add new chart for Form 1040SS.

(51) IRM 3.42.5.25.13(12), Revised to make paragraph 12 for Form 4868 chart.

(52) IRM 3.42.5.25.13(13), Add new chart for Form 9465.

(53) IRM 3.42.5.25.13(14), Add new chart for Form 2350.

(54) IRM 3.42.5.25.13(15), Add new chart for Form 56.

Effect on Other Documents

This IRM supersedes IRM 3.42.5 dated 10/01/2010.

Audience

The intended audience includes e-help Desk assistors at the Andover, Atlanta, Austin, Cincinnati, Ogden and Martinsburg sites. The intended audience also includes managers, analysts, business owners, and others who provide support to users of IRS electronic products and services.

Effective Date

(10-01-2011)

Jerald H. Heschel
Director Submission Processing
Wage and Investment Division

3.42.5.1  (10-01-2010)
Overview of the IRS e-file Program

  1. IRS e-file is a process by which tax returns are submitted to the IRS by way of data communications and processed electronically through front-end edits. Tax return data is transmitted over telephone lines in the form of electronic records to a designated Submission Processing Campus. Filing a tax return through IRS e-file can be accomplished by using an Authorized IRS e-file Provider, or by filing using a personal computer (Online Filing).

  2. Many tax preparation firms use computers to prepare individual tax returns. In the past, the return preparer had to convert machine-readable data into printed returns to file with the service. IRS e-file allows for the electronic submission of tax return data to the IRS.

  3. The Submission Processing Campus where an electronic return is filed may not be the same one where taxpayers would normally mail their paper returns.

  4. IRS processing costs are reduced and quality is improved because manual processing is diminished. Storage costs are reduced as electronic returns can be stored more efficiently and less expensive than paper returns.

3.42.5.1.1  (10-01-2010)
Taxpayer Advocate Service (TAS)

  1. This section provides a general overview of the Taxpayer Advocate Service (TAS).

  2. 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 should. If taxpayers believe they are eligible for TAS assistance, they can reach TAS by calling their toll-free case intake line at 1-877-777-4778 or TTY/TDD 1-800-829-4059.

  3. The National Taxpayer Advocate, along with the senior leadership team, have negotiated and finalized working agreements that establish how each operating division and Appeals will work Taxpayer Advocate Service (TAS) referred cases. These agreements, called Service Level Agreements (SLAs), outline the procedures and responsibilities for processing of TAS casework when either the statutory or delegated authority to complete the case transactions rests outside of TAS.

  4. The SLAs are located at http://tas.web.irs.gov/ under the heading "Policy Procedures/Guidance" .

3.42.5.1.2  (10-01-2010)
Disclosure

  1. Disclosure safeguards must always be observed as prescribed in IRM 11.3, Disclosure of Official Information.

  2. IRS employees must use caution not to disclose return information except to the taxpayer or to a person whom the taxpayer authorized to receive that information by Form 2848, Power of Attorney and Declaration of Representative; Form 8821, Tax Information Authorization; Form 8453, U.S. Income Tax Declaration for an IRS e-file Return (Tax Year 2006 and prior); Form 8453-OL, U.S. Income Tax Declaration for an IRS e-file Online Return (Tax Year 2007 and prior); or Form 8879, IRS e-file Signature Authorization. Under the disclosure authority granted on the Form 8453, Form 8453-OL, Form 8879 or equivalent display of text, IRS employees are permitted to discuss the following with Authorized IRS e-file Providers (Providers):

    1. An acknowledgement of receipt or reason for rejection of the transmission,

    2. The reason for any delay in the processing of the return or the refund, and

    3. The date of any refund.

    Caution:

    Disclosures of return information should be limited to the authority granted to the third party by the taxpayer. The Form 8453 and Form 8879 give different authority than may be given under the check box authority, or oral authority, or that which is granted with filing of a Form 2848 or Form 8821 and then recorded on the CAF. Be sure that you have checked to see what authority has been granted prior to releasing information to a third party. See IRM 21.1.3 or contact the Disclosure Help Desk at 866-591-0860 if you have questions.

3.42.5.1.3  (10-01-2010)
Declaration Control Number (DCN)

  1. The Provider's software assigns a unique fourteen-digit Declaration Control Number (DCN) to each electronic return. The DCN is printed on Form 8453 (Tax Year 2006 and prior) / Form 8453-OL (Tax Year 2007 and prior) associated with an accepted return. The 14 digit DCN is also visible on the printout of Form 8879 and is located on the top left hand corner of the page. The DCN is structured as shown in Figure 3.42.5-1.

    Figure 3.42.5-1

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Declaration Control Number (DCN)

3.42.5.1.4  (10-01-2010)
Refunds

  1. Taxpayer refunds can be expected to be issued within 3 weeks if the return is error free, has posted to Master File, and the refund is not reduced by outstanding liabilities. Taxpayers can also elect to have their refunds deposited directly into their qualifying account at a financial institution. Questions regarding refunds should be directed to Tele-Tax at 1-800-829-4477 (toll free) or the IRS Refund Hotline at 1-800-829-1954 (toll free). Taxpayers can also check the status of their refund through "Where's My Refund" on the IRS web site. See IRM 21.4 for additional information.

3.42.5.2  (10-01-2011)
Electronic Returns Systems Overview

  1. e-filing includes:

    1. Electronic Management System (EMS);

    2. The Submission Processing Subsystem (also referred to as the UNISYS Mainframe); and

    3. The Tax Return Data Base (TRDB), which is the official repository for both the Individual Master File (IMF) and Business Master File (BMF) electronically filed tax returns.

3.42.5.2.1  (10-01-2010)
The Electronic Management System (EMS)

  1. The Electronic Management System (EMS) is the front-end processing system for electronic information exchange between the Internal Revenue Service (IRS) and external Trading Partners (TPs). EMS receives returns from external Trading Partners, acknowledges the receipt of the information, prepares the information for mainframe processing, and provides mainframe-generated and EMS-generated acknowledgments to the Trading Partners. EMS also receives state tax returns, supplies mainframe-accepted state returns to State Trading Partners, receives state acknowledgment files from States, and provides the state acknowledgments to the originating Trading Partner. EMS includes a Help Desk Web Interface that provides Tax Examiners access to EMS processing information. EMS is now one system providing 2 main functionalities:

    • Processing of Trading Partner files, and

    • Web Graphic User Interface (GUI) (Help Desk) to support EMS.

  2. The exchange of data between EMS and the UNISYS Mainframe is electronic.

  3. The EMS is the gateway to and from electronic income tax filing for Form 1040 series in IRS proprietary format, Electronic Tax Documents (ETDs) and some business returns. See IRM 3.42.4 for a list of business returns.

  4. The EMS operates at the Enterprise Computer Centers (ECC) located at Martinsburg, WV and Memphis, TN. The ECC accepts returns via modems connected to either dedicated leased lines or through the internet using Secure Socket Layer (SSL) with a telnet/s protocol and the interface to the IRS Gateway. Providers can use the following Asynchronous file transfer protocols: XMODEM-1K, FTP, YMODEM Batch, ZMODEM. These are not modems; they are software protocols that the modems use to communicate with each other.

  5. The EMS provides format data verification, data translation, and mainframe delivery services.

3.42.5.2.1.1  (10-01-2010)
Help Desk Web Interface System

  1. The Help Desk Web Interface System (HDWIS) of the EMS provides help desk users (i.e., IRS e-help Tax Examiner(s) and Systems Administrators) the capability to verify the status of the receipt of trading partner transmissions and acknowledgements. The HDWIS can be used to verify transmissions and acknowledgement files between EMS and other IRS systems or subsystems. Users are able to securely log into EMS via the intranet to query and obtain various reports on the status of file transmissions. IRS users can re-hang Acknowledgement Files, query and display the log of transmissions, query and display statistics, view trading partner's status, deactivate and activate Trading Partners, determine the status of transmissions, and acknowledgements and look at a data dump of files. Instructions for e-help Tax Examiner(s) can be found in the Help Desk Web Interface Users Manual.

3.42.5.2.1.2  (10-01-2011)
State Return Function

  1. The Electronic Management System (EMS) resides at the Enterprise Computing Centers (ECC) located at Martinsburg, WV (ECC-MTB) and Memphis, TN (ECC-MEM). Kansas City (KCSPC) and Fresno (FSPC) state returns reside at ECC-MEM. Philadelphia (PSPC), Austin (AUSPC) and Andover (ANSPC) state returns reside at ECC-MTB. The EMS is used to store participating State Revenue Agencies state tax return data.

  2. The ECC receives transmissions that contain federal returns and some federal returns with state returns attached. Once the federal return associated with a state return has been validated and accepted by the UNISYS, the state return is separated from the federal return and appended to a file that is electronically transferred to EMS three times a day.

  3. The state returns are then available for retrieval by participating State Revenue Agencies.

3.42.5.2.2  (10-01-2010)
Submission Processing Subsystem (SPS)

  1. The Submission Processing Subsystem, processes an electronic file of transmissions from the Front-End Processing System (FEPS). A series of computer programs called the ELF runs do the following:

    1. Convert the electronic tax return information (sometimes called electronic data) into a format for processing.

    2. Perform validation.

    3. Generate Acknowledgement Files of accepted, duplicate, and rejected returns which are sent back to the FEPS and then to the Provider.

    4. Automate the numbering, coding, and editing.

    5. Produce an electronic file for further Submission Processing Campus Processing.

    6. Produce electronic file of electronic return data for the Tax Return Data Base (TRDB).

    7. Produce an electronic file of state data which is sent back to the EMS.

  2. Returns filed electronically are distinguished from paper returns by a unique Filing Location Code (FLC) shown as the first 2 digits in the Document Locator Number (DLN). The FLCs shown below have been reserved for e-filing except for FLCs 20 and 21. All of the other FLCs shown below should never be used for numbering paper Form 1040, Form 1040A or Form 1040EZ.

  3. When the maximum number of DLNs have been used for the Primary FLC, use the Secondary FLC. After the DLNs are exhausted using the secondary FLC, rollover to the next Julian Day.

    Submission Processing Campus Primary ELF Filing Location Code (FLC) Secondary ELF Filing Location Code (FLC)
    ANSPC 16 14
    AUSPC 76 75
    FSPC 80 99
    KCSPC 70 79, 43
    PSPC 30 32
    AUSC (International returns, Form 2555, Form 2555EZ, Form 8833, Form 8854, Form 8891, or Foreign Country address indicator "3" ) 20*  
    AUSC (U.S. Possessions addresses and returns containing U.S. Possession Form 4563, Form 5074, Form 8689, Form 1040-SS (PR), or Foreign Country) 21*  

3.42.5.2.3  (10-01-2010)
Archival Retrieval Facility and Tax Return Database (TRDB)

  1. The Archival Retrieval Facility (ARF) was used to store e-file returns up to 1998. However, the ARF system no longer exists. TRDB began to age off data in 2004. Tax Year 1998 returns that were not identified as needing to be retained via CFO-4-0449 were deleted from the database January 2005. Tax Year 1998, 1999, 2000, 2001 and 2002 (PY2011 processing) Returns are retained on TRDB only if they meet the CSED retention requirements are determined by Master File processing.

3.42.5.3  (10-01-2011)
Participants Acceptance Testing System (PATS)

  1. During PATS Testing, Software Developers will be able to transmit their PATS Test returns to the same site their live returns are transmitted to. Although all five sites (ANSC, AUSC, FSPC, KCSPC, PSPC), can receive the PATS returns, only e-help Desk Tax Examiners in Austin and Andover will work the PATS Test transmissions and returns using the ELF1544 Automated Retrieval System.

  2. Beginning with Tax Year 2008 and subsequent, all Software Developers will be required to create their own test scenarios to pass PATS testing before they can be accepted into the electronic filing program. IRS will provide test criteria for Scenarios 1, 2, 3, 4 and 5 that, if supported by the software, all Developers must follow and include when developing their test scenarios. Test Scenarios 6 through 12 will have limited criteria and must be tested if the software supports the criteria. All test scenarios transmitted must be error free before the software can be considered as passed.

  3. A test file consisting of at least ten returns, but no more than thirty-eight (38), with all related forms, schedules and attachments must be transmitted. If the test file is not formatted correctly, or if the test returns contain errors, the e-help Desk Tax Examiner will work with the Software Developer to resolve any reject conditions. The Software Developer must then send two separate same day transmissions before the software can be considered as passed in order to test the ability of the software to increment the transmission sequence number that appears in the TRANA record.

    Note:

    Test Scenario 11 is programmed to reject with ERC 0500.

  4. The Electronic Tax Administration requires that all Software Developers and Transmitters perform the required testing for each software package before being allowed to market that particular software package or transmit directly to the IRS.

  5. The PATS test package will consist of limited testing criteria. If supported by the software, each scenario should include the applicable Form W-2, Form W-2G, Form 1099-R, Form 1040, Form 1040A, Form 1040EZ and/or Form 1040-SS (PR).

  6. The test returns will include the most commonly used forms and schedules accepted for electronic filing. Any forms and schedules that will be included in software that are not included in the test scenarios may be added to Scenarios 6 through 12.

  7. PATS testing will begin on November 15, 2011.

3.42.5.3.1  (10-01-2010)
Testing

  1. The purpose of testing is to ensure, prior to live processing, that:

    1. Providers are able to transmit to the FEPS communication processor and retrieve their acknowledgement files;

    2. Providers transmit in the correct format and meet the IRS electronic filing specifications as outlined in Publication 1346, Electronic Return File Specifications and Record Layouts for Individual Income Tax Returns;

    3. Returns have fewer errors; and

    4. Providers understand the mechanics of electronic filing.

  2. When PATS testing begins and new Providers are ready to test, they should call the e-help Desk at 1-866-255-0654.

  3. Prior to transmitting test data, the Software Developer must advise the e-help Desk of all limitations to their software package. The limitations document is required prior to submitting test data. This document may be amended at any point prior to passing PATS to include or exclude forms or schedules. The document may include either a list of items that are supported or are not supported (example: Developer is only testing/submitting Form 1040EZ, there is no need to list all forms/schedules not supported). The only allowable limitation to software is:

    1. Software does not have to provide for all forms or schedules, nor for all occurrences of a particular form or schedule; however, the complete form must be transmitted with no field limitations except for the number of occurrences.

      Note:

      If software can not provide for all occurrences of a particular form or schedule, or series of fields, as specified in Publication 1346, no statement record may be used as a substitute.

  4. Software Developers can test their software packages with state e-file programs at the same time they are conducting federal testing. (See IRM 3.42.5.18.1.6, IRS Acknowledgement: Acceptance or Rejection of Records).

  5. A Software Developer that will be developing only Form 1040A and Form 1040EZ should test only Form 1040A and Form 1040EZ using as much of the required criteria as possible.

3.42.5.3.1.1  (10-01-2011)
Software Identification Number

  1. All electronically filed returns are required to have a Software Identification Number (SIN) transmitted as part of the return. If the number is not provided, the return will reject with Error Reject Code 0493. The Software Identification Number is designed to identify software products used when transmitting returns to the IRS. It is not used to track the serial numbers of individual software packages.

    Note:

    Individuals or firms who purchase another Developer's current year PATS approved software for the purpose of using and/or marketing it under their own name, must complete and submit an application requesting a separate Software Identification Number (SIN). In addition, a Communication Test must be performed by transmitting a total of five (5) tests in two separate same-day transmissions.

  2. The Software ID number assigned to tax preparation packages will be an eight digit number given during PATS testing. The Software ID number is generated in the Third Party Data Store (TPDS) by the e-help Desk Tax Examiner(s). The format of the number is "YYNNNNNN." The "YY" is the two digit tax year for which the product is being developed. For example, during PATS testing of software to be used for processing year 2012, the two digit year will be "11" for Tax Year 2011.

  3. Each software package gets its own ID number. For example, if a software company has a Windows tax package, a Macintosh tax package, a Disk Operating System (DOS) Tax package, and a Web tax package, that company will need four distinct software package ID numbers. This will allow the tracking of how errors on different packages are handled from the same company. Once the software packages have passed PATS, the assigned PATS team will update TPDS and the designated person at each campus will e-mail the acceptance sheets to the other sites, E-Submissions and Electronic Products & Services Support (EPSS) Headquarters.

  4. The information will be sent in an EXCEL file which contains the following columns:

    1. Software ID Number (different ID for each package),

    2. Software Vendor,

    3. Package Name,

    4. Software Developer's Electronic Filing Identification Number (EFIN) and

    5. any pertinent notes.

3.42.5.3.1.2  (10-01-2010)
E-help Software Acceptance Testing Spreadsheet for Software Packages

  1. The e-help Acceptance Testing Spreadsheet should include the following information:

    • Company Name

    • PATS 1 (ELF) Testing passed date

    • Developing Companies EFIN

    • PATS 1 (ELF) Software Limitations (i.e., forms not supported)

    • PATS 2 Electronic Transmitted Documents (ETD) Testing passed date

    • PATS 2 (ETD) Software limitations (i.e., forms not supported)

    • Software Package name

    • Operating System (DOS, MAC, UNISYS, Windows, etc.)

    • Software Package ID Number

    • Online or Practitioner

  2. Assign a Software Package ID Number to ALL software packages using TPDS.

3.42.5.3.2  (10-01-2010)
1040 PATS 1

  1. Communication Testing is required at one of the EMS sites to which the Electronic Return Originator (ERO)/Transmitter plans to transmit live returns. Communication Testing can be performed by transmitting a total of five (5) tests. Testing at multiple EMS sites is optional.

    1. A Transmitter (solely), who is not a Software Developer, using accepted software is required to complete an error-free Communication Test by transmitting a total of five (5) tests in 2 separate same-day transmissions.

    2. An ERO/Transmitter, using accepted software, must complete an error-free Communication Test by transmitting a total of five (5 ) tests in 2 separate same-day transmissions. The e-help Desk Tax Examiner(s) will verify the Software ID number. (See IRM 3.42.5.7.1)

3.42.5.3.2.1  (10-01-2010)
ETD PATS 2

  1. The forms below are processed on the Electronic Transmitted Documents (ETD) System. The ETD System will process forms which are considered stand-alone forms (a form unaccompanied by any version of the Form 1040).

    • Form 56, Notice Concerning Fiduciary Relationship;

    • Form 2350, Application for Extension of Time for Filing U.S. Income Tax Return (AUSC only);

    • Form 4868, Application for Automatic Extension of Time to File U.S. Individual Income Tax Return;

    • Form 9465, Request for Installment Agreement.

    Note:

    Software Developers can test ELF PATS 1 or ELF PATS 2 data at any time. The ETD file must include the Form 4868 and may include one or more of the following: Form 56, Form 2350, Form 9465 and form payments. Companies that only submit Electronic Transmitted Documents are not required to pass ELF PATS 1.

  2. Software Developers who have passed PATS for 1040 and develop ETD software are required to do ETD PATS Testing. When they have passed, they will be considered as passed for all sites. All test scenarios transmitted must be error free and received in two separate same-day transmissions before the software can be considered as passed in order to test the ability of the software to increment the transmission sequence number that appears in the TRANA record before the software can be considered as passed.

3.42.5.3.2.2  (10-01-2011)
PATS Test Passwords

  1. New applicants will receive a password letter when the application is processed and the Electronic Transmitter Identification Number (ETIN) is assigned. All other transmitters/Software Developers will use their current password. If the password letter is not received, Providers must contact the e-help Desk at 1-866-255-0654.

  2. The FEPS will accept transmissions from Providers 24 hours a day, except for a one to two hour maintenance period, which may vary with each Submission Processing Campus.

3.42.5.4  (10-01-2010)
Front-End Processing System and Trading Partner Interface (TPI)

  1. When a new transmitter has received their ETIN/passwords and their profile has been input to the FEPS, they are ready to send their transmission.

  2. See the Trading Partner Interface of the FEPS of Publication 1346, Electronic Return File Specifications and Record Layouts for Individual Income Tax Returns.

  3. Access to the FEPS will be via a web-based browser, Internet Explorer, that resides on the employee's workstation. Staff can reset Acknowledgement Files, view and display the log of transmissions, view and display a data dump of files. The Electronic Automated Reports System (EARS), the Third Party Data Store (TPDS), etc., will also be available so staff can have everything they need on one workstation.

3.42.5.5  (10-01-2010)
PAT Runs

  1. The PAT Runs are a series of computer programs that are run on a UNISYS computer system. The FEPS processor receives the transmitted data. The raw data is drained (copied or moved) from the FEPS in order to process it through the PAT Runs.

3.42.5.5.1  (10-01-2010)
PAT02 Generate-Fixed-ELF-Records

  1. The PAT02 run expands returns received in variable format to a fixed format. It also validates the format of the Trans Records (the first 2 records of each file are known as TRANA and TRANB), Summary Record (the last record for each tax return), Recap Record (the last record on each file), returns, forms, and schedules.

3.42.5.5.1.1  (10-01-2011)
PAT04 Validate-ELF Returns

  1. The PAT04 performs the validity and consistency checks. These checks are completed before IRS accepts the return into the processing system. If the return does not satisfy these checks, it is rejected back to the Provider. A return can be acknowledged to the transmitter as accepted, even if it has not been through any math checks. An accepted acknowledgement indicates that the return is in a processable format. The ELF acknowledgement file is generated from this run.

  2. Data from the PAT04 generates the following PAT15XX reports shown in IRM 3.42.5.5.1.2 and IRM 3.42.5.5.1.4.

3.42.5.5.1.2  (10-01-2010)
PAT1542 (Rejected Transmission Summary)

  1. The PAT1542 screen display identifies the reasons for rejection of an entire transmission. Transmitters will receive the information shown on the screen display in their acknowledgement file. When this occurs, the individual returns will not be validated. The errors are listed by transmission sequence number and the PAT1542 report is sorted by process date and transmitter ETIN. The summary includes the total number of returns and total number of electronic fund transfer (EFT) requests that were included in the rejected transmission. PAT15XX reports are available on EARS.

3.42.5.5.1.3  (10-01-2010)
Transmission Reject

  1. Transmissions reject when one or more error conditions exist. Publication 1346, Attachment 1 contains a complete list and explanations of all error reject codes. The following are examples of error conditions:

    Note:

    A complete listing of transmission communication errors can be found in Publication 1346, Appendix I

    • Total Return Count in RECAP record disagrees with the program computed count.

    • Total EFT Count in RECAP record disagrees with the program computed count.

    • The transmission sequence number of the TRANA matches a previously accepted transmission.

    • Julian Day in TRANA record is more than 2 days prior or 1 day subsequent to process date.

    • Transmitter identification data in TRANA differs from that in RECAP.

    • Transmission unrecognizable due to unreadable characters or inconsistent control data.

    • The TRANB record is not present.

    • The data records of the transmission are not in the following sequence: TRANA, TRANB, Return records (1-10,000) and RECAP record.

    • The format of the TRANA, TRANB or the RECAP record does not correspond exactly to format specified in Part II of Publication 1346.

    • The EFIN of the transmitter is missing.

3.42.5.5.1.4  (10-01-2010)
PAT1544 (Acknowledgement Listing)

  1. The PAT1544 report identifies the status of the returns that have been received by IRS. Providers will receive this information in their Acknowledgement (ACK) File.

  2. The acknowledgement listing shows if the returns are A-accepted, R-rejected, D-duplicate, or T-transmission rejected.

  3. A rejected return can have error records. However, only 9 error records are displayed. Each error record consists of the number of the error record (01–09) and:

    • The form or schedule in error,

    • The occurrence of the form or schedule in error,

    • The field in error and

    • The reject code for the error.

  4. In addition, there will be a state code indicator to identify a federal return containing a state record.

  5. State Only returns are also identified on the PAT1544 Report.

3.42.5.6  (10-01-2010)
Acknowledgement (ACK) Files

  1. An Acknowledgement File (ACK File) is generated by the UNISYS-PAT41 and transmitted back to the Provider through the FEPS. It lists accepted, rejected, duplicate or exception processing electronic returns that have been transmitted to the IRS. This file will show if an entire transmission has rejected.

  2. Each file of returns transmitted to the Service will normally be acknowledged within 2 workdays of receipt. The Provider should match the acknowledgement file to the original file transmitted. The ACK File will indicate whether a return has been accepted, rejected or duplicate processing. Rejected returns must be resubmitted and acknowledged as accepted before they will be processed.

  3. Acknowledgement Files are purged from EMS 2-7 days after the Provider has picked up the ACK File, depending on the space available in the system. Any ACK File over 14 days old cannot be retrieved.

3.42.5.6.1  (10-01-2010)
Resetting ACK Files

  1. If Providers have trouble receiving their ACK Files, the ACK File can be reset on the e-help Desk. Follow the "Reset Acknowledgements" instructions in the EMS Help Desk Web Interface Tax Examiner (TE) Manual (Section 5.1.1).

  2. Providers may reset their ACK Files using the EMS Log-in Menu.

    Note:

    ACK Files can only be reset for the Transmitter.

3.42.5.6.2  (10-01-2010)
Identifying Problems in the ACK File

  1. Providers may need more assistance than the ACK File provides in resolving problems and identifying reject codes. When this is necessary, the following printouts from the EMS system showing the data in different stages of processing can be requested:

    • EMS Data Dump

    • UNISYS Data Dump

  2. Follow the instructions for requesting a data dump in the EMS Help Desk Web Interface Tax Examiner (TE) Manual (Section 5.2.1).

  3. In reviewing the data from these printouts you will be able to identify field entries in error.

  4. Tax Examiners will provide assistance to Providers in interpreting the data.

  5. It may be necessary to order an EMS Data Dump, which can be viewed on the screen while on the phone or may be printed out. This printout contains the data the Provider transmitted to the EMS before being converted in the PAT02 Run.

3.42.5.7  (10-01-2011)
PATS Acceptance Procedures: e-help Desk - Software Developers

  1. An e-case will be created at initial contact. Be sure to give the e-case number to the Software Developer and forward to the Site Coordinator to be included on the Excel Spreadsheet. Continue to update e-case until the Software Developer is approved.

  2. Based on the previous year's Software Developer listing, the e-help Desk will contact each Software Developer prior to the beginning of PATS testing. The initial and subsequent contact should include:

    1. Contact information for the Developer's assigned Tax Examiner(s)

    2. Ways to contact the e-help Desk Tax Examiners:

        • GoldCard e-mail @ irs.e-helpmail@irs.gov
        • Toll free # 866–255–0654

    3. TPDS verified information:

        • contacts
        • phone numbers, addresses and e-mail addresses
        • application roles and forms
        • provider options (OL vs. Professional)
        • provider options Software Developer ETIN

    4. Software Identification Number for all packages

    5. PATS Testing and Production Drain times

    6. EMS web addresses

    7. Vendor's name, Package Names, Operating Systems, Uniform Resource Locators (URLs)

    8. Whether they are conducting PATS 1, PATS 2, or both

    9. Software Limitations document for approval before testing begins

  3. Any new Software Developer is subject to the above criteria.

  4. Publication 1436, Test Package for Electronic Filers of Individual Income Tax Returns for Tax Year 2011, has established criteria for test Scenarios 1-5 and is not to be altered. Based on Publication 1436's established criteria for test Scenarios 6-12, the Software Developers will create their own scenarios, if the software supports the criteria.

  5. During the PATS testing process, the e-help Desk Tax Examiner(s) will work with the Software Developer to resolve any transmission or return reject conditions. If unable to resolve, the Tax Examiner(s) will refer to the lead or manager. When unable to resolve at the e-help Desk site, the E-Submission analyst will resolve the issue. The e-case will be referred to the analyst.

  6. The Tax Examiner(s) will utilize EARS for PAT Retrieval (PAT1544) and/or ETD Retrieval (PAT6824) to validate return criteria and to identify field entries in error.

  7. The Tax Examiner(s) will utilize PAT Retrieval (PAT1544), and/or ETD Retrieval (PAT6824):

    1. Verify (based on established criteria and software limitations) all required forms/schedules have been sent in on at least one of the test returns.

    2. Verify the software contains a valid and current Software Identification Number.

  8. For final approval, the Software Developer must successfully transmit the required forms/schedules in 2 separate same-day transmissions with no errors in order to test the ability of their software to increment the transmission sequence number that appears in the TRANA record (Test #11 is designed to reject with ERC 0500). The Tax Examiner(s) will:

    1. Search PAT Retrieval (PAT1544) and/or ETD Retrieval (PAT6824), by ETIN/EFIN and Julian Date of the transmission,

    2. F2 to print the summary screen of the 2 transmissions,

    3. Print data dump of test return(s) to verify established return criteria,

    4. Forward documentation for final approval of PATS Site Coordinator,

    5. Update the appropriate role/form on TPDS after final approval is received from PATS Site Coordinator, and

    6. Notify Software Developer of final approval using E-mail Response Management System (ERMS) software template.

    7. Close e-case

  9. The e-help Desk assigned Tax Examiner will forward all documentation to the Site Coordinator for final approval/acceptance. The Site Coordinator will update the Software Acceptance Testing Spreadsheet and forward to appropriate personnel.

3.42.5.7.1  (10-01-2011)
PATS Acceptance Procedures: e-help Desk - Communication Testing

  1. Each Transmitter (solely), who is not a Software Developer, is required to send a Communication Test using an approved Software package. The Transmitter must complete an error-free Communication Test by transmitting five (5) tests to one EMS site in 2 separate same-day transmissions. The e-help Desk Tax Examiner(s) will:

    1. Search PAT Retrieval (PAT1544) and/or ETD Retrieval (PAT6824) by ETIN/EFIN and Julian Date of the transmission,

    2. Verify the Transmitter sent five (5) tests in 2 separate same-day transmissions to one EMS site,

    3. Verify the software contains a valid and current Software Identification Number,

    4. Verify suitability status on TPDS,

    5. Ensure the ACKS have been picked up on EMS, and

    6. Move the appropriate ETIN to production status and add comments to TPDS, "Passed Comm Test" .

    Note:

    Software ETINS always remain in test so that the Software Developer may conduct Form 1040 tests all year round. If applicable, Software Developers should check the specific state procedures to determine if the state allows testing beyond January 2012.

  2. A Transmitter using accepted ETD software that has passed PATS Communications testing for 1040 electronic returns will not be required to do an ETD Communications Test.

3.42.5.8  (10-01-2010)
Review Procedures

  1. The test package of electronic returns, Publication 1436, consists of return information that the applicant converts into the correct format for electronic filing. This package is used to test the applicant's ability to format and transmit electronic returns.

3.42.5.8.1  (10-01-2010)
PAT6242-Reject Error Report

  1. Review the Reject Error Report when there is a discrepancy between the input and output counts on the PAT0248 listing. It is likely that the records were dropped because of an incorrect format. PAT0242 contains records that passed through PAT02. These records are either not in the proper sequence, contain form(s) or schedule(s) that are not accepted in electronic filing, or there is an error in the Record Identification (Record ID). Records appearing on this listing usually drop for one of the following reasons:

    • Record out of sequence (for example: Schedule A follows Form 2106 instead of preceding Form 2106 ). Records appear out of sequence because of records that dropped in PAT02 and/or PAT62. The correct sequence is explained in the File Specifications and Record Layouts.

    • Applicant does not increment the sequence number in the record identification field of multiple forms or schedules (for example: when there are 2 Form 2106, three Schedules C, etc.).

    • Applicant transmits a form or schedule with a Social Security Number (SSN) that is not the SSN in the record identification field of Form 1040, page 1.

      Note:

      Dropped records are not validated. Therefore, the Providers must retransmit the return before the records are checked for errors.

3.42.5.8.2  (10-01-2010)
Review Transmissions

  1. Each transmission must begin with the TRANA and TRANB records and end with the RECAP record. In between will be return information. Each individual return must end with a summary record. The specifications for these records are found in Publication 1346.

3.42.5.8.2.1  (10-01-2010)
Review Data Dump Printouts

  1. The printout shows the order in which the information appears. All record identification fields are fixed length fields regardless of the format type.

  2. The Data Dump printout shows the transmitted file or return in raw state. By reviewing the data in this raw state, you can identify why field entries are in error or why a record dropped. You can request a Data Dump of the entire transmission by ETIN or a single return by SSN.

  3. Copy and paste the fixed format data dump into a Microsoft Word document that is formatted to use HE Terminal font. This maintains the 80 characters per line, and Microsoft Word will count and display the line and column position.

  4. When the transmission is in variable format, the field number is listed in brackets ([ ]) and followed by the field entries.

  5. If the same error reject code appears throughout the transmission, there is no need to inform the applicant of each occurrence. Advise the transmitter that a program problem could exist within the software rather than it being a data entry error.

  6. Because this is a general list, the PATS Site Coordinator will be available to help resolve specific problems.

3.42.5.8.2.1.1  (10-01-2010)
Identifying the Cause of a Rejected Transmission

  1. Compare the field contents to the specifications listed in Publication 1346 to see why the field is in error.

  2. Check the format type indicator in the TRANA to see if the file was transmitted in fixed or variable format. The Provider transmits significant data fields only, preceded by the field sequence number. (For example: [0110] 5000 indicates that the entry for sequence 0110 is 5000).

  3. Identify errors in variable format by comparing the Publication 1346 to the transmitted data. Often errors in variable length records are caused by one of the following:

    • Omission of the sequence number.

    • Omission of the bracket delimiters ([ ]). (A delimiter is a symbol that indicates the beginning or end of a record.)

    • Incorrect hexadecimal characters for brackets.

    • Format type indicator in the TRANA record is fixed (F), but the data is in the variable (V) format, or vice versa.

    • Omission of record delimiters (for example, 4 asterisks at the beginning of the record and a # pound sign at the end of the record are missing).

  4. Cross-check the byte count (character code) on the printout with the byte count specified in Publication 1346 when the transmission is in a fixed format. If they do not match, the Provider has transmitted an incorrect record or the file was corrupted during the transmission. An incorrect byte count transmitted in the byte count field will not cause the transmission to reject. However, if the actual byte count (length) of the TRANA record is incorrect, the transmission will reject.

  5. Compare count of returns in RECAP record with count of the returns in the transmission. Count returns in the transmission by the change in the Primary Social Security Number (contained in the Record ID of a subsequent record) between the TRANB and RECAP. For example, if a page record from one return was erroneously positioned in the middle of another return, the program would count that one return as three separate returns because the counter is triggered by a change in the primary SSN in the Record ID.

  6. Compare the count of EFT returns in the RECAP record with the count of EFT data in the transmission. Count EFTs by the presence of any data within the direct deposit fields of Form 1040: 1272, 1274, 1276, and/or 1278 or if Form 8888 is present. If an extraneous character is present anywhere within those fields, the program counts it as an EFT.

  7. Compare the count of records in the Summary with the count of records in the return count records by a recognizable and valid Record ID for a particular form, schedule, or statement. (See IRM 3.42.5.5.1.2, PAT1542 Rejected Transmission Summary and IRM 3.42.5.5.1.4, PAT1544 Acknowledgement Listing).

3.42.5.9  (10-01-2010)
ELF Reports

  1. In addition to the ELF1542 and ELF1544 reports mentioned in IRM 3.42.5.5.1.2 and IRM 3.42.5.5.1.4, there are other reports used by e-help Desk managers to pull statistics. Management may also use some of these reports to monitor Providers. If their error rate is unacceptable, they may be suspended from the Electronic Filing Program. The following are descriptions of these reports.

3.42.5.9.1  (10-01-2010)
ELF0448-Drain Receipts

  1. The ELF0448, Drain Receipts, provides statistics that show how many returns were transmitted, accepted, or rejected, etc., from the previous drain.

3.42.5.9.1.1  (10-01-2010)
ELF1041-Return Volume and Percent, ERS/Unpostables

  1. The ELF1041, Return Volume and Percentage of ERS Returns and Volumes for Unpostable Returns, provides daily cumulative totals and percentages for ELF Form 1040 ERS returns. This report also provides return counts for the ELF Form 1040 unpostable returns for the GUF 0705 processing cycles available for each Submission Processing Campus.

3.42.5.9.1.2  (10-01-2010)
ELF1540-Daily Cumulative Totals by Territory and EFIN

  1. The ELF1540, Daily Cumulative Totals Report, by Territory and EFIN, provides daily cumulative totals for each Territory Office by EFIN for each transmission drain of Form 1040 returns. It also includes a summary of daily counts. This report is not generated for PATS processing.

3.42.5.9.1.3  (10-01-2010)
ELF1541-Year to Date Totals by Territory and EFIN

  1. The ELF1541, Year-to-Date Totals, by Territory or EFIN, provides year-to-date totals for each Territory and/or the EFIN. This report is updated daily.

3.42.5.9.1.4  (10-01-2010)
ELF1543-Transmitter Activity of Accepted Returns

  1. The ELF1543, Transmitter Activity of Accepted Returns, provides totals of year-to-date accepted returns for all transmitters by EFIN within each ETIN by Territory. This report is updated daily.

3.42.5.9.1.5  (10-01-2010)
ELF1545-Reject Code Listing

  1. The ELF1545, Reject Code Listing, contains a listing of all error reject codes, the total number of occurrences for each code per drain, or a year-to-date cumulative count of all reject code occurrences. It also provides the percentage of each error reject code when compared to the total number of all error reject code occurrences. Multiple submissions of a return may have numerous occurrences of the same reject code.

3.42.5.9.1.6  (10-01-2010)
ELF1546-1040 Inventory Listing

  1. The ELF1546, 1040 Inventory Listing, provides the number of electronically filed returns by the territory office during the processing year. Counts for both year-to-date or current-run returns are listed for each return type ( Form 1040, Form 1040 with a Schedule C or F present, Form 1040A, and Form 1040EZ ), by Territory. Neither the screen display or the report will be generated for PATS processing.

3.42.5.9.1.7  (10-01-2010)
Federal/State e-file Statistics

  1. The ELF1547, Federal/State e-file Daily and Year-to-date Reports, provides counts for states participating in Federal/State and State Only e-file, and Federal/State Online. The yearly report compares prior year and current year totals.

  2. The ELF1557, Federal/State e-file Daily and Year to Date State Count Reports provide federal and state counts for e-file, OnLine and State Only. The reports counts are based on the Form 1040/ Form 1040A/ Form 1040EZ state abbreviation in the taxpayer address and contains separate counts for all states, APO addresses and foreign addresses.

3.42.5.9.1.8  (10-01-2010)
ELF1549-Participant's Returns-filed count Summary

  1. The ELF1549, Participant's Summary Report, provides a breakdown of the number of participants within each territory that filed a given volume range of returns. This report will not be generated for PATS processing. This report is updated daily.

3.42.5.10  (10-01-2010)
Direct Deposit of Refunds

  1. Taxpayers who file tax returns electronically can elect to have their refunds deposited directly in up to three different accounts at financial institutions. Publication 1345 contains a detailed explanation of the Direct Deposit option. Additional Direct Deposit information can be found in IRM 21.4.1, Refund Research.

  2. Direct Deposit refunds are transmitted electronically from Martinsburg Computing Center (MTB) to the appropriate Financial Management Service (FMS) Regional Financial Centers (RFC), utilizing telephone lines and MITRON tape drives. This technology enables Direct Deposit refunds to be made one week earlier than paper check refunds requested in the same processing cycle.

  3. Financial institutions must credit Direct Deposit refunds to taxpayers' accounts as of the Friday payment date specified in the payment data IRS sends to them through the RFCs.

  4. Refer direct deposit erroneous refunds to the Refund Inquiry Unit. See IRM 21.4.1.4.7, Direct Deposits - General Information, for more details.

3.42.5.10.1  (10-01-2010)
Dishonored Direct Deposit Refund Requests

  1. Direct Deposit data on electronic returns is checked during initial processing. Returns that receive the following Direct Deposit related reject codes may be retransmitted to IRS after the necessary correction is made by the Provider.

    Reject Code Cause
    0019 The transmitted routing transit number (RTN) does not match the EFT-RTN on the Financial Organization Master File or the RTN is not in the valid range.
    0105 A mismatch in Direct Deposit data on the transmitted Return and Summary records.
    0830 A mismatch between the EFT count of the transmitted RECAP record and the IRS computed counts.

  2. Subsequent to IRS acknowledging that a return was accepted, the following special processing conditions can cause a direct deposit request to be dishonored if the return meets any of the following Refund Review criteria:

    • ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    • A Power of Attorney (POA) indicator exists on Master File, directing the refund be sent to, but not cashed by, the POA; and

    • The financial institution cannot credit the account specified in the Direct Deposit refund request.

  3. Special processing conditions can cause a direct deposit request to be reduced or eliminated. These include:

    • IRS debts;

    • Financial Management Service (FMS) debts; and

    • Certain Exam and Criminal Investigation criteria.

  4. Check Command Code (CC) INOLE with definer "S" to determine if there is an outstanding IRS and/or FMS debt. Also, check CC INOLE with definer "S" to determine if there is a cross reference SSN and/or Employer Identification Number (EIN) and research these numbers for IRS debts as well.

  5. If the Direct Deposit refund request is subsequently dishonored by the IRS and/or FMS, in most cases the IRS and/or FMS will issue an explanatory notice to the taxpayer.

  6. Issuance of a refund after settlement cycle (when the return data is posted at Master File) will not, in itself, cause the Direct Deposit request to be denied.

  7. When applicable, paper checks are annotated that the refund amount includes interest. However, taxpayers who are paid interest on Direct Deposit refunds do not receive a written notice from IRS that interest was included in the payment.

3.42.5.11  (10-01-2010)
Returns Processed Under the Wrong SSN or Name

  1. Calls may be received from Providers or taxpayers who indicate that the incorrect SSN or name was transmitted, causing returns with a mismatch between the name and SSN to reject up-front. However, there is still a small possibility that these type of returns could get through the system. If this occurs, the refund may be delayed. When this occurs:

    1. Complete Form 9189, Referral Sheet;

    2. Research using Integrated Data Retrieval System (IDRS) CC UPTIN;

    3. Research using IDRS CC INOLE to verify if the information is correct;

    4. Attach IDRS CC UPTIN printout that reflects the return is an open Unpostable, and an CC INOLE printout showing entity information;

    5. Route to Unpostables Unit.

3.42.5.12  (10-01-2010)
Returned Direct Deposit Information

  1. Direct Deposits that have incorrect RTNs are returned to IRS by FMS, and the refunds are issued as paper checks. A CP-53 notice will automatically be sent to the taxpayer when this occurs.

  2. If the account number, SSN, or name on a Direct Deposit transaction does not match their records, financial institutions return the refund to the RFC, generally within 3 days.

  3. When an institution returns a Direct Deposit refund, the RFC sends both paper and electronic documentation of that returned item to the appropriate IRS Submission Processing Campus and to Martinsburg Computing Center (MTB).

    1. The RFCs send Tax Form Segment (TFS) Forms 145, Schedule of Canceled EFT Items, to notify Submission Processing Campuses of returned refunds, and;

    2. The RFCs send a copy of the TFS Form 145 and the electronic (magnetic tape) record (by which credit [TC 841] for the refund is posted to the Master File) to MTB.

  4. Returned refunds documented by the TFS Form 145 post to IDRS and the credits are released in the same cycle. CC REINF displays "MORE THAN ONE REFUND" to indicate this event. Submission Processing Campus personnel need to take no action to release the credit.

  5. The most common reasons for credits not posting timely are:

    • The RFCs do not send documentation of the returned credit to MTB at the same time that they send the tape file, MTB cannot process the electronic record without the paper document;

    • Financial institutions may not return refunds timely, after determining that the taxpayer's depositor account number does not match an account number at that institution.

3.42.5.13  (10-01-2010)
Manual Refunds

  1. Manual refunds should be processed by the Refund Inquiry Unit.

  2. For complete information on issuing manual refunds, See IRM 21.4.4, Manual Refund.

3.42.5.14  (10-01-2010)
Processing CP-31 Notice

  1. CP-31 notices are to be forwarded to the Refund Inquiry Unit for resolution. For information on the undeliverable refunds process, See IRM 21.3.1.4.25, Undelivered Refund Check.

3.42.5.15  (10-01-2010)
Transmission to the IRS

  1. Transmission to the IRS is accomplished through the Front-End Processing System. The Front-End Processing System (FEPS) resides at the Enterprise Computing Centers located at Martinsburg, West Virginia and Memphis, Tennessee.

3.42.5.15.1  (10-01-2010)
Front-End Processing System

  1. Transmitters will transmit returns and ETDs to the following sites. To access the "Processing for 1040 e-file Transmission Chart" , go to: http://www.irs.gov/efile/article/0,,id=188321,00.html.

  2. FEPS performs the following tasks:

    1. Transmits an Authorized Use Banner.

    2. Identifies itself.

    3. Prompts for login ID (8 byte alpha-numeric EMS LoginID).

    4. Prompts for password.

    5. Validates login ID and password.

    6. Displays Official Use banner.

    7. Present main menu.

    8. Asks if ready to receive ACK files.

    9. Downloads ACK files.

    10. Sends dummy ACK Files if there are no regular ACK files ready to send.

    11. Sends Communication Error ACK Files.

    12. Indicates that it is ready to receive transmission file.

    13. Performs virus detection (if virus is detected the FEPS will flag virus detected, temporarily suspend transmitter, disconnect and generate a communication error ACK).

    14. Disconnects: anytime there are pauses greater than 60 seconds; 3 invalid logon attempts; 3 invalid transfer protocol attempts or 3 invalid compression methods.

    15. Generates file name for transmission.

    16. Validates for existence of TRANA, TRANB, RECAP record.

    17. Validates Julian Date.

    18. Counts numbers of returns and compares to RECAP.

    19. Creates file for UNISYS to pick up.

3.42.5.15.2  (10-01-2010)
Successful Transmission

  1. Providers will receive several messages determining a "Successful Transmission" from the FEPS; for an example of a successful transmission, (See Figure 3.42.5-2).

    Figure 3.42.5-2
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Successful Transmission FEPS screen


More Internal Revenue Manual