Information Returns Intake System (IRIS)

Agency decision

Ask Donna

What actually matters in this document.

Text

PUBLICATION 5718

Information Returns Intake System (IRIS)

Electronic Filing Application to Application

(A2A) Specifications

PROCESSING YEAR 2026

What’s New for Processing Year 2026

Location

Changes

Throughout Publication

Updated Processing Year

Throughout Publication

Updated Tax Year

Introduction

New forms added to IRIS A2A intake

Section 1.1

Added clarifying information on Issuer TCC and EIN

Section 1.2.2

Chatbot Feature

Section 1.6

Added a few clarifications

Section 3.1.2

Added a few clarifications

Section 3.1.3

Added a few clarifications

Table 3.3.1

Updated Table with new forms

Section 9

Rhode Island added to CF/SF program

Section 10.1

New forms added to Due Date chart

Publication 5718

Table of Contents

1. Introduction �� 6

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. Transmissions, Submissions and Records �� 18

2.1 Definitions and Limitations ��19

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

3. Transmitting Information Returns �� 21

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

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. How IRIS Validates Your Transmission �� 42

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

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

5. Status and Acknowledgment Request and Response �� 44

6. Corrections and Replacements �� 45

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. Extension of Time to File �� 52

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

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

8. Waiver from Filing Electronically �� 53

Publication 5718

9. Combined Federal/State Filing (CF/SF) Program �� 54

10. Other Helpful Information �� 55

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

11. Acronym and Abbreviation List �� 59

Publication 5718

1. Introduction

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 &

530)

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

www.irs.gov/iris.

1.1 Purpose

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.

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.

1.2 Communications

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

1.2.1 IRIS Webpage

For information regarding IRIS and electronic filing information returns, go to Information

Returns Intake System (IRIS) Program webpage: www.irs.gov/iris

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

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 QuickService

Alerts at E-file information returns with IRIS | Internal Revenue Service.

1.2.2 Chatbot Feature Chatbot Feature

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.

1.3 Registration and Application Process

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

1.3.1 Registration

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.

Service

Publication 5718

1.3.2 Applying for an IRIS TCC

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.

Publication 5718

Table 1-1: TCC Roles

What roles should I select on my IRIS Application for Transmitter Control Code?

Software

Purchased or

Developed?

If…

And

Then

Developed

I am a commercial Software

Developer developing

software and selling

software,

I will transmit information for

others.

Developed

I am developing my own

software package, or

contracted with someone to

develop a unique package

for my sole use,

I will perform the software

Select the roles of Software

testing with IRS and transmit Developer and Issuer on

my own information returns. your application.

Purchased*

I am purchasing a software

package,

I will transmit my own

information returns.

Select the role of Issuer on

your application.

Note: The Transmitter

TIN and the Issuer TIN

must match the TIN on the

TCC application. Issuers

must pass a one time

communication test in IRIS

ATS prior to transmitting in

production.

Purchased*

I am purchasing a software

package,

I will transmit my own

information returns and

transmit for others.

Select the role of Transmitter

on your application.

Note: The TCC for a

Transmitter can be used to

transmit your own returns

and others. You may not use

an Issuer TCC to transmit

information returns for

others. See Section 1.4 for

required communication

testing for Transmitters.

Select both the Software

Developer role and the

Transmitter role on your

application.

*Not all software supports corrections and/or replacements. Prior to purchasing IRIS

software, make sure it meets your business needs.

1.3.3 Third-Party Transmitters

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.

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.

1.3.4 Things you need to know before completing the IRIS Application

for TCC

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

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.

1.3.5 Access the IRIS Application for TCC

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

1. Go to IRIS TCC

Click on the Access Application for TCC button

an account if you already have one)

Select Individual on the Select Your Organization page

Click on New Application and select IRIS Application for TCC

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.

1.3.6 Application Approved/Completed

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.

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.

1.3.7 Revise Current TCC Information

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.

1.3.8 Deleted TCCs

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.

TCC

1.4 Transmitter and Issuer TCCs

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.

1.5 Software Developer TCCs

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.

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.

1.6 API Client ID

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.

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

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

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

application.

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.

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.

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 Certificates | 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

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.

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

Figure 1-3: Example of Certification Expiration Dates

Publication 5718

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.

2. Transmissions, Submissions and Records

2.1 Definitions and Limitations

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

IR Transmission

IRTransmissionType

IRSubmission1Grp

IRSubmission1GrpType

IRSubmission2Grp

IRSubmission2GrpType

IRSubmission3Grp

IRSubmission3GrpType

IRSubmission1Grp

IRSubmission1Header

IRSubmission1HeaderType

IRSubmission1Detail

IRSubmission1DetailType

Form1099ADetail

Form1099ADetailType

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

Publication 5718

Allowed Data Value

Description

‘O’

A transmission containing original records

‘C’

A transmission containing correction records

‘R’

A transmission containing replacement records

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.

2.2 Uniquely Identifying the Transmission, Submission and Records

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

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.

3. Transmitting Information Returns

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.

3.1 Application to Application (A2A) Channel Overview

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

Initial Validation: IRIS performs basic checks on your transmission format

Error Response: If problems are found, you’ll receive an immediate error message

explaining what went wrong

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

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

3.1.1 A2A Consent Requirements

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.

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.)*

Select Setup on the API Authorization Management page.

Enter your IRIS Client ID on the A2A Authorization page.

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.

Grant access to TEST, which is needed to test software and electronic transmissions in

the IRIS ATS environment.

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

environment.

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.

3.1.2 Access Token Generation for A2A Access Flow

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

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.

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

Publication 5718

PARAMETER

DESCRIPTION

grant_type

Required: Value must be set to ““urn:ietf:params:oauth:grant-type:jwt-bearer”

assertion:

Required: The assertion used as authorization grant. Must contain a single jwt.

{app-signed-jwt}

client_assertion_type:

Required: The value is urn:ietf:params:oauth:client-assertion-type:jwt-bearer

client_assertion:

Required: contains a single JWT. Must not contain more than one JWT

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

Figure 3-2: Login endpoint HTTPs request – Example

POST /token.oauth2 HTTP/1.1

Host: api.irs.gov

Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer

&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.

&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer

&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0

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.

Publication 5718

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

curl -k -POST https://api.alt.www4.irs.gov/auth/oauth/v2/token \

-H “Content-Type: application/x-www-form-urlencoded” \

-d @- <<EOF

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer

&assertion=XXXX.XXXX.XXXX

&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer

&client_assertion=XXXX.XXXX.XXXX

EOF

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

PARAMETER

DESCRIPTION

access_token

The access token will be used as the credentials for accessing the IRIS endpoints.

token_type

Value is Bearer for all responses that include an access token

refresh_token

The refresh token is a credential that can be used to obtain additional access token(s).

expires_in

The lifetime in seconds of the access token. For example, the value “900” denotes

that the access token will expire in 15 minutes from the time the response was

generated.

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.

Publication 5718

Figure 3-4: Access Token Successful Response - Example

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

“access_token”: “<Access-Token>” ,

“token _type” : “Bearer” ,

“refresh_token”: “<Refresh-Token>” ,

“expires_in”: 900

}

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.

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.

{

•

Refresh tokens expire 60 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 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.

3.1.3 Operations

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

Operation:

Submit Transmission API

Description:

This service accepts the incoming information return from A2A (application/xml)

Protocol:

REST

Method:

POST

Live Endpoint

(Production):

https://api.www4.irs.gov/IRIntakeAcceptanceA2A/1.0/irisa2a/v1/intake-acceptance

Test Endpoint

(ATS):

https://api.alt.www4.irs.gov/IRIntakeAcceptanceA2A/1.0/irisa2a/v1/intakeacceptance

Resource:

/irisa2a/v1/intake-acceptance

Headers:

◼

Authorization: Bearer <Access-Token>

Publication 5718

REQUEST

Request:

◼

Media Type: multipart/form-data

◼

Accepts: application/xml

Response:

application/xml

Request

Attachment:

Content Type: text/xml (accept:text/xml)

ContentID: “file”

Note: File attachment no more than 100MB. Ensure the payload is attached as a file

RESPONSE

CODE

DESCRIPTION

CONTENT

TYPE

RESPONSE BODY

200

Receipt ID has been generated

application/xml

ReceiptID object

400

Bad request

application/xml

ErrorResponse object

404

Not found

application/xml

ErrorResponse object

500

Internal Server Error

Raw

ErrorResponse object

503

Service Unavailable Error

application/xml

ErrorResponse object

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

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

Figure 3-7: A2A Intake Acceptance Illustrative Response – 404 Not Found

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

Operation:

GetStatus/Ack API

Description:

Endpoint that fetches Transmission Status and Acknowledgement Info

Protocol:

REST

Method:

POST

Live Endpoint

(Production):

https://api.www4.irs.gov/IRIntakeAcceptanceA2A/1.0/iris/transstatusorack

Publication 5718

REQUEST

Test Endpoint

(ATS):

https://api.alt.www4.irs.gov/IRIntakeAcceptanceA2A/1.0/iris/transstatusorack

Resource:

/iris/transstatusorack

Headers:

◼

Authorization: Bearer <Access-Token>

◼

Content-Type: application/xml

◼

Accepts: application/xml

Body:

POST

◼

XML Payload per Schema

RESPONSE

CODE

POST

CONTENT TYPE

RESPONSE BODY

200

Transmission or Acknowledgement

status response

application/xml

Status object

404

Invalid Search Parameters

application/xml

ErrorResponse object

500

Internal Server Error

application/xml

ErrorResponse object

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

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

Publication 5718

3.2 XML Overview for IRIS

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.

3.2.1 IRIS XML Schema Package Structure

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

{

•

FORM_TYPES

{

•

IRS-IRefileTypes.xsd defines simple and complex elements that are reused across

the XML payload.

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

3.2.2 IRIS XML Structure

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.

Submission: Details the type of form, transmittal form elements, and total of form values

(if applicable). Contains one or more forms.

Form: Details the form data elements.

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

3.2.3 Prohibited and Constrained Special Characters

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

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

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

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.

3.2.4 Tag Names

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

Publication 5718

3.2.5 Attributes

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

3.2.6 Repeating Group

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.

3.2.7 IRIS Schema and Business Rules

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.

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.

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 “FormnnnnDetailType” 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

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.

3.2.8 Validating Schema Versions

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.

Publication 5718

3.3 Filing Prior Year Returns

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.

3.3.1 Calculating Total Reported Amount

Note: Total Reported Amount was removed from TY2025 schema. Use this chart if filing

TY2022-TY2024.

Amounts to include to calculate Total Reported Amount TY2022-TY2024

Form W-2G

Box 1

Form 1097-BTC

Box 1

Form 1098

Boxes 1 and 6

Form 1098-C

Boxes 4c and 6b

Form 1098-E

Box 1

Form 1098-F

Box 1

Form 1098-Q

Box 4

Form 1099-B

Boxes 1d and 13

Form 1099-C

Box 2

Form 1099-CAP

Box 2

Form 1099-DIV

Boxes 1a, 2a, 3, 9, 10 and 12

Form 1099-INT

Boxes 1, 3, 8, 10, 11 and 13

Form 1099-K

Box 1a

Form 1099-LS

Box 1

Form 1099-LTC

Boxes 1 and 2

Form 1099-MISC

Boxes 1, 2, 3, 5, 6, 8, 9, 10, 11 and 14

Form 1099-NEC

Box 1

Form 1099-OID

Boxes 1, 2, 5, 6 and 8

Form 1099-PATR

Boxes 1, 2, 3 and 5

Publication 5718

Amounts to include to calculate Total Reported Amount TY2022-TY2024

Form 1099-Q

Box 1

Form 1099-QA

Box 1

Form 1099-R

Box 1

Form 1099-S

Box 2

Form 1099-SA

Box 1

Form 1099-SB

Boxes 1 and 2

Form 3921

Boxes 3 and 4

Form 3922

Boxes 3, 4 and 5

Form 5498

Boxes 1, 2, 3, 4, 5, 8, 9, 10, 12b, 13a and 14a

Form 5498-ESA

Boxes 1 and 2

Form 5498-SA

Box 1

4. How IRIS Validates Your Transmission

This section explains the checks IRIS performs on your transmission to ensure accuracy and

completeness. Understanding this process helps you prepare error-free submissions.

4.1 The Validation Process - What Happens Behind the Scenes

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

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

Generate Confirmation: Creates your Receipt ID and timestamp

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

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

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

Validation)

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

Publication 5718

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

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

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

4.2 How to Avoid Common Errors - Pre-Submission Tips

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)

5. Status and Acknowledgment Request and Response

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.

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)

6. Corrections and Replacements

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.

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.

6.1 Corrections Process

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.

6.1.1 Transmitting Corrections

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

form was submitted:

Errors Needing 1-Step Correction

◼

Information mismatch: name and/or TIN is

incorrect

◼

Form should not have been filed for a recipient.

(To correct, enter “0” for all amounts.)

◼

Incorrect payment amounts in a record

◼

Incorrect code or indicator value

Error Needing 2-Step Correction

◼

Incorrect form type, e.g.,1099-MISC filed rather

than 1099-NEC.

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

1. Follow steps for a one-step correction, entering

“0” in all payment amounts.

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

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.

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.

6.2 Rejected Transmissions

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

Transmissions Rejected in Pre-Receipt Validation

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.

Publication 5718

Table 6-1: Pre-Receipt Validation Errors

Error

General Description

Severity

Action

HTTP/1.1 400 Bad

Request

Transmission includes

Duplicate UTID

Submitted

Request Rejected

Transmitter notified

via the http response

(Unable to process

request, check for

duplicate data)

Transmitter Resolves

HTTP/1.1 400 Bad

Request

Transmission includes

‘TestCd’: “T” to

production environment

Request Rejected

Transmitter notified via

the http response

(Found invalid Test Code,

found T, P is required)

Transmitter Resolves

HTTP/1.1 400 Bad

Request

Transmission includes

‘TestCd’ that’s not’: “T”

or “P”

Request Rejected

Transmitter notified via

the http response

(Unable to process

request, check Test Code)

Transmitter Resolves

HTTP/1.1 400 Bad

Request

Manifest is not present in

transmission

Request Rejected

Transmitter notified via

the http response

(Unable to process

request)

Transmitter Resolves

HTTP/1.1 400 Bad

Request

No submissions in the

transmission

Request Rejected

Transmitter notified

via the http response

(Unable to process

request)

Transmitter Resolves

Transmission Rejected

Transmitter notified

via the http response

(Unable to process

request)

Transmitter Resolves

Initial Schema Validation Error occurred during

Error

initial validation (e.g.,

Note: Additional schema manifest is missing).

validation occurs after

ReceiptId is sent. These

errors will reject with

business rule error and

can be replaced unless

its due to an “XML

Schema Validation Error”.

Publication 5718

6.2.1 Transmissions/Submissions Rejected by IRIS

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

Publication 5718

6.3 Replacing an Original Transmission that Rejected

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.

6.3.1 Replacing an Original Transmission that Rejected

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

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

6.3.2 Replacing a ‘Replacement’ Transmission that Rejected

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

6.4 Replacement Submissions

Replacement submissions must include the following requirements (see schema and

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

6.4.1 Replacing Submission Within a Partially Accepted Transmission

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

6.4.2 Replacing Submission from a Partially Accepted Original

Transmission when the Replacements Transmission or Submission

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

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

7. Extension of Time to File

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.

7.1 Request for an Additional Extension of Time to File

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.

Publication 5718

7.2 Extension of Time to Provide the Recipient Copy

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.

8. Waiver from Filing Electronically

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 final

regulations on e-file.

e-file

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.

9. Combined Federal/State Filing (CF/SF) Program

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.

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

Alabama

Indiana

New Jersey

Arizona

Kansas

New Mexico

Arkansas

Louisiana

North Carolina

California

Maine

North Dakota

Colorado

Maryland

Ohio

Connecticut

Massachusetts

Oklahoma

Publication 5718

Delaware

Michigan

Oregon

District of Columbia

Minnesota

Pennsylvania

Georgia

Mississippi

Rhode Island

Hawaii

Montana

South Carolina

Idaho

Nebraska

Wisconsin

10. Other Helpful Information

10.1 Due Dates

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

Certain Information Returns.

Form

IRS Electronic Filing

Recipient/Participant Copy

1042-S

March 15

1097-BTC

March 31

On or before the 15th day of the

2nd calendar month after the close

of the calendar quarter in which

the credit is allowed (on or before

May 15, August 15, November 15,

and February 15 of the following

year).

1098

March 31

(To Payer/Borrower) January 31

1098-C

March 31

(To Donor) 30 days from date of

sale or contribution

1098-E

March 31

January 31

1098-F

N/A

1098-MA

February 28

January 31

1098-Q

February 28

January 31

1098-T

March 31

January 31

1099

March 31

January 31

1099-A

March 31

(To Borrower) January 31

1099-B

March 31

February 15 or March 15 (For

trustees and middlemen of widely

held fixed investment trusts

(WHFITs))

1099-C

March 31

January 31

1099-CAP

March 31

(To Shareholders) January 31 (To

Clearing Organization) January 5

Publication 5718

Form

IRS Electronic Filing

Recipient/Participant Copy

1099-DA

March 31

February 15 or March 15 (For

trustees and middlemen of widely

held fixed investment trusts

(WHFITs))

1099-DIV

March 31

January 31, February 15 for

amounts reported in boxes 8 or

10 and March 15 (For trustees and

middlemen of widely held fixed

investment trusts (WHFITs))

1099-G

March 31

January 31

1099-INT

March 31

January 31 or March 15 (For

trustees and middlemen of widely

held fixed investment trusts

(WHFITs))

1099-K

March 31

January 31

1099-LS

March 31

(To Reportable Policy Sale

Payment Recipient) February 15,

(To Issuer) January 15 or earlier as

required by Regulations section

1.6050Y-2(d)(2)(i)(A)

1099-LTC

March 31

January 31

1099-MISC

March 31

January 31 or March 15 (For

trustees and middlemen of widely

held fixed investment trusts

(WHFITs))

1099-NEC

January 31

1099-OID

March 31

January 31 or March 15 (For

trustees and middlemen of widely

held fixed investment trusts

(WHFITs))

1099-PATR

March 31

January 31

1099-Q

March 31

January 31

1099-QA

February 28

January 31

1099-R

March 31

January 31

1099-S

March 31

February 15

1099-SA

March 31

January 31

1099-SB

March 31 (except as provided in

Regulations section 1.6050Y-3(c))

February 15 (except as provided in

Regulations section 1.6050Y-3(d)

(2))

3921

March 31

January 31

3922

March 31

January 31

5498

May 31

(To Participant) For FMV/RMD/

SIMPLE IRA contributions,

January 31; For all other

contributions, May 31

5498-ESA

May 31

April 30

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.

10.2 Help with IRIS Transmissions

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

10.3 Verifying Issuer and Recipient Identity and TINS

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)

10.4 Additional Resources

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

Publication 5718

Webpage References

Description

www.irs.gov/irisschema

Find information about IRIS schemas and business rules

www.irs.gov/iristcc

Apply for a Transmitter Control Code (TCC) to e-file with IRIS

www.irs.gov/iriswgm

View FAQs and/or join the monthly working group meetings

for software developers, transmitters and state agencies

interested in IRIS A2A

11. Acronym and Abbreviation List

A2A

Application to Application

Ack

Acknowledgement

alg

algorithm

API

Application Program Interface

ATS

Assurance Testing System

aud

audience

BOM

Byte Order Mark

CF/SF

Combined Federal/State Filing

exp

expiration time

FIRE

Filing Information Returns Electronically

iat

issued at time

Identification

Information Returns

IRIS

Information Returns Intake System

IRS

Internal Revenue Service

iss

issuer

jti

JWT ID

JWK

JSON Web Key

JWKS

JSON Web Key Set

JWT

JSON Web Token

kid

Key identifier

MeF

Modernized e-File

OUSID

Original Unique Submission Identifier

Production

Processing Year

Publication 5718

RID

Record Identifier

Responsible Official

SID

Submission Identifier

SOR

Secure Object Repository

sub

subject

Test

TCC

Transmitter Control Code

Treasury Decision

TFA

Taxpayer First Act

TIN

Tax Identification Number

Tax Year

URID

Unique Record Identifier

UTF-8

Unicode Transformation Format-8

UTID

Unique Transmission Identifier

UUID

Universally Unique Identifier

XML

Extensible Markup Language

Publication 5718

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

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.