0126 Publ 5718 (PDF)

Official source: IRS Forms, Instructions & Publications (https://www.irs.gov/pub/irs-pdf/p5718.pdf), retrieved 2026-10-03. U.S. Government work (17 U.S.C. § 105).

---

What’s New for Processing Year 2026

2 Publication 5718

1.1 Purpose ���������������������������������������������������������������������������������������������������������������������� 7

1.2 Communications �������������������������������������������������������������������������������������������������������� 8

1.2.1 IRIS Webpage ��������������������������������������������������������������������������������������������������� 8

1.3 Registration and Application Process ���������������������������������������������������������������������� 9

1.2.2 Chatbot Feature ����������������������������������������������������������������������������������������������� 9

1.3.1 Registration ����������������������������������������������������������������������������������������������������� 9

1.3.2 Applying for an IRIS TCC ������������������������������������������������������������������������������� 10

1.3.3 Third-Party Transmitters ������������������������������������������������������������������������������� 11

1.3.4 Things you need to know before completing the IRIS Application for TCC ������������������������������������������������������������������������������������������������������������ 12

1.3.5 Access the IRIS Application for TCC ������������������������������������������������������������� 13

1.3.6 Application Approved/Completed ����������������������������������������������������������������� 13

1.3.7 Revise Current TCC Information �������������������������������������������������������������������� 14

1.3.8 Deleted TCCs ������������������������������������������������������������������������������������������������� 14

1.4 Transmitter and Issuer TCCs ����������������������������������������������������������������������������������� 14

1.5 Software Developer TCCs ��������������������������������������������������������������������������������������� 14

1.6 API Client ID ������������������������������������������������������������������������������������������������������������ 15

2.1 Definitions and Limitations ������������������������������������������������������������������������������������� 19

2.2 Uniquely Identifying the Transmission, Submission and Records ������������������������ 22

3.1 Application to Application (A2A) Channel Overview ���������������������������������������������� 21

3.1.1 A2A Consent Requirements ��������������������������������������������������������������������������� 22

3.1.2 Access Token Generation for A2A Access Flow ������������������������������������������� 24

3.1.3 Operations ����������������������������������������������������������������������������������������������������� 29

3.2 XML Overview for IRIS �������������������������������������������������������������������������������������������� 35

3.2.1 IRIS XML Schema Package Structure ����������������������������������������������������������� 35

3.2.2 IRIS XML Structure ���������������������������������������������������������������������������������������� 35

3 Publication 5718

3.2.3 Prohibited and Constrained Special Characters ����������������������������������������� 36

3.2.4 Tag Names ����������������������������������������������������������������������������������������������������� 37

3.2.5 Attributes ������������������������������������������������������������������������������������������������������� 38

3.2.6 Repeating Group ������������������������������������������������������������������������������������������� 38

3.2.7 IRIS Schema and Business Rules ���������������������������������������������������������������� 38

3.2.8 Validating Schema Versions �������������������������������������������������������������������������� 40

3.3 Filing Prior Year Returns ������������������������������������������������������������������������������������������ 41

3.3.1 Calculating Total Reported Amount �������������������������������������������������������������� 41

4.1 The Validation Process - What Happens Behind the Scenes �������������������������������� 43

4.2 How to Avoid Common Errors - Pre-Submission Tips ������������������������������������������� 43

6.1 Corrections Process ������������������������������������������������������������������������������������������������ 45

6.1.1 Transmitting Corrections �������������������������������������������������������������������������������� 46

6.2 Rejected Transmissions ������������������������������������������������������������������������������������������ 47

6.2.1 Transmissions Rejected in Pre-Receipt Validation ��������������������������������������� 47

6.2.2 Transmissions/Submissions Rejected by IRIS ���������������������������������������������� 48

6.3 Replacing an Original Transmission that Rejected ����������������������������������������������� 49

6.3.1 Replacing an Original Transmission that Rejected ��������������������������������������� 50

6.3.2 Replacing a ‘Replacement’ Transmission that Rejected ������������������������������ 50

6.4 Replacement Submissions ������������������������������������������������������������������������������������� 51

6.4.1 Replacing Submission Within a Partially Accepted Transmission �������������� 51

6.4.2 Replacing Submission from a Partially Accepted Original Transmission when the Replacements Transmission or Submission was Rejected ������������������� 52

7.1 Request for an Additional Extension of Time to File ��������������������������������������������� 53

7.2 Extension of Time to Provide the Recipient Copy ������������������������������������������������ 53

10.1 Due Dates �������������������������������������������������������������������������������������������������������������� 55

10.2 Help with IRIS Transmissions ������������������������������������������������������������������������������� 57

10.3 Verifying Issuer and Recipient Identity and TINS ������������������������������������������������� 57

10.4 Additional Resources �������������������������������������������������������������������������������������������� 58

The Information Returns Intake System (IRIS) Application to Application (A2A) is a system that uses Extensible Markup Language (XML) format to bulk file large volumes of information returns.

This publication outlines the communication procedures, transmission formats, business rules and validation procedures for information returns transmitted electronically through the IRIS A2A system. Use the guidelines provided in this publication along with the yearly XML schemas and business rules to develop software for IRIS and/or to transmit through the IRIS A2A system. For Tax Year (TY) 2025 in Processing Year (PY) 2026 the following information returns can be filed using IRIS A2A:

• Form 1042-S, Foreign Person’s U.S. Source Income Subject to Withholding

• Form 1097-BTC, Bond Tax Credit

• Form 1098, Mortgage Interest Statement

• Form 1098-C, Contributions of Motor Vehicles, Boats, and Airplanes

• Form 1098-E, Student Loan Interest Statement

• Form 1098-F, Fines, Penalties and Other Amounts

• Form 1098-Q, Qualifying Longevity Annuity Contract Information

• Form 1098-T, Tuition Statement

• Form 1099-A, Acquisition or Abandonment of Secured Property

• Form 1099-B, Proceeds From Broker and Barter Exchange Transactions

• Form 1099-C, Cancellation of Debt

• Form 1099-CAP, Changes in Corporate Control and Capital Structure

• Form 1099-DA, Digital Asset Proceeds From Broker Transactions

• Form 1099-DIV, Dividends and Distributions

• Form 1099-G, Certain Government Payments

• Form 1099-INT, Interest Income

• Form 1099-K, Payment Card and Third-Party Network Transactions

• Form 1099-LS, Reportable Life Insurance Sale

• Form 1099-LTC, Long-Term Care and Accelerated Death Benefits

• Form 1099-MISC, Miscellaneous Information

• Form 1099-NEC, Nonemployee Compensation

• Form 1099-OID, Original Issue Discount

• Form 1099-PATR, Taxable Distributions Received From Cooperatives

• Form 1099-Q, Payments from Qualified Education Programs (Under Sections 529 &

6 Publication 5718

• Form 1099-QA, Distributions from ABLE Accounts

• Form 1099-R, Distributions From Pensions, Annuities, Retirement or Profit-Sharing Plans, IRAs, Insurance Contracts, etc.

• Form 1099-S, Proceeds From Real Estate Transactions

• Form 1099-SA, Distributions From an HSA, Archer MSA, or Medicare Advantage MSA

• Form 1099-SB, Seller’s Investment in Life Insurance Contract

• Form 3921, Exercise of an Incentive Stock Option Under Section 422(b)

• Form 3922, Transfer of Stock Acquired Through an Employee Stock Purchase Plan under Section 423(c)

• Form 5498, IRA Contribution Information

• Form 5498-ESA, Coverdell ESA Contribution Information

• Form 5498-QA, ABLE Account Contribution Information

• Form 5498-SA, HSA, Archer MSA, or Medicare Advantage MSA Information

• Form W-2G, Certain Gambling Winnings

Note: Information contained in transmittal Forms 1096 and 1042-T are included in Submission Headers in IRIS A2A.

The procedures in this publication should also be used in conjunction with the most current version of the following publications:

Publication 4557 - Safeguarding Taxpayer Data: A Guide for Your Business: The purpose of this publication is to provide information on legal requirements to safeguard taxpayer data. The target audience is non-government businesses involved in the preparation and filing of income tax returns.

Publication 5719 - Information Returns Intake System (IRIS) Test Package for Information Returns: This publication contains guidelines and instructions for the IRIS Assurance Testing System (IRIS ATS). IRIS ATS is a process to test software and electronic transmissions prior to accepting Software Developers, Transmitters, and Issuers into the electronic filing program.

Publication 5717 - Information Returns Intake System (IRIS) Taxpayer Portal User Guide: This Publication provides guidance for filing electronically for free through the IRIS taxpayer portal.

Links to IRIS publications and guides are located at www.irs.gov/iris .

The purpose of this document is to provide the A2A specifications to electronically file information returns with the IRS including the requirements and specifications under the Combined Federal/State Filing Program (CF/SF). Additionally, this publication provides specifications to submit an automatic 30-day extension of time to file certain information returns, and the procedure for replacing and correcting returns.

7 Publication 5718

All filers are encouraged to file electronically. If you have 10 or more information returns to file in a calendar year, those information returns must be filed electronically. Corrected information returns MUST be filed electronically if the original return was submitted electronically. Corrected information returns are not counted when calculating the aggregate number of information returns to determine if you are required to file electronically. For more information about the regulations and the reduced threshold to electronically file, refer to the IRS and Treasury’s final regulations on e-file and the Information Returns Intake System (IRIS) web pages.

Filers should keep a copy of information returns (or be able to reconstruct the data) for at least three years from the reporting due date with the following exceptions:

• Returns reporting federal withholding should be kept for four years.

• Keep a copy of Form 1099-C, Cancellation of Debt, for at least four years from the due date of the return.

The Help Desk has been designated as the first point of contact for information return electronic filing issues. Filers can contact the Help Desk toll free at 1-866-937-4130, for domestic calls, or 470-769-5100 (not toll-free) for international calls. The IRS welcomes calls via your choice of relay. Deaf or hard of hearing taxpayers using a relay service may call any of our toll-free numbers. The Help Desk provides assistance in the following areas:

• IRIS Application for Transmitter Control Code (TCC)

• IRIS Assurance Testing System (ATS) software and Communication Testing

• Business rule and schema error resolution

For information regarding IRIS and electronic filing information returns, go to Information Returns Intake System (IRIS) Program webpage: www.irs.gov/iris .

The IRIS page provides:

• Online IRIS System (Production and Testing) Status

• IRIS Program Overview

• IRIS ATS Information

• Links to access IRIS Publications, Schemas, Business Rules, Known Issues and Solutions.

If you encounter a problem or limitation that prevents you from filing electronically through IRIS, check the IRIS known issues and solutions | Internal Revenue Service webpage to see if it is a system error that has been identified and if there is a workaround. If nothing is posted, please call the Help Desk for further assistance. If the Help Desk does not have a resolution they will elevate your inquiry to the IRIS Team. The IRIS Team will research and

8 Publication 5718

determine the appropriate actions. Until a solution can be implemented, IRIS may develop a temporary workaround to allow the return to be transmitted electronically. Known Issues and solutions will be posted by Tax Year (TY).

IRIS uses QuickAlerts, an IRS e-mail service, to disseminate information quickly regarding IRIS issues to subscribers. This service keeps tax professionals up to date on IRIS issues throughout the year, with emphasis on issues during the filing season. After subscribing, customers will receive “round the clock” communication and get updates on issues, changes and working group meetings about IRIS. New subscribers may sign up for QuickAlerts at E-fle information returns with IRIS | Internal Revenue Service .

Use the IRS Automated Chatbot/Live chat feature, please visit Filing Information Returns Electronically (FIRE) | Internal Revenue Service. Click the Chat bubble in the bottom right corner.

• Chatbot is available 24/7.

• Escalation to live chat is available Monday through Friday 8:30 a.m. – 5:30 p.m. E.T.

• Get answers to your questions about transmitter control codes and filing information returns electronically.

• For account-specific questions, you need an IRS (ID.me) account.

External users must register with the current IRS credential service provider and complete the IRIS Application for Transmitter Control Code (TCC) to submit transmissions using the IRIS intake platform. Information returns filed through the IRIS A2A system cannot be filed using any other intake platform TCC. These include:

• e-File Application (MeF)

• Affordable Care Act (ACA) Application for TCC (AIR)

• Partnership Bipartisan Budget Act (PBBA) Application for TCC

• Information Returns (IR) Application for TCC (FIRE)

• IRIS TCC for the Taxpayer Portal

Before completing the IRIS A2A TCC Application, each user must create an account or sign-in using their existing credentials to validate their identities using the latest authentication process.

For more information, please visit How to register for IRS online self-help tools | Internal Revenue Service .

9 Publication 5718

If you are transmitting information returns to the IRS or if you are developing software to file information returns electronically, you must submit the IRIS application for TCC for authorization and TCC(s) assignment. Refer to Publication 5903, IRIS App for TCC Tutorial.

Allow up to 45 calendar days for application processing. You may check the status of your application and TCC(s) on the Application Summary page.

A single application can be used to apply for multiple roles and the necessary TCCs. In IRIS, you do not need a different TCC for different form types. The IRS encourages transmitters who file for multiple issuers to submit one application and use the assigned TCC for all issuers. The purpose of the TCC is to identify the business acting as the transmitter of the file. As a transmitter, you may transmit files for as many companies as you need to under one TCC. The IRIS A2A TCC Application contains three separate roles: Software Developer, Transmitter, and Issuer. Complete the IRIS A2A TCC Application if your firm or organization is performing one or more of the following roles:

• Software Developer : An organization writing either origination or transmission software according to IRS specifications.

• Transmitter : A Third-Party sending the electronic information returns data directly to IRS on behalf of any business.

• ( Note: If you are transmitting returns for your own company, in addition to transmitting returns on behalf of another business, you do not need both the Transmitter and Issuer role. You can file all returns as a Transmitter.)

• Issuer : A business filing their own information returns using the same EIN as on the TCC application. (If a Sole Proprietor wants to file information returns using their SSN, then you must select Transmitter role.)

Note: Issuers and Transmitters are collectively referred to as transmitters throughout this document unless specifically state otherwise.

These roles are not mutually exclusive. An organization may be both a Transmitter and a Software Developer. Each role will receive its own TCC to be used based on the activity being performed. Software Developers performing Testing will use the Software Developer TCC. Do not use the Software Developer TCC to transmit Production files.

Note: If an organization requires more than one TCC for any given role, a Responsible Official (RO) listed on the application should request an additional TCC by clicking on the ‘Request’ option under ‘Request Additional TCC’ on the Application Summary Page.

The table below provides examples of who should apply for a TCC.

10 Publication 5718

*Not all software supports corrections and/or replacements. Prior to purchasing IRIS software, make sure it meets your business needs.

If you do not want to develop or purchase software then you can file through a Third-Party Transmitter or use the online IRIS Taxpayer Portal. Visit www.irs.gov/iris for additional information.

11 Publication 5718

If using a Third-Party Transmitter, note that some may not support all IRIS capabilities (e.g., corrections and/or replacements). It is your responsibility to ensure your business needs are supported. Only the transmitter will be able to communicate with the IRS about your transmissions. It is important that you obtain the following from the transmitter for each submission filed on your behalf:

• A copy of all electronic records within each submission, along with the Receipt ID for the transmission in which they were filed.

• The transmission Acknowledgement that includes the Status that is returned when processing is complete (Accepted, Accepted With Errors, Partially Accepted, Rejected) and a detailed list of errors, if any.

Note: The items cited above are critical to your ability to make corrections should your Thirdparty Transmitter go out of business or be otherwise unavailable to file corrections on your behalf.

A Responsible Official (RO) initiates and submits the IRIS Application for TCC electronically. Each RO must sign the terms of agreement using their five-digit PIN they created when they initially accessed the system. An application will receive a tracking number after saving it. Completing the application in a single session isn’t a requirement.

The following information is necessary to complete each application:

• Firm’s business structure

• Firm’s (EIN) (the system doesn’t allow firms to use a Social Security Number (SSN) or Individual Taxpayer Identification Number (ITIN)

• Firm’s legal business name and business type

• Firm’s doing business as name when it’s different from the legal business name

• Business phone number (including country code and area code)

• Business address (this must be a physical location, not a post office box)

• Mailing address when different than business address

• RO, contact and authorized delegate if applicable information must include: SSN or ITIN

• Date of birth

12 Publication 5718

• Contact information, including email address, position/title and phone number

• Know the correct Role as defined in Section 1.3.2.

• At this time, the only option to select is Form 1099 Series, which includes all forms listed above in the Introduction

• Know the transmission method you will use

After the approval of your application, a five-character alphanumeric TCC will be assigned. The IRS will send a letter with this information to the mailing address on your application. You may sign into your IRIS Application for TCC to monitor the status of your application and view your TCC(s). The Application Summary page usually is viewable within 48 hours of applying however, it may take up to 45 days.

If you would like to use IRIS A2A, you must complete the following steps:

1. Go to IRIS TCC

2. Click on the Access Application for TCC button

3. Sign in or create an account to begin the application process (you don’t need to create an account if you already have one)

4. Select Individual on the Select Your Organization page

5. Click on New Application and select IRIS Application for TCC

6. Complete and submit an IRIS Application for Transmitter Control Code (TCC)

Each RO must sign the Application Submission page using their 5-digit PIN. The application will be processed after all ROs have entered their PIN and accepted the Terms of Agreement.

If you forgot your PIN, select the Modify PIN tab located at the top of the screen to create a new PIN.

7. Allow up to 45 calendar days for application processing. You may check the status of your application and TCC(s) on the Application Summary page which usually is viewable within 48 hours of applying however, it may take up to 45 days.

If you are unable to complete your application during your session, follow steps 1–4 above to access your saved application.

When your IRIS Application for TCC is approved and completed, a five-character alphanumeric TCC that begins with the letter ‘D’ will be assigned to your business. An approval letter will be sent via the United States Postal Service (USPS) to the address listed on the application, informing you of your TCC. You can also sign into your IRIS Application for TCC to view your TCCs on the Application Summary page.

13 Publication 5718

If your application is in Completed status for more than 45 days and your TCC has not been assigned, contact the Help Desk.

As changes occur, you must update and maintain your IRIS TCC Application. Some changes will require all ROs or Authorized Delegates (ADs) on the application to re-sign the Application Submission page. Below are examples of when an application would need to be re-signed (this list is not all inclusive):

• Firm’s DBA Name change

• Role changes or additions

• Add, delete or change RO and/or AD

Note: Changes submitted on an IRIS TCC Application do not change the address of IRS tax records just as a change of address to IRS tax records does not automatically update information on an IRIS TCC Application.

Changes that require a firm to acquire a new Employer Identification Number (EIN) require a new IRIS TCC Application. Firms that change their form of organization, such as from a sole proprietorship to a corporation, generally require the firm to acquire a new EIN.

TCC(s) remain valid unless unused for three consecutive years. Once a TCC is deleted, you must apply for a new TCC. IRIS Application for TCC .

Depending on the roles selected on the application, one or more TCCs will be assigned. Each TCC will have an indicator of Test “T” or Production “P” and status of Active, Inactive, or Dropped. Transmitters and Issuers are issued a TCC in Test “T” status until required Communication Testing is conducted in the ATS environment and passed. Once Communication Testing is passed, the Transmitter should contact the Help Desk to request to be moved to Production “P” status. For more information about Communication Testing for Transmitters, refer to Publication 5719, Information Returns Intake System (IRIS) Test Package for Information Returns.

After selecting the Software Developer role on the application, additional information about the software package being developed is required. A software developer TCC is permanently assigned in “Test” status. A separate Software ID is also assigned for each package. The tax year(s) for the information returns supported, form type, and software package type (Commercial Off the Shelf (COTS), Online, In-house) are also required. Each Software Package and form type has a separate status.

14 Publication 5718

Software Package information must be updated annually through the IRIS Application for TCC . New Software IDs will be assigned for each tax year. To update your application, the Responsible Official should go to the Software Packages page and click the “Add Software Package” button which is located towards the bottom of the page. For more information about Software Testing for Software Developers, refer to Publication 5719, Information Returns Intake System (IRIS) Test Package for Information Returns.

All IRIS A2A users will need to create, develop, or purchase software to use the A2A transmission method. The IRIS A2A Channel uses the API Client ID to authenticate and authorize access to IRIS A2A services. After you receive your IRIS TCC, you must complete an API Client ID Application which will allow your software to communicate directly with IRS systems. To receive a API Client ID for IRIS A2A services, the following actions must take place:

1. Go to www.irs.gov/iris and select Get an API Client ID under Steps to use IRIS A2A. You will be redirected to Get an API client ID .

2. Click on the Sign in or create an account button to complete or modify your application.

3. Select Individual on the Select Your Organization page or access your existing Client ID Application if you already have one.

Exception: You must create a new Client ID if your existing Client ID Application is only for Income Verification Express Services (IVES) Forms Based Processing (FBP).

4. Click on New Application and select API Client ID Application to begin a new application.

5. To modify your existing application, select your API application under All Applications to access the Application Details page.

a. Select the edit icon and check the IRIS box under Select APIs, then resubmit your

application.

b. If there are no errors, you will see the Submission Complete page. Return to the

Application Details page to view your IRIS Client ID.

6. Each Client ID will need a JavaScript Object Notation (JSON) Web Key Set (JWKS) to be uploaded to the application and validated before the Client ID will be issued. Review the following instructions to complete the process.

You will have the opportunity to save your application if you do not have all the required information. Once the application is saved, you may come back at your convenience.

Note: Continue to select Individual from the Select Your Organization page to access your new application, until the application has gone to completed status.

15 Publication 5718

While completing the application, you will need to provide the JWKS file with use of valid X.509 digital security certificate. The certificate will be validated during the application process. Your Client ID will be provided to you at the time of registration. A JSON Web Key Set (JWKS) that represents a cryptographic key is used for e-Services API authentication. It contains a public key that validates the API consumer application. JWKS will have the following criteria:

• Contain a public key using RSA algorithm. RSA provides a key ID for key matching purposes.

• Should contain X.509 certificate using both “x5t” (X.509 SHA-1 Thumbprint) and “x5c” (X.509 certificate Chain) parameters.

{ You are not allowed to use self-signed certificates.

{ You can use the same public certificate as used for other IRS programs such as MeF or AIR.

• For more information on Digital Certificates visit Digital Certifcates | Internal Revenue Service

The set of JWK attributes need to be pasted into the JSON Web Key (JWK) section of your application following these guidelines:

• Must be in the order listed below

• Remove any attribute names not in the list below

• Paste the full JWK including all the beginning ‘{‘ and ending curly braces ‘}’ to avoid errors

• A text editing tool may be useful when rearranging and/or removing attributes not listed below

• Please refer to ‘Figure 1-1’ for a JWK example

• The attributes expected in JWK are:

{ “kty”: Key Type (must be RSA)

{ “kid”: Key ID

{ “use”: “sig” Public Key Use

{ “n”: the modulus

{ “e”: “AQAB” the public exponent

{ “x5c”: X. 509 Certificate Chain

{ “x5t”: X.509 Certificate SHA-1 Thumbprint

16 Publication 5718

Note: If any of the above attributes are missing from the JWK, the JWK will be invalid. Please refer to Figure 1-1, which contains an example of an RSA key represented as JWKS. Paste the full JWK including the beginning ‘{‘ and ending curly braces ‘}’ to avoid errors. If there are no errors, you will see the Submission Complete page and you will be able to view the issued Client ID.

Figure 1-1: JWK Example

• It is your responsibility to keep track of the JWK expiration date and provide a new one once the current JWK expires. The JWK expiration date is tied to the certificate expiration date. There are various methods for checking a certificates expiration date. As one example, you can double-click the public cert file on your computer as shown is Figure 1-2.

17 Publication 5718

Figure 1-2: Example of Saved Certificate

• This will open up the certificate where the valid dates are shown, the expiration date is the end date. See the example in Figure 1-3.

• For more information on JWK visit RFC 7517

Once the application is completed, the Responsible Official or Contact will need to sign in and obtain the API Client ID(s) issued to the firm/organization. The API Client ID(s) will be listed on the Application Details or Application Summary pages.

For any questions related to the API Client ID Application, contact the Help Desk.

A transmission is an XML payload containing the Manifest with one or more submissions containing one or more records. The Manifest contains information about the Transmitter and transmission.

A submission is defined as the combination of the records (information return) associated with that submission group. For example, Form1099ADetail is filed with IRSubmission1Grp, Form1042SDetail is filed with IRSubmission3Grp and the associated records (information returns). Table 2-1 shows the IRIS schema structure.

IRTransmission

IRSubmission1Grp

Transmission Requirements :

• Must consist of one or more submissions. If a Transmission has multiple submissions, they may be a combination of any submission group, form type and issuer. (The schema package contains samples of transmissions with different submission groups, forms, and issuers)

• Each Submission must have the same form type within the submission

• Each submission must be for the same tax year

• Must not contain multiple Transmission types (Original, Correction, and Replacement)

• The size of the transmission should not exceed 100MB

• Must include the “ TransmissionTypeCd ” that identifies the type of transmission as follows:

Table 2-2: Transmissions Types

19 Publication 5718

Submission Requirements:

• The reported number of information returns on the submission header must match the actual number of information returns in the submission

• Must not contain records of different form types or tax years

• May contain as many records as the 100MB payload size allows

• May include only the form type allowed for that submission group. For example, Submission1 Group contains all Forms 1099. Submission 2 Group is only for Form

8809. Submission 3 Group is only for Form 1042-S.

Note: Please see the XML examples of IRIS transmissions in the IRIS schema package.

The XML Schemas include elements designed to uniquely identify information return transmissions, submissions within the transmission, and records within the submission.

Transmitters must identify each transmission with a Unique Transmission Identifier (UTID). The format for the UTID includes various fields separated by colons (:) as follows: da20a4de1357-11ed-861d-0242ac120002:IRIS:00000::A.

• Universally Unique Identifier (UUID) - is an identifier standard defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 4122. It is a mandatory field and is represented by 32 hexadecimal digits, displayed in five groups separated by hyphens. da20a4de-1357-11ed-861d-0242ac120002

• Application ID - the Application ID will be hardcoded IRIS and is a mandatory field

• Transmitter Control Code - is an uppercase alphanumeric field that will contain the Transmitter’s TCC and is mandatory

• Reserved - is an empty field (no space between colons). *This is for future use and is intentionally blank

• Request Type - the Request Type defines the type of request, A for A2A

Every transmission that IRIS receives is validated to ensure that the UTID is unique (has not been previously submitted to the IRIS System, including previously submitted rejected returns) and conforms to the pattern assigned in the XML Schema.If a UTID is missing and not unique, the transmission is rejected, and no further processing occurs.

Along with a UTID for the transmission, each submission must have a unique Submission

20 Publication 5718

Identifier (SID) and each record a unique Record Identifier (RID). For every transmission that passes initial validation, IRIS returns a Receipt ID with the UTID and a Timestamp for the transmission. The Receipt ID is key information that should be kept with the transmission and protected from loss or deletion. The ReceiptId, along with the SubmissionId and the RecordId create the identifiers used to submit replacements and corrections. (See Section 6, Corrections and Replacements for more details.) For example, to replace a rejected submission and the original submission are uniquely identified by combining the transmission ReceiptId and SID, using the pipe symbol as separator.

OriginalUniqueSubmissionId = RECEIPTID|SID

To correct accepted or accepted with error records, the transmission ReceiptId, SID and RID are combined with the pipe symbol as separator: UniqueRecordId = RECEIPTID|SID|RID

The Original Unique Submission Identifier (OUSID) and Unique Record Identifier (URID) enable:

• Transmitters to send replacement submissions and corrected records to the IRS

• Both IRS and Transmitters to track transmissions, submissions and records.

This section provides an overview of how to transmit information returns to the IRS through IRIS, including the technical requirements and step-by-step process.

What You Need Before Starting: To transmit via the A2A channel, Transmitters must have:

• An active IRS e-Services account

• IRIS A2A Transmitter Control Code (TCC)

• IRS approved software for submitting returns and retrieving acknowledgments

How A2A Communication Works: The A2A channel uses REST (Representational State Transfer) APIs - these are web-based tools that allow your software to communicate directly with the IRS systems using standard internet protocols (HTTPS). REST APIs are a standardized way for computer systems to “talk” to each other over the internet.

Step-by-Step Transmission Process:

1. Security Check: The IRIS system first verifies your identity and checks for security threats

2. Initial Validation: IRIS performs basic checks on your transmission format

3. Error Response: If problems are found, you’ll receive an immediate error message explaining what went wrong

4. Success Response: If everything looks good, IRIS returns three important pieces of

21 Publication 5718

information:

{ Receipt ID (your confirmation number)

{ Unique Transmission ID (UTID - your tracking number)

{ Timestamp (when IRIS received your transmission)

What you’re actually sending: Your transmission is an XML document (a structured text file) that contains your information returns. This document is packaged as an attachment within the REST message system. The Receipt ID or the UTID is the key information required for a Transmitter to retrieve the acknowledgement for the respective transmission.

Note: The Receipt ID returned to the Transmitter should be kept with the transmission and protected from loss or deletion.

If the Transmitter does not receive the Receipt ID for some reason (e.g., the session times out or is terminated) or it is accidentally lost or deleted, request the Acknowledgement File using the UTID. New for TY2025, the TransStatusOrAckResponse will include the ReceiptId if the request SearchParameterTypeCd is UTID (unless the TransmissionStatusCd is “Not Found”). Filers no longer need to call the Help Desk for a missing Receipt Id. Figure 3-0 shows TransStatusOrAckResponse when UTID is in request. before calling the Help Desk to request the Receipt ID for the transmission. The IRIS Help Desk assister will require the user to identify themselves and the UTID for the transmission in question to provide the respective Receipt ID.

Figure 3-0: Sample of TransStatusOrAckResponse with UTID and ReceiptId

For A2A Client IDs to execute e-Services API transactions on behalf of e-Services users, Transmitters must first grant access to the A2A Client ID before a client can request an access token on their behalf.

Transmitters must complete the following steps to grant access:

1. Login to IRS Consent App .

Note: When logging into the consent app, select the organization associated with your IRIS TCC application on the Select Your Organization page (Do not select your API application.)

2. Select Setup on the API Authorization Management page.

3. Enter your IRIS Client ID on the A2A Authorization page.

22 Publication 5718

If you have multiple Client IDs, please use the Client ID that was assigned to you for IRIS. You can sign into your API Client ID Application to retrieve your IRIS Client ID on the Application Summary page.

4. Grant access to TEST, which is needed to test software and electronic transmissions in the IRIS ATS environment.

5. Grant access to PROD, which is needed to transmit live return data in the production environment.

6. Retrieve your full IRIS UserID from the A2A Setup Complete page. Make note of the UserID. Example of UserID format: “dasmith-345870”.

Your full IRIS UserID must be used to generate access tokens in Section 3.1.3, Access Token Generation for A2A Access Flow .

For any questions related to the API Client ID Application, contact the Help Desk.

The authorization process for the IRIS endpoint is a token-based authentication scheme following the OAuth authorization access framework. Transmitters will use JSON WEB TOKENS (JWTs) for both Client Authentication and Authorization Grants. Two JWTs must be provided when requesting an access token.

• Client JWT – This JWT should represent the client and will be used to authenticate the client.

• User JWT – This JWT should represent the resource owner/user that the client is requesting an access token for.

For more background on OAuth and/or JWT Profile(s) for OAuth, please review the following RFCs:

• RFC-6749

• RFC-7523

In A2A flow, the client application requests an access token from the IRS server for API

23 Publication 5718

access on a user’s behalf. The IRS server verifies the two JWTs using the key(s) the transmitter provided in their JWK file on the API Client ID Application. If the JWTs are valid the IRS server will then verify that the user identified in the User JWT has provided consent to the client identified in the Client JWT to run transactions on their behalf. Figure 3-1 shows steps including the generation of the access token.

Figure 3-1: A2A OAuth Flow – Diagram

The A2A flow illustrated in Figure 3-1 consists of the following steps including the generation of the access token:

Step 0 and 01 : The A2A Client App must issue two JWTs and they must be signed with private keys to validate assertion. The JWTs should be in JWT token format using the following for the header and payload claims:

Header

• kid (key identifier) – Identifies the key the client used to sign the JWT.

24 Publication 5718

Note: The kid should match the kid that was provided in the JWK file on your API Client ID Application. The kid is also case sensitive.

• alg (algorithm) – Identifies the algorithm used to sign the JWT.

Note: RS256 is the supported/expected algorithm.

Payload

• iss (issuer) – Identifies who issues the token. Must include the Client ID obtained at registration.

• sub (subject) – Subject of the token. Must include:

{ The Client ID for Client JWT token type

{ Example of User ID format “dasmith-345870”.

{ Retrieve your Full IRIS UserID by following the steps in Section 3.1.2, A2A Consent.

• aud (audience) – the IRS authorization server. The token endpoint of the auth server

• iat (issued at time) – Optional. Issued at time. Numeric value of the time the token was created

• exp (expiration time) – Numeric value of the time when the token expires. It must be valid for 15 minutes. “iat” and “exp” must be notated in Epoch time

{ “iat” and “exp” time is 15 minutes

{ “iat” and “exp” times cannot have a “.” in it. (e.g. 16705993.36)

• jti (JWT ID) – Required. Provides unique identifier for each JWT. It prevents the JWT from being replayed. This is required by the IRS API Gateway.

Note: In addition to the required claims above, the JWT header should include the “alg” and the “kid” claims, otherwise the JWT will be invalid.

The JWT Grant type request will have the following parameters:

• grant_type – required, value should be “jwt-bearer”

• Assertion – required, JWT value

• Client assertion type – required, value should also be “jwt-bearer”

• Client assertion – required, JWT value

Step 1: The A2A Client App requests API access using the URL token endpoint : https://api.www4.irs.gov/auth/oauth/v2/token

The A2A Client App is required to provide the parameters in Table 3-1.

Table 3-1: Token Endpoint – Parameters

25 Publication 5718

The example in Figure 3-2 shows A2A authorization URL login endpoint .

Figure 3-2: Login endpoint HTTPs request – Example

The client app sends over an access token request using a client ID and signed JWT tokens.

Example in Figure 3-3 shows an access token /refresh token POST request sends the JWT tokens.

Note: The example below is using the test endpoint. JWT is represented as XXXX.XXXX. XXXX be sure to replace them with your JWTs before running the example.

26 Publication 5718

Figure 3-3: Access Token\Refresh Token POST request – JWT Grant Type Examples

Step 2 : If authenticated successfully, the token server will respond with an HTTP 200. The body of the response will contain an access and refresh token.

The HTTP response with 200 (OK) status will contain the following parameters as defined in Table 3-2.

Table 3-2: Success Response Parameters

The basic structure of a response is a JSON object that holds the response information. Figure 3-4 shows an example of a successful response.

27 Publication 5718

Figure 3-4: Access Token Successful Response - Example

Step 3 : The A2A Client App now has an access token which can be used to call the IRS A2A endpoints.

Step 4 : The e-Services API server checks the access token in the app’s request and decides whether to authenticate the app.

Step 5 : The e-Services API resource sends response successfully.

28 Publication 5718

Notes

• An Access token and Refresh token are received by the transmitter as a result of successful user validation.

  • Access tokens expire 15 minutes after they are issued.

{ You do not need to request a new Access token during a transmission that takes longer than 15 minutes. The access token only needs to be active when the transmission is initiated.

• Refresh tokens expire 60 minutes after they are issued.

{ Refresh tokens have a longer time limit and are used to obtain new access tokens. Refresh tokens will become inactive when you log out.

• You can use access tokens on as many requests as needed as long as the token is still active. You can use your software to leverage the “expires_in” data that is provided when the token is issued and retrieve a new access token as expiration nears.

For any questions related to the API Client ID Application, contact the Help Desk.

This request allows a transmitter to submit information returns using A2A. Details for the request and response message are provided in Table 3-3 and Figures 3-5 to 3-8.

Use the following:

• Live Endpoint: Production environment

• Test Endpoint: ATS environment

Table 3-3: Submit A2A Transmission

REQUEST

29 Publication 5718

REQUEST

Figure 3-5: A2A Intake Acceptance Illustrative Request

Curl Command Guidance:

curl -i -k -X POST -H “Content-type: multipart/form-data” -H “Authorization: Bearer KEY_IN_ YOUR_TOKEN” -F “file=@YOUR_1099_PAYLOAD_IN_XML_FORMAT; type=text/xml” https:// host_url/irisa2a/v1/intake-acceptance

30 Publication 5718

Note: Ensure that your xml payload is in the same location (folder) where the curl command will be executed. For example: if you execute curl from C:\IR Folder, your xml payload must be in the same folder which looks like C:\IR Folder\1099MISC.xml.

Figure 3-6: A2A Intake Acceptance Illustrative Response – Receipt ID has been generated

31 Publication 5718

Figure 3-8: A2A Intake Acceptance Illustrative Response – 500 Internal Service Error

This request allows a transmitter to retrieve status and acknowledgement using A2A. Details and response messages are provided in Table 3-4 and Figures 3-9 to 3-11.

Use the following:

• Live Endpoint: Production environment

• Test Endpoint: ATS environment

Table 3-4: GetStatus/Ack

REQUEST

32 Publication 5718

REQUEST

Figure 3-9: XML Format Get Status/Ack Illustrative Request

33 Publication 5718

Figure 3-10: XML GetStatus/Ack Illustrative Response – 200 Status Response

Figure 3-11: A2A GetStatus/Ack Illustrative Response – 400 Bad Request Response

34 Publication 5718

IRIS uses XML, a language that specifies the structure and content of electronic documents and files to define the electronic format of IRIS Information Returns. This section explains some of the elements of an XML document. For detailed information, refer to the IRIS schema package.

This section describes the IRIS XML Schema file structure and how the schemas will be packaged as of the date this publication was issued.

The IRIS XML Library includes the following folders and files:

• COMMON

{ IRS-IRefileTypes.xsd defines simple and complex elements that are reused across the XML payload.

• FORM_TYPES

{ There is a file for each Information Return form, for example IRS-Form1099AType. xsd defines the schema for Form 1099-A.

• MSG

{ IRS-IRIntakeTransmissionMessage.xsd defines complex elements at the Transmission (manifest) and Submission levels. It also defines fields from Submission level forms like Form 1096.

In addition to the schema files, there are business rule files. To request IRIS schema and business rules, please see information at: www.irs.gov/irisschema

The IRIS XML payload is structured in three levels:

1. Transmission: A manifest with information on the transmitter and software used to prepare the package. Contains one or more submissions.

2. Submission: Details the type of form, transmittal form elements, and total of form values (if applicable). Contains one or more forms.

3. Form: Details the form data elements.

35 Publication 5718

When entering character data into an XML document, it is important to ensure that the specified encoding supports the characters provided. By design, IRIS uses Unicode Transformation Format-8 (UTF-8), without Byte Order Mark (BOM). IRIS does not support any other encoding scheme (for example, UTF-16 and UTF-32).

Software Developers and Transmitters must not include certain special characters in any character data included in the XML of the REST message. The following special character must not be included in any of the data fields:

Table 3-5: Special Character Not to Be Included in Any Data

Character Character Description

-- Double Dash

IRIS will reject a transmission that contains the special character identified in Table 3-5.

• Example : If a record has an address data field containing NoPlaceWay--Suite 4, then the transmission must not include the double dash, so that the data field instead contains NoPlaceWay-Suite 4 .

The following special characters must be escaped before they are included in any data fields that allow the characters:

Table 3-6: Allowable Characters

Character Character Description

Character

Allowed?

Escape Characters

Escape Character

Allowed

& Ampersand Rejected & Allowed

‘ Apostrophe Rejected ' Allowed

< Less Than Rejected < Allowed

“ Quotation Mark Rejected " Allowed

• Greater Than Allowed > Allowed

Additional elements may also be restricted by XML schema data element definitions. For

36 Publication 5718

example, “ PersonFirstNm”, “ PersonMiddleNm ”, and “ PersonLastNm ” cannot contain any special characters except “-“. If a record being put into “ PersonLastNm ” has a last name containing an apostrophe, such as “ O’Malley ”, the transmission cannot include the apostrophe or the escaped apostrophe characters. The apostrophe must be stripped, and the last name data must be entered as “ OMalley ”. The transmission will be rejected if the apostrophe is used. Another example is the # character. It is permitted in Business Name but not for Person Name. As a rule, the schema definitions must be followed.

Each field in the transmission is identified using an XML tag name within the XML schema.

Tag names were created using the following conventions:

• A meaningful phrase with the first letter of each word capitalized and using no spaces (upper Camel case)

• A length of not more than 30 characters

• Standard abbreviations to meet the tag name 30-character limit

The Tag Names, also known as Element Names, were standardized by IRS for all information return forms. A notional example of a simple XML element that identifies an additional recipient name would be:

<xsd:element name=“AdditionalRecipientTxt” type=“NameTextType” minOccurs=“0”>

A notional example of a complex XML element that identifies all the data element groups allowed directly in a transmission.

Figure 3-12: IRTransmission Schema Structure

37 Publication 5718

Attributes provide additional information or describe a constraint of a data element.

• The first letter of the first word of an attribute name is lower case; the first letter of each subsequent word is capitalized (lower camel case).

For instance, in the example of the complex XML element IRSubmission1Grp above, the attribute maxOccurs=”unbounded” identifies that there is no limit to the number of IRSubmission1Grp(s) that can be included in the XML. (However, the maximum number of submissions is constrained by the payload size limit of 100MB.)

Repeating groups are specified in XML schema definitions using the minOccurs and maxOccurs facets on sequence or choice definitions. An example of a repeating group is as follows:

<xsd:element name=“Form1099ADetail” type=“Form1099ADetailType” minOccurs=“1” maxOccurs=“unbounded”/>

This element Form1099ADetail allows a minimum of 1 and a maximum of unlimited repeated Forms1099ADetail. Beginning and ending tags are necessary for each group submitted. Since the minimum is zero, any of the Submission Groups may be used. Submission1Grp might not be used but rather the Submission2Grp or Submission3Grp. (While the Submission Groups are optional, IRIS will reject a transmission if no submissions are included.)

The reference element is of Type IRSubmission1GrpType. This is a complex data element that includes complex elements IRSubmission1Header and IRSubmission1Detail.

A schema is an XML document that specifies the data elements, structure and rules for the transmission, submission, and form levels. In addition to formats defined by schemas, information returns must also adhere to business rules, which provide a second level of validation for information returns processed by the IRIS System.

IRS created one XML schema for the Transmission and Submission levels and one XML schema for each form. Each schema also has a respective set of business rules that are used during IRIS validation.

Within the XML schema, data elements are the basic building blocks of an XML document. Schemas recognize two categories of element types: simple and complex. A simple type element contains only one data type and may only have documentation attributes, such as description or line number. A complex type element is an element that has one or more attributes or is the parent to one or more child elements.

38 Publication 5718

The Transmitter and Issuer have the responsibility to provide information as specified by IRS forms, instructions and regulations. Note: The software used to transmit IRIS documents to IRS must be capable of putting the information in the specified schema while also abiding by all applicable business rules.

All data elements present by virtue of an opening and a closing tag should contain a value. Do not include tags for optional data elements that are empty.

Each year, new legislation and/or improvements to IRS programs impact IRS forms and processing procedures. IRS evaluates these changes to determine if updates to the XML schemas and business rules are necessary.

When the IRIS schemas and business rules are available, the IRIS schema and business rule page on irs.gov will explain how to request them through eServices. IRIS schemas and business rules | Internal Revenue Service . Software Developers are not required to retest updated versions for a given tax year. However, IRS strongly recommends the use of IRIS ATS to retest when software is updated.

Note: If there are critical changes required due to late legislation changes, national disasters, or errors identified during testing or production, IRS may issue updated XML schemas and business rules after December and during the processing year.

General Information about Version Numbers follows:

Prior to TY2025, the IRIS schema VersionNum and VersionDt were in the metadata of the IR-IntakeTransmissionMessage. Beginning TY2025, the schema VersionNum and VersionDt are manfiest elements and must be included in the payload as shown in Figure 3-13. TY2025 will be v2.0.

• Each information return’s schema version has an associated set of business rules. There may be additional business rule changes so the latest business rule version and schema version number may differ.

• The “Form nnnn DetailType” complex element includes a documentation element and dictionary entry name as well as the effective begin date for the XML Schema as shown in Figure 3-14.

Figure 3-14: IRIS Form 1099-NEC Detail Type Documentation

39 Publication 5718

• Each business rule document’s version number identifies the latest version in effect.

• The “Active Validating Schema Version” specifies the business rules and schema version that will be used to validate an information return that has been received by IRS during a timeframe. This provides a mechanism for different versions to be accepted at the same time. It also enables an older version to be validated against a newer version’s set of schemas and business rules.

Throughout the year, multiple versions of XML Schemas and Business Rules may be available depending upon whether a change to the schema is major or minor. IRIS may not require that the schema version used to submit the return data match the schema version used by IRIS during validation. In general, there is one active validating schema version for each return type in a tax year. The Schema/Business Rules page will include the Start dates, if applicable, for ATS and Production. IRS strives to limit the number of schema and/or business rule revisions, especially after production opens. A Quick Alert is issued when a new version of the XML schemas and business rules is available through the e-Services mailbox.

Minor Schema Changes - When IRS issues revised schemas for an information return type and changes the increment for the minor number, IRIS continues to accept returns composed using previous schema versions. When the minor number is changed, IRS allows Software Developers to decide for themselves whether they need to use the latest version or not based on what is included in their tax preparation software and what changes were made to the schemas.

Returns may be composed using previously published schema versions, but IRS will only validate against the “active validating schema version” when the return is processed. For example:

If the current schema version is 1.0 and the schema change is minor, IRS will assign the new number 1.1. The active validating schema version is 1.1. IRIS will continue to accept returns composed using version 1.0. However, all returns (whether composed with version 1.0 or 1.1) will be validated with the latest version, 1.1.

Major Schema Change - When IRS issues revised schemas for an information return type and changes the increment for the major number, all returns must be composed by software using the latest version. If information returns are composed using previously published schema versions, they will not validate against the active validating schema version when the return is processed and will be rejected.

For example, if the current version is 1.1 and IRS determines it can no longer accept information returns composed using schema version 1.1 (or v1.0), it will assign the new major number 2.0. The active validating schema version is 2.0. Returns submitted with version 1.1 or earlier will be rejected for using an unsupported schema version. Software Developers and Transmitters should visit the IRIS schema and business rule page for information on active and prior year schema and business rules.

40 Publication 5718

When filing prior years, please use the schemas and business rules that are in effect for that tax year. Do not use the current year schemas and business rules. In addition, do not mix or combine tax years in the same transmission or submission. Use the latest prior year schema and business rule package available through the e-Services mailbox.

41 Publication 5718

Amounts to include to calculate Total Reported Amount TY2022-TY2024

This section explains the checks IRIS performs on your transmission to ensure accuracy and completeness. Understanding this process helps you prepare error-free submissions.

Immediate Processing (Steps 1-4): When you submit a transmission, IRIS first handles the basics:

1. Uniqueness Check: Verifies your UTID hasn’t been used before for your TCC

2. Save Your Data: Stores your transmission safely in the IRS database

3. Generate Confirmation: Creates your Receipt ID and timestamp

4. Send Confirmation: Returns your Receipt ID, UTID, and timestamp to the transmitter

Detailed Validation (Steps 5-10): After confirming receipt, IRIS performs thorough checks:

5. Format Validation: Ensures your XML follows the required structure (Schema Validation)

6. Queue for Processing: Places your transmission in line for business rule checks

42 Publication 5718

7. Basic Information Check: Verifies your Transmitter Control Code and Software ID

8. Content Verification: Checks transmission type, tax year, and company information

9. Form-Specific Validation: Applies specific rules for each type of form you submitted

10. Error Recording: Documents any problems found and prepares error messages for you

What Happens When Errors Are Found:

• Immediate Problems: Issues with transmission or storage result in instant rejection with error explanation

• Format Problems: Schema validation failures are reported when you request your acknowledgement

• Content Problems: Business rule violations are recorded and sent back in your acknowledgement

Important: Test Before You Submit Before sending your actual transmission to IRIS, we strongly recommend using a “validating parser” - this is a tool that checks your XML files against IRS requirements to catch errors early.

What a Validating Parser Does:

• Compares your XML files against IRS specifications

• Checks that all required information is included

• Verifies data formats (like making sure dates look like dates, numbers are in the right format)

• Ensures your file structure matches what IRIS expects

Why This Matters: Using IRS-approved software with built-in validation can eliminate most formatting errors before submission, saving you time and reducing rejections.

Schema Compliance - The Technical Details:

• Your information returns must match the specific XML schema version you specify

• Missing required fields or incorrectly formatted XML will cause rejection

• IRIS validates every return against these technical specifications

• Errors include detailed explanations and locations of problems (XPath references)

Once the transmission is received, the payload is read and written to persistent storage, and checks are made on the Transmission Manifest Data, then the Receipt ID, Timestamp, and Unique Transmission ID are returned to the Transmitter as part of the synchronous session.

43 Publication 5718

The XML payload is then queued for processing within IRIS.

When IRIS receives a status request IRIS will send a response with one of the following statuses:

• Accepted – IRS has successfully processed and accepted the transmission

• Rejected – IRS rejected the transmission as it could not be processed successfully. A list of errors is provided as part of the Acknowledgement Response

• Processing – IRS has not completed processing the transmission

• Partially Accepted – IRS has successfully processed the transmission (accepted and rejected one or more submissions contained in the transmission). A list of errors will be provided as part of the Acknowledgement Response

{ No fatal errors were identified while processing the transmission metadata

{ At least one submission within the transmission was accepted (with or without errors)

{ At least one submission within the transmission was rejected as unusable data

• Accepted with Errors –IRS has successfully processed and accepted the transmission with some errors. A list of errors will be provided as part of the Acknowledgement Response

• Not Found – The Receipt ID or the UTID in the request was not found

When IRIS receives an acknowledgment request, an acknowledgment response is generated that will include:

• Transmitter Control Code

• Unique Transmission ID

• ReceiptId (when request Search Parameter is UTID)

• Form Type Code

• Timestamp

• Transmission Status Code: Accepted, Rejected, Processing, Partially Accepted, Accepted with Errors, Not Found

• Error Information Group (if errors are identified)

Corrections can only be made to previous submissions/records that have been “Accepted” or “Accepted with Errors”. Corrected information returns MUST be filed electronically if the original return was required to be submitted electronically. Originals filed in FIRE must be corrected in FIRE and originals filed in IRIS A2A must be corrected in IRIS A2A. Transmitters should file corrections with IRS as soon as possible and furnish a copy of the corrected return to the Recipient. File corrected returns to comply with filing requirements. Refer to the General Instructions for Certain Information Returns for details.

44 Publication 5718

Note: Errors on the Manifest and Submission Headers with “Report Error” severity may not be corrected. These are for informational purposes only. The missing data should be provided in subsequent transmissions.

The correction process can be utilized when:

• IRS notifies the Transmitter of one or more errors on the information returns (Form1099ADetail) filed.

• The Transmitter identifies one or more errors on the information returns (Form1099ADetail) filed.

• The Recipient reports an error.

Do not file an original again, as this may result in duplicate reporting.

The UniqueRecordId assigned by IRIS allows corrections to be linked to the original information return. As explained in Section 2.2, the UniqueRecordId is a concatenation of ReceiptId|SubmissionId|RecordId. For example: 2024-63385508791-4a6c57eda|10|2. You must provide the UniqueRecordId in every corrected record.

Most errors in IRIS can be corrected by submitting 1-Step corrections, unless the wrong

form was submitted:

45 Publication 5718

1-Step Correction Procedures 2-Step Correction Procedures

1. Prepare a new transmission with TransmissionTypeCd “C” in the Manifest. (Do not mix original and corrected records in the same transmission payload.)

2. Include an IR Submission Group for each form type and issuer being reported. (The IssuerDetail in the SubmissionHeader must be the same as the original submission.)

3. Include the complete record for correction. Do not submit only the corrected data.

4. The CorrectedInd in each correction record must be set to “1”. Include the PrevSubmittedRecRecipientGrp with the UniqueRecordId. This element is optional in the schema but enforced with a business rule. It must be present on all corrected records, or the submission will reject. Recipient Name and TIN of the original record are optional in this group but ensure the correction is associated with the original record. Note: An original is only corrected once. If after a correction is filed and accepted, an additional correction is needed, use the UniqueRecordId associated with the most recently accepted correction.

1. Follow steps for a one-step correction, entering “0” in all payment amounts.

2. Once the first correction is Accepted, submit a new transmission with TransmissionTypeCd “O” in the Manifest.

3. Include an IRSubmissionGrp with the correct form type in the IRSubmissionHeader and IRSubmissionDetail.

Transmissions can be “Rejected” before or after a ReceiptId is issued. Transmissions rejected due to an “XML Schema Validation Error” will receive a ReceiptId; however, they can’t be replaced. These transmissions must be resent as the “Original”.

When a transmission is rejected by IRIS before a ReceiptId is issued or an “XML Schema Validation Error”, the Transmitter must fix the problem that caused the rejection and resend the transmission using the same TransmissionTypeCd of the rejected transmission. Verify the transmission does not exceed the 100MB limit.

46 Publication 5718

Table 6-1: Pre-Receipt Validation Errors

47 Publication 5718

Additional business rule checks occur after the Transmitter has successfully submitted the transmission to IRIS.

Error details returned to Transmitters will show exactly which business rules were violated by the transmission.

• Manifest level: TMFSTXXX or FTMFSTXXX

• Submission and Manifest level: SMFXXX

• Submission1Header: S1HXXX

• Submission2Header: S2HXXX

• Submission3Header: S3HXXX

• Shared Form: Shared IRForm XXX

• Individual Forms: F1097BTCXXX, F1098XXX, F1099BXXX, etc.

Note: The first “XXX” is sequential numbering of Business Rule.

Certain business rules (those with a severity of “Report Error and Reject if Over Threshold”) may cause a rejection of the entire submission, if violated in more instances than the threshold allows. If this happens, the Transmitter will receive an Error File containing all the rules that were violated plus a generic “Threshold Rule” error for each threshold that was exceeded. It is the responsibility of the Transmitter to correct all business rule errors and retransmit a replacement for rejected submissions.

Business rule validation provides Transmission level rejections along with submission level rejections. None of the records included in a transmission/submission that are rejected are maintained in IRS data stores. Thus, when a transmission or submission is rejected by IRIS, a replacement transmission or submission must be submitted including all data submitted in the original file.

A complete Transmission can be rejected for the following reasons:

• Business rule failures at the transmission level (Manifest error)

• All Submissions within the transmission are rejected.

• Note: The above situations require the Transmitters to replace the entire Transmission.

A Transmission can be Partially Accepted when one or more submissions, but not all, are rejected.

A submission can be rejected for the following reasons:

• Business Rule failures at submission level, e.g., Submission Header with incorrect Tax Year resulting in submission rejection.

• Business Rule failure at form level (e.g., a value on a form must be present or threshold rule failure)

Note: These situations require the Transmitters to replace only the rejected Submission(s).

48 Publication 5718

Transmitters can replace rejected Transmissions as well as rejected Submissions. A replacement transmission must contain all the records submitted to IRS for processing in the rejected Transmission or Submission that is being replaced. Transmitters should submit an acceptable replacement transmission no later than 60 days after the date the rejected status of the original transmission was available. The 60-day adjustment applies whether the original transmission was received before or after the information return due date. When an acceptable replacement transmission is received within 60 days, the file will be treated as filed on the original transmission received date. If an acceptable replacement transmission is received after the 60 days, the file will be treated as filed on the date the replacement transmission is received. In this way, any applicable late-filing penalty is calculated based on the date the transmission was received.

Note: Transmitters should wait until a transmission is processed and the Acknowledgement status is either ‘Rejected’ or ‘Partially Accepted’ by IRS before submitting a replacement transmission or submission.

IRIS requires specific identifiers in replacements to reference the original rejected transmission/submission. When replacing a transmission, the Manifest XML Schema includes an element “OriginalReceiptId” which references the Receipt ID of the original transmission that is being replaced. When replacing a submission, the Submission Header element “OriginalUniqueSubmissionId” is used to reference the Submission ID of the original submission that is being replaced. When submissions are replaced, the Manifest data element “OriginalReceiptId” is not included in the schema.

Only transmissions that contained original records (“ TransmissionTypeCd ” is ‘O’) that were rejected require a replacement transmission. When a transmission containing original records is rejected (“ TransmissionTypeCd ” is ‘O’), the Transmitter must fix the problem that caused the rejection and resend the transmission as a replacement (“ TransmissionTypeCd” is ‘R’). If a transmission containing correction records is rejected (“ TransmissionTypeCd ” is ‘C’), the Transmitter must fix the problem that caused the rejection and resend the transmission following correction procedures (“ TransmissionTypeCd ” remains ‘C’).

An individual original submission within a transmission can be rejected by IRS in a Partially Accepted transmission. The original submission should be fixed and retransmitted in a replacement transmission (“ TransmissionTypeCd ” is ‘R’).

Exception: If a Submission2Grp containing only Form 8809 is rejected, file an original again, not a replacement.

If the original Transmission was “Rejected”, then replace the entire Transmission by using the Receipt ID from the Rejected Transmission to populate the Manifest Data element ‘ OriginalReceiptId ’ of the Replacement Transmission. Replacement transmissions must include the following requirements (see schema and business rules for additional details):

49 Publication 5718

• A “ UniqueTransmissionId ” for the replacement transmission in the Manifest that should be unique for each transmission

• “ TransmissionTypeCd ” in the Manifest should be “R” for replacements

Include the “ OriginalReceiptId ” data element identifying the original transmission that is being replaced.

Do not:

• Include any additional or new submissions

• Include the “ OriginalUniqueSubmissionId ” in the Submission Header

• Try to replace individual submissions within a rejected transmission

• Try to replace a transmission that was not rejected

• Try to replace a transmission that has been successfully replaced

If an original Transmission is rejected and the Replacement Transmission is also rejected, then replace the first (Earliest) rejected Transmission in the chain by populating the Manifest Data element ‘OriginalReceiptId’ with the Receipt Id that references the EARLIEST rejected Transmission in the chain.

Replacement Transmissions must include the following requirements (see schema and business rules for additional details):

• A “ UniqueTransmissionId” for the replacement transmission in the Manifest that is unique for each transmission

• “ TransmissionTypeCd” in the Manifest should be “R” for replacements

• Include the “ OriginalReceiptId” data element identifying the Receipt Id that references the first rejected transmission in the chain, which contained a TransmissionTypeCd of “O”.

• Replacement transmission should not include any additional or new submissions

Do not:

• Include the “OriginalUniqueSubmissionId” in the Submission Header

• Try to replace a rejected replacement transmission

• Try to replace individual submissions within a rejected transmission

• Try to replace a transmission that was not rejected

• Try to replace a transmission that has been successfully replaced

Replacement submissions must include the following requirements (see schema and

50 Publication 5718

business rules for additional details):

• A “ UniqueTransmissionId” for the replacement transmission

• “ TransmissionTypeCd ” in the Manifest should be “R” for replacement

• Include the “ OriginalUniqueSubmissionId ” in the Submission Header identifying the submission that is being replaced

• Duplicate replacement Submission (s) included within the same transmission will be rejected

• Replacement transmission should not include any new submissions

Do not:

• Include the “OriginalReceiptId” data element in the Manifest

If the Original Transmission was Partially Accepted, then replace the individual Submission(s) that were rejected by populating the data element “ OriginalUniqueSubmissionId ” in each replacement Submission (SubmissionHeader) with the “ UniqueSubmissionId ” from the Submission Header of the rejected Submission(s). When filing replacement Submission(s) for submissions that were rejected within a Partially Accepted Transmission, adhere to the following requirements (see schema and business rules for additional details):

• A “ UniqueTransmissionId ” for the replacement transmission

• “ TransmissionTypeCd ” in the Manifest should be “R” for replacement

• Include the “ OriginalUniqueSubmissionId ” in the Form Data File identifying the submission that is being replaced from the original Partially Accepted transmission

• Duplicate replacement Submission ID(s) included within the same transmission will be rejected

• Replacement transmission should not include any new submissions

Do not:

• Include the “ OriginalReceiptId ” data element in the Manifest

• Submit a submission-level replacement for a transmission that was rejected

If the original Transmission is Partially Accepted, and the Transmission with the replacement submissions is Rejected or Partially Accepted, then transmit another replacement

51 Publication 5718

transmission using the Submission IDs from the original rejected submissions. In either case always replace the first rejected submission in the chain of rejected submissions when one or more replacements are rejected.

Note: First rejected Submission(s) in the chain of rejections does not relate to the order of submission within an individual Transmission.

If filing a replacement Submission from a Partially Accepted Transmission where the replacement was rejected, adhere to the following requirements (see schema and business rules for additional details):

• “ UniqueTransmissionId ” for the replacement transmission

• “ TransmissionTypeCd ” in the Manifest should be “R” for replacement

• Include the “ OriginalUniqueSubmissionId ” in each replacement submission’s Submission Header with the Unique Submission ID from the Submission Header within the earliest rejected Submission in a sequence within a Partially Accepted Transmission that is being replaced

• Duplicate replacement Submission ID(s) included within the same transmission will be rejected.

• Replacement transmission should not include any new submissions

Do not:

• Include the “ OriginalReceiptId ” data element in the Manifest

• Replace a submission within a Submission Replacement Transmission that was rejected

You may transmit a request for an automatic 30-day extension of time to file forms included in IRIS (see Section 1). The Transmission should include “ IRSubmission2Grp ” with the “ IRSubmission2Header ” and “ Form8809Detail ”. Extensions cannot be corrected or replaced. If an extension is rejected, it must be retransmitted as an original request.

For Form W-2 and Form 1099-NEC reporting Nonemployee Compensation, filers can only request a non-automatic extension of time, which must be filed on a paper Form 8809. An automatic 30-day extension is not available.

Under certain hardship conditions you may apply for an additional 30-day extension if the initial extension of time to file is granted, and the additional extension is filed before the expiration of the automatic 30-day extension. The additional 30-day extension request can only be submitted by filing a paper Form 8809.

52 Publication 5718

The due date for furnishing the information returns to the recipient vary.

You may request an extension of time to furnish the statements to recipients by faxing Form 15397, Application for Extension of Time to Furnish Recipient Statements to:

Internal Revenue Service Technical Services Operation Attn: Extension of Time Coordinator Fax: 877-477-0572 (International Fax: 304-579-4105)

Your request must be received no later than the date on which the statements are due to the recipients. If your request for an extension is approved, generally you will be granted a maximum of 30 extra days to furnish the recipient statements.

Treasury Decision (TD) 9972 amended the rules for filing returns and other documents electronically (e-file). These regulations reduce the 250-return threshold to generally require electronic filing by filers of 10 or more returns in a calendar year beginning in Tax Year 2023, Processing Year 2024. Details on this regulation can be found here: IRS and Treasury fnal regulations on e-fle .

The electronic filing requirement does not apply if you apply for and receive a hardship waiver. If the filer is required to submit information returns electronically and fails to do so, and there is not an approved waiver on record, the filer may be subject to a penalty for failure-to-file electronically.

Form 8508 - Request for Waiver from Filing Information Returns Electronically, is used to request a waiver. A separate Form 8508 must be submitted for each issuer. Form 8508 May be filed beginning in January of each year and should be submitted at least 45 days before the due date of the information return. The form cannot be filed electronically. Refer to Form 8508 for detailed Instructions on how to complete the request for a waiver.

The Combined Federal/State Filing (CF/SF) Program was established to simplify information returns filing for issuers. Through the CF/SF Program, the IRS electronically sends information returns (original and corrected) to participating states. State Coordinators must contact their IRS Government Liaison to request their state be added or removed from the CF/SF Program. Requests must be submitted by January 1st and the request will be implemented the following tax year. For example: To be added to or removed from the CF/ SF Program for tax year 2026, the request would need to be submitted by January 1, 2026. Refer to Combined Federal/State Filing (CF/SF) Program State Coordinator Information FAQs on IRS.gov.

53 Publication 5718

Note: Only state coordinators should contact the IRS Government Liaison.

If you participate in the IRIS CF/SF Program, you may report withholdings and payments for as many states as needed. If you made a payment to a recipient that’s reportable to more than one state, you must prorate the amounts for each state.

The following information returns are available for filing under the CF/SF Program:

Form 1099-B, Proceeds from Broker and Barter Exchange Transactions

Form 1099-DIV, Dividends and Distributions

Form 1099-G, Certain Government Payments

Form 1099-INT, Interest Income

Form 1099-K, Payment Card and Third-Party Network Transactions

Form 1099-MISC, Miscellaneous Information

Form 1099-NEC, Nonemployee Compensation

Form 1099-OID, Original Issue Discount

Form 1099-PATR, Taxable Distributions Received From Cooperatives

Form 1099-R, Distributions From Pensions, Annuities, Retirement or Profit-Sharing Plans, IRAs, Insurance Contracts, etc

Form 5498, IRA Contribution Information

The following table provides the participating states in the CF/SF Program. Each state’s filing requirements are subject to change by the state. It’s the filer’s responsibility to contact the participating state(s) to verify their criteria and special data entry requirements.

Table 9-1 States Participating in CF/SF

54 Publication 5718

For a complete list of due dates please review the current version of General Instructions for

Certain Information Returns.

55 Publication 5718

56 Publication 5718

Form IRS Electronic Filing Recipient/Participant Copy

5498-QA May 31 March 15

5498-SA May 31 (To Participant) May 31

W-2G March 31 January 31

If any filing due date falls on a Saturday, Sunday, or a legal holiday, you will be considered to have timely filed if you file by the next day that is not a Saturday, Sunday, or a legal holiday. Legal holidays for this purpose are legal holidays in the District of Columbia or a statewide legal holiday where the return is required to be filed. Also, a leap year does not extend the filing deadline. For example, see Announcement 91-179, 1991-49 I.R.B. 78.

Contact the Help Desk Monday through Friday 7:30 a.m. – 7:00 p.m. ET. Listen to all options before making your selection.

866-937-4130 (toll-free)

470-769-5100 (international; not toll-free)

TTY\TDD: The IRS welcomes calls via your choice of relay. Deaf or hard of hearing taxpayers using a relay service may call any of our toll-free numbers

It is important that the Issuer and Recipient name, name control and TIN match the IRS database. Incorrect TINs and associating the wrong name with a TIN are some of the most common causes of information return errors.

For guidance on names and name controls:

General Instructions for Certain Information Returns (Forms 1096,1097, 1098, 1099, 3921, 3922, 5498, and W-2G)

Webpage References Description

www.irs.gov/inforeturn Learn about the differences between IRIS and other filing systems such as the Filing Information Returns Electronically (FIRE) system

www.irs.gov/iris Access the Taxpayer Portal, E-File Forms with IRIS, subscribe to QuickAlerts and locate Help Desk contacts

www.irs.gov/irisats Find ATS scenarios, known issues and solutions

57 Publication 5718

58 Publication 5718

59 Publication 5718

Publication 5718 (Rev. 1-2026) Catalog Number 93552B Department of the Treasury Internal Revenue Service www.irs.gov