Part 3. Submission Processing

Chapter 42. Electronic Tax Administration

Section 5. IRS e-file of Individual Income Tax Returns

3.42.5  IRS e-file of Individual Income Tax Returns

Manual Transmittal

September 06, 2012

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

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.1, deleted paragraph.

(3) IRM 3.42.5.1.1(2), reworded last sentence.

(4) IRM 3.42.5.1.1(3), added a new paragraph.

(5) IRM 3.42.5.1.2, deleted references to Form 8453 and Form 8453-OL.

(6) IRM 3.42.5.1.3, deleted references to Form 8453 and Form 8453-OL.

(7) IRM 3.42.5.1.4, reworded paragraph.

(8) IRM 3.42.5.2, add information to bullet list.

(9) IRM 3.42.5.2.1.1, added instructions for e-help.

(10) IRM 3.42.5.2.1.2(2), reworded paragraph.

(11) IRM 3.42.5.2.1.2(3), added information to paragraph.

(12) IRM 3.42.5.3(2), change scenarios number to three (3).

(13) IRM 3.42.5.3(3), change ten (10) to three (3) returns and deleted note.

(14) IRM 3.42.5.3(5), deleted Form 1040 SS (PR).

(15) IRM 3.42.5.3(6), deleted last sentence.

(16) IRM 3.42.5.3(7), revised date to November 13, 2012.

(17) IRM 3.42.5.3.1(2), delete PATS.

(18) IRM 3.42.5.3.1(3), revised paragraph.

(19) IRM 3.42.5.3.1(4), add information to paragraph.

(20) IRM 3.42.5.3.1.1(1), add MeF Business Rule.

(21) IRM 3.42.5.3.1.1(1) note, change five (5) to three (3).

(22) IRM 3.42.5.3.1.1(2), deleted PATS.

(23) IRM 3.42.5.3.1.1(2), revised processing year to 2013.

(24) IRM 3.42.5.3.1.1(2), revised "11" to "12" .

(25) IRM 3.42.5.3.1.1(2), revised Tax Year to 2012.

(26) IRM 3.42.5.3.1.1(3), deleted PATS.

(27) IRM 3.42.5.3.1.2(1), deleted reference to PATS.

(28) IRM 3.42.5.3.2(1), change five (5) to three (3).

(29) IRM 3.42.5.3.2.1, deleted this tridoc.

(30) IRM 3.42.5.6.1, revise paragraphs one (1) and two (2).

(31) IRM 3.42.5.7(4), revised Tax Year to 2012, add three (3) scenarios and deleted last sentence.

(32) IRM 3.42.5.7(6), deleted ETD Retrieval (PATS6824).

(33) IRM 3.42.5.7(7), deleted ETD Retrieval (PATS6824).

(34) IRM 3.42.5.7(8), deleted Test 11.

(35) IRM 3.42.5.7(8), deleted reference to ETD and change five (5) to three (3).

(36) IRM 3.42.5.7.1(1), change five (5) test to three (3) test.

(37) IRM 3.42.5.7.1(1) note, revised year to 2013.

(38) IRM 3.42.5.8.2.1, revised verbiage in this section.

(39) IRM 3.42.5.8.2.1.1, revised verbiage in this section.

(40) IRM 3.42.5.11(1), add an "s" to the word type.

(41) IRM 3.42.5.14(1), change IRM reference to 21.3.1.4.26.

(42) IRM 3.42.5.16, deleted references to Form 8453-OL.

(43) IRM 3.42.5.16.1.1(1), revised year to 2012.

(44) IRM 3.42.5.16.1.1(2), revised Tax Year to 2011.

(45) IRM 3.42.5.16.1.1(5), add Form 8949 information.

(46) IRM 3.42.5.16.1.2(5), revised paragraph.

(47) IRM 3.42.5.16.1.4(3), change IRM reference to 3.42.5.16.18.

(48) IRM 3.42.5.16.3(2), add Form 8949 information to bullet list.

(49) IRM 3.42.5.16.4(1), revised link to http://www.irs.gov/pub/irs-utl/charstatety11_fs12_97716_120911.pdf.

(50) IRM 3.42.5.16.5, revised the Tax Years in the title to 2005 and 2011.

(51) IRM 3.42.5.16.5.1, revised Tax Year in the title and para 1 to 2003 .

(52) IRM 3.42.5.16.5.2, revised Tax Year in the title to 2004.

(53) IRM 3.42.5.16.5.2(1) note, revised Tax Year example to 201112.

(54) IRM 3.42.5.16.5.3, revised Tax Year in the title to 2011.

(55) IRM 3.42.5.16.7(1), correct title of IRM 9.8.1 to Scheme Development Center.

(56) IRM 3.42.5.16.12(1), revise Tax Year to 2004.

(57) IRM 3.42.5.16.19(1), correct title of Publication 1167.

(58) IRM 3.42.5.18.1.1(1), revised link to http://www.irs.gov/pub/irs-utl/charstatety11_fs12_97716_120911.pdf

(59) IRM 3.42.5.19(1), revised paragraph.

(60) IRM 3.42.5.19.1, revised paragraphs in this section.

(61) IRM 3.42.5.19.1.1, revised paragraphs in this section and delete charts.

(62) IRM 3.42.5.19.1.2, revised to a new tridoc.

(63) IRM 3.42.5.21.1(5), correct e-file Bulletin Board telephone number.

(64) IRM 3.42.5.21.2.1, correct word Coordinate in title of subsection.

(65) IRM 3.42.5.23.2(3), revised paragraph.

(66) IRM 3.42.5.23.3(1), removed Prior Year bullet.

(67) IRM 3.42.5.23.3(1) 7th bullet, corrected filing year dates.

(68) IRM 3.42.5.23.4(2), removed the word "and" .

(69) IRM 3.42.5.23.6, added new section.

(70) IRM 3.42.5.23.7, added new section.

(71) IRM 3.42.5.24.1(4), change MITS to IT.

(72) IRM 3.42.5.25.3(1), add ELMS course to seventh bullet.

(73) IRM 3.42.5.25.5(4), added the word "and" .

(74) IRM 3.42.5.25.7, revised title to change Tax Year to 2013.

(75) IRM 3.42.5.25.7(1), revised first and second bullets in list.

(76) IRM 3.42.5.25.8(2), revised date to November 5, 2012.

(77) IRM 3.42.5.25.8(2), revised Tax Year to 2012.

(78) IRM 3.42.5.25.8(6), revised date to November 5, 2012.

(79) IRM 3.42.5.25.12(5), added two new bullets.

(80) IRM 3.42.5.25.12(8), added one new bullet.

(81) IRM 3.42.5.25.13(2), added exception of FLCs.

(82) IRM 3.42.5.25.13(5), added information on Form 2350.

Effect on Other Documents

This IRM supersedes IRM 3.42.5 dated 09/09/2011.

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-2012)

Paul Mamo
Director Submission Processing
Wage and Investment Division

3.42.5.1  (09-06-2012)
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. The Submission Processing Campus where an electronic return is filed may not be the same one where taxpayers would normally mail their paper returns.

  3. 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  (09-06-2012)
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 a taxpayer specifically requests TAS assistance and it meets TAS criteria contained in IRM 13.1.7, refer the case immediately to the TAS office. You must notate on Form 911, Section III:

    • The TAS criteria number

    • The specific circumstances of the hardship

    • The reason you did not provide the relief

  3. Form 911 must be reviewed and approved by an e-help Desk manager or lead before submission to TAS. Submit this request to the Taxpayer Advocate office located in the city or state where you reside.

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

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

3.42.5.1.2  (09-06-2012)
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; or Form 8879, IRS e-file Signature Authorization. Under the disclosure authority granted on the 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:

    In general, the e-help Desk does not answer account-specific questions (i.e., calls received regarding individual tax accounts) but disclosures of return information should be limited to the authority granted to the third party by the taxpayer. The Form 8879 gives 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 a 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  (09-06-2012)
Declaration Control Number (DCN)

  1. The Provider's software assigns a unique fourteen-digit Declaration Control Number (DCN) to each electronic return. The 14 digit DCN is 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  (09-06-2012)
Refunds

  1. Taxpayer refunds can be expected to be issued within the projected dates on the IRS e-file Refund Cycle Chart if the return is error free, has posted to Master File, and the refund is not reduced by outstanding liabilities. Taxpayers can elect to have their refunds deposited directly into their qualifying account at a financial institution. Direct questions regarding refunds to 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  (09-06-2012)
Electronic Returns Systems Overview

  1. e-filing includes:

    1. Modernized e-File (MeF);

    2. Return Request and Display Application (RRD);

    3. Electronic Management System (EMS);

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

    5. 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  (09-06-2012)
Help Desk Web Interface System

  1. The Help Desk Web Interface System (HDWIS) of the EMS provides help desk users (i.e., IRS 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 DataDump of files. Follow the instructions for requesting a Data Dump in the EMS Help Desk Web Interface Tax Examiner (TE) Manual, Section 5.2 “Data Dump” which can be accessed using the EPSS Research Portal under the menu item EPSS - EMS.

3.42.5.2.1.2  (09-06-2012)
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 either federal returns alone, federal returns with state returns attached or certain states alone. For 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.

  3. The state returns are then available for retrieval by participating State Revenue Agencies. Each file of electronic returns transmitted by an electronic filer is normally acknowledged within forty-eight hours of receipt and, if the federal/state return is accepted, the state packet is available for state retrieval within 24 hours of IRS acknowledgment

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  (09-06-2012)
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 three (3) PATS test scenarios that, if supported by the software, all Developers must follow and include when developing their test scenarios. All test scenarios transmitted must be error free before the software can be considered as passed.

  3. A test file consisting of at least three (3) 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.

  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.

  6. The test returns will include the most commonly used forms and schedules accepted for electronic filing.

  7. PATS testing will begin on November 13, 2012.

3.42.5.3.1  (09-06-2012)
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 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 during the testing process. The document includes a list of software limitations 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). If the Federal submission is rejected, the linked state return will be rejected. It is recommended that the state submission is sent after an accepted acknowledgement is received for the Federal return.

  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  (09-06-2012)
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 MeF Business Rule or 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 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 three (3) 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 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 testing of software to be used for processing year 2013, the two digit year will be "12" for Tax Year 2012.

  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 , the assigned 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  (09-06-2012)
E-help Software Acceptance Testing Spreadsheet for Software Packages

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

    • Company Name

    • Testing passed date

    • Developing Companies EFIN

    • 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  (09-06-2012)
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 three (3) 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 three (3) 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 three (3) 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-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  (09-06-2012)
Resetting ACK Files

  1. If the Provider has not received their ACK Files, they can have the ACK Files resent using the instructions in the EMS Trading Partner's Users Manual, Section 10 "Resetting Acknowledgment Files(s)."

  2. The Provider can do so under option (8) on the EMS Main Menu using either the GTX Key or the ACK File Reference Name.

    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  (09-06-2012)
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:

        • Gold Card 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,

    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 2012, has established criteria for three (3) PATS test scenarios and are not to be altered.

  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) to validate return criteria and to identify field entries in error.

  7. The Tax Examiner(s) will utilize PAT Retrieval (PAT1544):

    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. The Tax Examiner(s) will:

    1. Search PAT Retrieval (PAT1544) , 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  (09-06-2012)
PATS Acceptance Procedures: e-help Desk - Communication Testing

  1. Each Transmitter that 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 three (3) tests to one EMS site in two (2) separate same-day transmissions. The e-help Desk Tax Examiner(s) will:

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

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

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

    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 the e-file application stating, "Passed Communications Test" .

    Note:

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

  2. A Transmitter using accepted ETD software that has passed PATS 1 Communications test will not be required to do a Communications Test for PATS 2.

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 applicants 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  (09-06-2012)
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 whether the format of the transmission is fixed or variable. Check the format type indicator in the TRANA record to see if the file was transmitted in fixed (F) or variable (V) format.

  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. From the Utilities menu on the EMS Help Desk screen, you can request a Data Dump of an entire transmission by entering the ETIN with a Julian Filename, GTX Key or Ref. Filename. You can further narrow the request to a single return by entering the SSN under Options.

  3. When the transmission is in variable format, the field number is listed in brackets ([ ]) and followed by the field entries. The Provider transmits significant data fields only, preceded by the field sequence number. (e.g. [0110] 5000 indicates that the entry for field or sequence 0110 is 5000.

  4. Rarely the transmission is in fixed format. To find the field in error, 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 of the transmission and displays the line and column position so that the error can be found.

  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, Site Coordinator will be available to help resolve specific problems.

3.42.5.8.2.1.1  (09-06-2012)
Identifying the Cause of a Rejected Transmission

  1. Identify errors in variable format by comparing the information in 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 unit of data.)

    • 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, four (4) asterisks at the beginning of the record and a # pound sign at the end of the record are missing).

  2. Cross-check the byte count in the record field with the byte count specified in Publication 1346 when the transmission is in 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.

  3. Compare the count of returns in RECAP record with a physical count of the returns in the Data Dump which are located between the TRANB and RECAP records. Each return in the transmission can be identified by the change in the Primary Social Security Number contained in the Record ID of each return.

  4. Compare the count of EFT returns in the RECAP record with a physical count of EFT data in the transmission. Each EFT return can be identified by the presence of any data within the direct deposit fields of Form 1040 lines 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 return.

  5. Compare the count of records in the Summary Record with a physical count of records in the return. Each record is identified by a recognizable and valid Record ID for a particular form, schedule, or statement.

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 ELF 1547, 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 ELF 1557, Federal/State e-file Daily and Year to Date State Count Reports provide federal and state counts fore-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 ELF 1549, 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  (09-06-2012)
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 types 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  (09-06-2012)
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.26, 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

3.42.5.15.3  (10-01-2010)
Unsuccessful Transmission

  1. Providers will receive several messages that determine an "Unsuccessful Transmission" from the FEPS.

  2. If the FEPS software detects that the transmission did not complete successfully, the message "Error receiving file; you must send it again" will be displayed followed by the Main menu from the FEPS. Also, after three consecutive unsuccessful attempts, the Provider will be disconnected. IRM 3.42.5.15.4 describes the various types of Communication Error Messages from the FEPS.

  3. The following are problems associated with unsuccessful log ons.

    • No Logon Received or invalid logon-Provider, log on with invalid login ID and/or password.

    • After three consecutive unsuccessful logic attempts, the TP is disconnected.

    • After six consecutive unsuccessful logic attempts (in 2 or more consecutive sessions) the TP's account is disabled.

    • Suspended Transmitter/ETIN - A suspended transmitter will be allowed to log into EMS to continue to receive acknowledgements, but will not be allowed to transmit new files. After receiving acknowledgement files, the Trading Partner (TP) will not receive the "Do you want to send a file?" prompt. Instead the message "SUSPENDED TRANSMITTER/ETIN" will be displayed, and the TP will be disconnected from EMS.


Next

More Internal Revenue Manual