Publication 5718 (Rev. 3-2024)

PUBLICATION 5718

PROCESSING YEAR 2024

INFORMATION RETURNS INTAKE SYSTEM

(IRIS) ELECTRONIC FILING APPLICATION

TO APPLICATION (A2A) SPECIFICATIONS

2 Publication 5718

What’s New for Processing Year 2024

Location Changes

Throughout Publication Updated Processing Year

Throughout Publication Updated Tax Year

1.3 Registration and

Application Process

Added new sections 1.3.4 ‘Things you need to know before completing the

IRIS Application for TCC’, 1.3.5 'Access the IRIS Application for TCC', Section

1.3.6 'Application Approval/Completed', Section 1.3.7 'Revise Current TCC

Information', and Section 1.3.8 'Deleted TCC'

Section 1.3.1 Registration Added additional information about how to register for IRS online self-help

tools

Section 1.3.2 Who should

apply for an IRIS TCC

Added ‘The IRS encourages transmitters who le for multiple issuers to

submit one application and use the assigned TCC for all issuers.’

Section 1.6 API Client ID Modied step-by-step instructions on how to access the application and

added additional information regarding JWK le creation

Section 3.1.2 A2A

Consent

Modied step-by-step instructions on how to grant A2A authorization to your

API Client ID through the IRS Consent App

Section 3.1.3 Access

Token Generation for A2A

Access Flow

Added clarifying information about the JWTs and access tokens

Section 3.1.4 Operations In Table 3-4: GetStatus/Ack, updated URLs for Test and Production endpoints

and removed Figures 3-9: JSON Format GetStatus/Ack Illustrative Request

and 3-11: JSON GetStatus/Ack Illustrative Response – 200 Status Response

Section 3.3 Sample IRIS

XML Schema

Modied title of section to '3.3 Filing Prior Year Returns', removed Figure 3-18:

Sample IRIS XML Schema, and add information about ling prior year returns

Section 3.3.1 Calculating

Total Reported Amount

Removed duplicate’ “Calculating Total Reported Amount” table

Section 6 Corrections

and Replacements

Added ‘Corrected information returns MUST be led electronically if the

original return was required to be submitted electronically.’

Section 6.1 Transmitting

Corrections

Added clarifying information and modied step-by-step instructions on how to

transmit corrections

Section 9 Combined

Federal/State Filing (CF/

SF) Program

Added District of Columbia and Pennsylvania

Section 10.4 Additional

Resources

Added additional online resources

Section 11 Acronym List Added Acronym List

3 Publication 5718

Processing Year 2024 Revisions After 12-2023

Date Location Update

03/2024 Section 6.1.1 2-Step Correction Step 2

4 Publication 5718

Table of Contents

1. Introduction �� 7

1.1 Purpose �� 8

1.2 Communications �� 9

1.2.1 IRIS Web Site ��9

1.3 Registration and Application Process ��10

1.3.1 Registration �� 10

1.3.2 Who should apply for an IRIS TCC �� 10

1.3.3 Third-Party Transmitters �� 12

1.3.4 Things you need to know before completing the IRIS ��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 and Submissions �� 18

2.1 Transmission/Submission Deﬁnitions and Limitations �� 18

2.2 Uniquely Identifying the Transmission �� 19

3. Transmitting Information Returns �� 20

3.1 Transmitting via the Application to Application (A2A) Channel �� 20

3.1.1 Transmission Payload and REST Message via A2A �� 21

3.1.2 A2A Consent �� 21

3.1.3 Access Token Generation for A2A Access Flow �� 22

3.1.4 Operations �� 27

3.2 XML Overview for IRIS �� 33

3.2.1 IRIS XML Schema Package Structure ��33

3.2.2 IRIS XML Structure ��34

3.2.3 Prohibited and Constrained Special Characters ��34

3.2.4 Tag Names �� 35

5 Publication 5718

3.2.5 Attributes �� 36

3.2.6 Repeating Group ��36

3.2.7 IRIS Schema and Business Rules �� 37

3.2.8 Validating Schema Versions �� 38

3.2.9 Example of Schema Versioning �� 39

3.3 Filing Prior Year Returns �� 40

3.3.1 Calculating Total Reported Amount �� 40

4. Validating the Transmission and Return Data �� 41

4.1 Transmission Validation �� 41

4.1.1 Missing or Multiple Attachments �� 42

4.1.2 Error Reading or Persisting the Transmission Payload �� 42

4.1.3 Manifest Veriﬁcation Failure ��42

4.1.4 Manifest and XML Payload Schema Validation Failure ��42

5. Acknowledgement Response �� 43

5.1 Acknowledgement Schema �� 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 �� 49

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

6.4 Replacement Submissions �� 50

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 �� 51

6 Publication 5718

7. Extension of Time to File �� 52

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

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

8. Waiver from Filing Electronically �� 53

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 �� 55

10.3 Verifying Issuer and Recipient Identity and TINS �� 55

10.4 Additional Resources ��56

11. Acronym List �� 56

7 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 le large volumes of Form 1099

series 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 to develop software for IRIS and/or to transmit through the IRIS A2A system. For

Tax Year (TY) 2023 in Processing Year (PY) 2024 the following information returns can be

led using IRIS A2A:

• 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-DIV, Dividends and Distributions

• Form 1099-G, Certain Government Payments

• Form 1099-H, Health Coverage Tax Credit (HCTC) Advance 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 Benets

• Form 1099-MISC, Miscellaneous Income

• Form 1099-NEC, Nonemployee Compensation

• Form 1099-OID, Original Issue Discount

• Form 1099-PATR, Taxable Distributions Received From Cooperatives

• Form 1099-Q, Payments from Qualied Education Programs (Under Sections 529 &

530)

• Form 1099-QA, Payments from Distributions From ABLE Accounts

• Form 1099-R, Distributions From Pensions, Annuities, Retirement or Prot-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

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

Note: Please refer to Publication 1220, Speciﬁcations for Electronic Filing of Form 1097,

1098, 1099, 3921, 3922, 5498 and W-2G, for Information Return electronic specications

led via the Filing Information Returns Electronically (FIRE) System.

8 Publication 5718

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

ration and ling 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 ling program.

The following guides/documents provide additional guidance for ling electronically through

IRIS:

Publication 5717 – Information Returns Intake System (IRIS) Taxpayer Portal User

Guide: Contains general and program specic information for use with the IRIS Taxpayer

Portal.

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

1.1 Purpose

The purpose of this document is to provide the A2A specications to electronically le

information returns with the IRS including the requirements and specications under the

Combined Federal/State Filing Program (CF/SF). Additionally, this publication provides speci-

cations to submit an automatic 30-day extension of time to le certain information returns,

and the procedure for replacing and correcting returns. The audience of this document is:

• Issuer: A business ling their own information returns regardless of whether they are

required to le electronically or volunteer to le electronically.

• Transmitter: A third-party sending the electronic information return data directly to IRS

on behalf of any business required to le. If you are transmitting returns for your own

business, in addition to transmitting returns on behalf of another business, you do not

need both the Transmitter and Issuer role. You can le all returns as a Transmitter.

• Software Developer: An organization writing either origination or transmission software

according to IRS specications.

Note: Issuer(s) and Transmitter(s) are collectively referred to as transmitters throughout this

document unless specically stated otherwise.

All lers are encouraged to le electronically. Issuers 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.

9 Publication 5718

1.2 Communications

The Help Desk has been designated as the rst point of contact for information return

electronic ling issues. Software Developers, Transmitters and Issuers 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) and Communication Testing

• Business Rules and Error Code Resolution

1.2.1 IRIS Web Site

For information regarding IRIS and electronic ling information returns, go to Information

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

The IRIS page provides:

• Online IRIS System (Production and Testing) Status

• IRIS Program Overview

• IRIS ATS Information

• Links to access IRIS Publications, Schemas, Business Rules and much more

If you encounter an issue or limitation that prevents an information return from being

submitted electronically through IRIS, and the solution is not posted on the IRIS webpage,

please contact the Help Desk. The Service will then work on making the appropriate correc-

tions or assisting with the issue or limitation. Until corrections can be implemented, IRIS may

develop “workarounds” which are temporary changes to allow the return to be transmitted

electronically. Workarounds will be posted by Tax Year (TY) and linked to the Schema and

Business Rules page under the “Known Issues.”

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 ling season. After subscribing,

customers will receive “round the clock” communication issues such as electronic specica-

tions and system information needed for Software Developers and Transmitters to transmit

to IRS. New subscribers may sign up through the “subscription page” link located on the

QuickAlerts “more” e-le Benets for Tax Professionals page.

10 Publication 5718

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 led through the IRIS A2A system cannot be led

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 Application for TCC, 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.

1.3.2 Who should apply for an IRIS TCC

If you are transmitting information returns to the IRS or if you are developing software to le

information returns electronically, you must apply for one or more TCCs using the IRIS Appli-

cation for TCC available online. A single application can be used to apply for multiple roles

and the necessary TCCs. The IRS encourages transmitters who le 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 le. As a transmitter, you may

transmit les for as many companies as you need to under one TCC. The IRIS Application for

TCC contains three separate roles: Software Developer, Transmitter, and Issuer. Complete

the IRIS Application for TCC if your rm or organization is performing one or more of the

following roles:

• Software Developer: An organization writing either origination or transmission

software according to IRS specications.

• 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 le all returns as a Transmitter.)

• Issuer: A business ling their own information returns regardless of whether they are

required to le electronically or volunteer to le electronically

11 Publication 5718

These roles are not mutually exclusive, for example, a rm or 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. For example, Software Developers performing Testing

will use the Software Developer TCC. Do not use the Software Developer TCC to transmit

Production les.

Note: If an organization requires more than one TCC for any given role, a Responsible

Ofcial 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.

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.

Select both the Software

Developer role and the

Transmitter role on your

application.

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

testing with IRS and transmit

my own information returns.

Select the roles of Software

Developer and Issuer on

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: You may not use

an Issuer TCC to transmit

information returns for

others.

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.

12 Publication 5718

1.3.3 Third-Party Transmitters

If you do not have an in-house programmer familiar with XML or do not wish to purchase

A2A software that is certied to support the information returns that you plan to le, you can

le through a Third-Party Transmitter or use the online Taxpayer Portal. Visit www.irs.gov/

iris for additional information.

Only those persons listed as an Authorized User on the IRIS Application for TCC qualify to

receive information about a Receipt ID associated with a TCC listed on that application.

If your Third-Party Transmitter needs technical assistance regarding a Receipt ID associated

with records that were submitted on behalf of your organization, they should contact the

Help Desk.

When ling through a Third-Party Transmitter obtain the following for each submission led

on your behalf:

• A copy of all electronic records within each submission, along with the Receipt ID for

the transmission in which they were led.

• 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 Third-

party Transmitter go out of business or be otherwise unavailable to le corrections on your

behalf.

1.3.4 Things you need to know before completing the IRIS

A responsible ofcial (RO) initiates and submits the IRIS Application for TCC electronically.

Each RO must sign the terms of agreement using their ve-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 rms to use a Social Security Number (SSN) or

Individual Taxpayer Identication 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 (phone country code and phone number)

• Business address (this must be a physical location, not a post ofce box)

• Mailing address when different than business address

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

• Date of birth

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

13 Publication 5718

Role: The RO must select one or more roles but cannot select both ‘Issuer’ and ‘Transmitter’.

• Issuer: is a person ling only for their business

• Transmitter: is a person ling for their own business and other businesses or multiple

businesses NOTE: The Software Developer role is not used with the Taxpayer Portal

• Forms: At this time, the only option to select is Form 1099 Series

• Transmission Method: Select the check box next to Application-to-Application (A2A).

After the approval of your application, a ve-character alphanumeric TCC that begins with

the letter ‘D’ will be assigned. The IRS will send a letter with this information to the mailing

address on your application. You can always sign into your IRIS Application for TCC to

monitor the status of your application and view your TCCs on the Application Summary

page.

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

2. Click on the Access Application for TCC button

3. Sign in or create an account to begin the application process (you don’t need to create

an account if you already have one)

4. Select Individual on the Select Your Organization page

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

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

◼

Each RO must sign the Application Submission page using their 5-digit PIN. The

application will be processed after all ROs have entered their PIN and accepted the

Terms of Agreement.

◼

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

create a new PIN.

7. Allow up to 45 calendar days for application processing. You may check the status of

your application and TCC(s) on the Application Summary page.

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 ve-character alphanu-

meric TCC that begins with the letter ‘D’ will be assigned to your business. An approval letter

will be sent via 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.

14 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 Appli-

cation 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 infor-

mation on an IRIS TCC Application.

Changes that require a rm to acquire a new Employer Identication 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 rm to acquire a new EIN.

1.3.8 Deleted TCCs

Your TCCs will remain valid if you transmit information returns or extensions of time to le. If

you don’t use your TCC for three consecutive years, your TCC will be deleted. Once your TCC

is deleted it cannot be reactivated. You’ll need to submit a new IRIS Application for 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 Commu-

nication 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. The TCC is permanently assigned in

“Test” status. A separate Software ID is also assigned for each package. The tax year(s) for

15 Publication 5718

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.

Software Package information must be updated annually through the IRIS Appli-

cation for TCC. New Software IDs will be assigned for each tax year. To update your appli-

cation, the Responsible Ofcial 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, Infor-

mation 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 trans-

mission method. The IRIS A2A Channel uses the API Client ID to authenticate and authorize

access to IRIS A2A services. You must be approved to receive an API Client ID and follow

the e-Services A2A program requirements. After you receive your IRIS TCC, you must

complete an API Client ID Application which will allow your software to communicate directly

with IRS systems. To receive a API Client ID for IRIS A2A services, the following actions must

take place:

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

You will be redirected to Get an API client ID.

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

3. Select Individual on the Select Your Organization page or access your existing Client ID

Application if you already have one.

Exception: You must complete a new application if your existing Client ID Application

is only for Income Verication Express Services (IVES) Forms Based Processing (FBP).

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

application.

5. To modify your existing application, access the Application Details page.

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

application.

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

Application Details page to view your IRIS Client ID.

6. Each Client ID will need a JavaScript Object Notation (JSON) Web Key Set (JWKs) to be

uploaded to the application and validated before the Client ID will be issued. Review the

following instructions to complete the process.

You will have the opportunity to save your application if you do not have all the required

information. Once the application is saved, you may come back at your convenience.

Note: Continue to select Individual from the Select Your Organization page to access your

new application, until the application has gone to completed status.

16 Publication 5718

While completing the application, you will need to provide the JWKs le with use of valid

X.509 digital security certicate. The certicate 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:

• JWKs should contain a public key using RSA algorithm. RSA provides a key ID for key

matching purposes.

• Should contain X.509 certicate using both “x5t” (X.509 SHA-1 Thumbprint) and “x5c”

(X.509 certicate Chain) parameters.

{

You are not allowed to use self-signed certicates.

{

You can use the same public certicate as used for other IRS programs such as

MeF or AIR.

• For more information on Digital Certicates visit Digital Certiﬁcates | 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 Certicate Chain

{

“x5t”: X.509 Certicate SHA-1 Thumbprint

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.

17 Publication 5718

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 certicate expiration

date. There are various methods for checking a certicates expiration date. As one

example, you can double-click the public cert le on your computer as shown is Figure 1-2.

Figure 1-2: Example of Saved Certiﬁcate

• This will open up the certicate where the valid dates are shown, the expiration date is

the end date. See the example in Figure 1-3.

18 Publication 5718

Figure 1-3: Example of Certiﬁcation Expiration Dates

• For more information on JWK visit RFC 7517

Once the application is completed, the Responsible Ofcial or Contact will need to sign in

and obtain the API Client ID(s) issued to the rm/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 and Submissions

2.1 Transmission/Submission Deﬁnitions and Limitations

A transmission is an XML payload containing the Manifest and one or more submissions.

The Manifest contains information about the Transmitter and transmission.

For the purposes of this document, a submission is dened as the combination of an Infor-

mation Return (IR) Submission Group Type and its associated information return.

19 Publication 5718

Transmission Requirements:

• Must consist of one or more submissions

• Each Submission must be the same form type

• 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 identies the type of transmission as

follows:

Table 2-1: Transmissions Types

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 transmittal form 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

2.2 Uniquely Identifying the Transmission

The XML Schemas include elements designed to uniquely identify information returns trans-

missions, submissions within the transmission, and records within the submission.

Transmitters must uniquely identify each transmission with a Unique Transmission

Identiﬁer (UTID). The format for the UTID includes various elds separated by colons (:) as

follows: da20a4de-1357-11ed-861d-0242ac120002:IRIS:00000::A.

• Universally Unique Identiﬁer (UUID) – is an identier standard dened by the Internet

Engineering Task Force (IETF) in Request for Comments (RFC) 4122. It is a mandatory

eld and is represented by 32 hexadecimal digits, displayed in ve groups separated by

hyphens. da20a4de-1357-11ed-861d-0242ac120002

• Application ID – the Application ID will be hardcoded IRIS and is a mandatory eld

• Transmitter Control Code – is an uppercase alphanumeric eld that will contain the

Transmitter’s TCC and is mandatory

• Reserved – is an empty eld (no space between colons). *This is for future use and is

intentionally blank

• Request Type – the Request Type denes the type of request, A for A2A

20 Publication 5718

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, not

sequential or not unique, the transmission is rejected, and no further processing occurs.

Each submission within a transmission must be unique and will include a Submission

Identiﬁer (SID) for each submission within the same transmission.

Each record within a submission must be unique and will include a Record Identiﬁer (RID)

for each record within the same submission.

When an error is identied, the error le provides the SubmissionId or RecordId as well as

the Xpath for the error. These identiers are used to replace submissions and to correct

records. To replace a submission, the submission is uniquely identied by combining the

transmission ReceiptId and SID, using the pipe symbol as separator. To correct records, the

transmission ReceiptId, SID and RID are combined using the pipe symbol as follows:

OriginalUniqueSubmissionId = RECEIPTID|SID

UniqueRecordId = RECEIPTID|SID|RID

Original Unique Submission Identiﬁer (OUSID) and Unique Record Identiﬁer (URID) enable:

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

• Both IRS and Transmitters to track transmissions and submissions

3. Transmitting Information Returns

This section provides an overview of transmission methodology, transmission composition,

as well as data structure needed to successfully transmit information returns to the IRS.

3.1 Transmitting via the Application to Application (A2A) Channel

To invoke the A2A channel, Transmitters must have an active IRS account and IRIS A2A

TCC, and must be using IRS approved software to submit returns and retrieve acknowledg-

ments.

REST messages are exchanged with IRS using the Web Services request-response model

transport mechanism using the HTTPS protocol.

The IRIS system will perform authentication and authorization, threat mitigation, and initial

validation on the transmission. IRS Portal will return a fault response, if a transmission

contains a threat, if a transmission fails initial validation, or if a connection with the endpoint

cannot be established.

The IRIS System validates the REST message and performs additional security checks and

Manifest Schema validation on the inbound transmission. If threats are detected or Manifest

Schema validation fails, IRS will reject the transmission and inform the Transmitter of the

rejection. If no security threats or Manifest schema validation failure are detected, IRIS returns

a Receipt ID, the UTID, and a Timestamp to the Transmitter in the REST Response message as

21 Publication 5718

part of the synchronous session. 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 before calling the Help Desk toll free to request the Receipt ID for the trans-

mission. 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 XML of Receipt ID through A2A Channel

</IntakeA2AResponse>

3.1.1 Transmission Payload and REST Message via A2A

The IRIS transmission payload is an XML document that contains a REST message with

attachments. The document is a REST attachment that contains the IRIS Information Return

Submissions.

3.1.2 A2A Consent

For A2A Client IDs to run e-Services API transactions on behalf of e-Services users, those

Transmitters must rst grant access to A2A Client ID before a client can request an access

token on their behalf. Transmitters must perform the following steps to grant access:

1. Login to IRS Consent App.

Note: When logging into the consent app, select the organization associated with your

IRIS TCC application on the Select Your Organization page.

2. Select Setup on the API Authorization Management page.

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

If you have multiple Client IDs, please use the Client ID that was assigned to you for

IRIS. You can sign into your API Client ID Application to retrieve your IRIS Client ID on

the Application Summary page.

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

the IRIS ATS environment.

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

environment.

6. Retrieve your Full IRIS UserID from the A2A Setup Complete page.

22 Publication 5718

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 e-Help Desk.

3.1.3 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 Prole(s) for OAuth, please review the following RFCs:

◼

RFC-6749

◼

RFC-7523

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

access on a user’s behalf. The IRS server veries the two JWTs using the key(s) the trans-

mitter provided in their JWK le on the API Client ID Application. If the JWTs are valid the IRS

server will then verify that the user identied in the User JWT has provided consent to the

client identied in the Client JWT to run transactions on their behalf. Figure 3-1 shows steps

including the generation of the access token.

23 Publication 5718

Figure 3-1: A2A OAuth Flow – Diagram

The A2A ow 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 identier) – Identies the key the client used to sign the JWT.

Note: The kid should match the kid that was provided in the JWK le on your API Client

ID Application. The kid is also case sensitive.

• alg (algorithm) – Identies the algorithm used to sign the JWT.

Note: RS256 is the supported/expected algorithm.

24 Publication 5718

Payload

• iss (issuer) – Identies 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

{

The User ID for User JWT token type

{

User ID for User 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 identier for the 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

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

25 Publication 5718

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

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

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 dened in

Table 3-2.

26 Publication 5718

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.

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.

27 Publication 5718

Notes

• An Access token and Refresh token are received by the transmitter as a result

of successful user validation.

• Access tokens expire 15 minutes after they are issued.

{

You do not need to request a new Access token during a transmission that

takes longer than 15 minutes. The access token only needs to be active

when the transmission is initiated.

• Refresh tokens expire 60 minutes after they are issued.

{

Refresh tokens have a longer time limit and are used to obtain new access

tokens. Refresh tokens will become inactive when you log out.

• You can use access tokens on as many requests as needed as long as the

token is still active. You can use your software to leverage the “expires_in” data

that is provided when the token is issued and retrieve a new access token as

expiration nears.

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

3.1.4 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

28 Publication 5718

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/intake-

acceptance

Resource: /irisa2a/v1/intake-acceptance

Headers:

◼

Authorization: Bearer <Access-Token>

Request:

◼

Media Type: multipart/form-data

◼

Accepts: application/xml

Response: application/xml

Request

Attachment:

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

ContentID: “le”

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

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

29 Publication 5718

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 “le=@YOUR_1099_PAYLOAD_IN_XML_FORMAT; type=text/xml” https://

host_url/irisa2a/v1/intake-acceptance

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

30 Publication 5718

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

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

31 Publication 5718

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

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

32 Publication 5718

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

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

33 Publication 5718

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

3.2 XML Overview for IRIS

IRIS uses XML, a language that species the structure and content of electronic documents

and les to dene the electronic format of IRIS Information Returns. This section explains

some of the elements of an XML document. For detailed information regarding the IRS

Submission File structure, including the XML Schema containing the required Tag Names/

Element Names and Namespaces, refer to the schema documentation le (IRS-IRIntakeT-

ransmissionMessage.doc) in the IRIS schema package.

3.2.1 IRIS XML Schema Package Structure

This section describes the IRIS XML Schema le 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 les:

• COMMON

{

IRS-IReleTypes.xsd denes simple and complex elements that are reused across

the XML payload.

• FORM_TYPES

{

There is a le for each Information Return form, for example IRS-Form1099AType.

xsd denes the schema for Form 1099-A.

• MSG

{

IRS-IRIntakeTransmissionMessage.xsd denes complex elements at the

Transmission (manifest) and Submission levels. It also denes elds from

Submission level forms like Form 1096.

34 Publication 5718

In addition to the schema les, there are business rule les. 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.

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

(if applicable). Contains one or more forms.

3. Form: Details the form data elements.

When entering character data into an XML document, it is important to ensure that the

specied encoding supports the characters provided. By design, IRIS uses Unicode Trans-

formation 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 characters

must not be included in any of the data elds:

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

Character Character Description

-- Double Dash

# Hash Key

IRIS will reject a transmission that contains any of the special characters identied in Table 3-5.

• Example 1: If a record has a last name data eld containing MyCorp #10, then the

transmission must not include the hash key/pound sign, so that the data eld instead

contains MyCorp 10.

• Example 2: If a record has an address data eld containing NoPlaceWay--Suite 4,

then the transmission must not include the double dash, so that the data eld instead

contains NoPlaceWay-Suite 4.

35 Publication 5718

The following special characters must be escaped before they are included in any data elds

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

Additional elements may also be restricted by XML schema data element denitions. For

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. As a rule, the schema denitions must be followed.

3.2.4 Tag Names

Each eld in the transmission is identied using an XML tag name within the XML schema.

Tag names were created using the following conventions:

• A meaningful phrase with the rst 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 identies the record number

in a submission would be:

<xsd:element ref=”UniqueRecordId” minOccurs=”1” maxOccurs=”unbounded”/>

For example, below is a notional example of a complex XML element that identies all the

data element groups allowed directly in a transmission.

36 Publication 5718

Figure 3-12: IRTransmission Schema Structure

3.2.5 Attributes

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

• The rst letter of the rst word of an attribute name is lower case; the rst 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” identies that there is no limit to the number of IRSub-

mission1Grp (submissions including Form 1096) that can be included in the XML. (However,

the maximum number of submissions is constrained by the payload size limit.)

3.2.6 Repeating Group

Repeating groups are specied in XML schema denitions using the minOccurs and

maxOccurs facets on sequence or choice denitions. An example of a repeating group for

Form 1099 submissions is as follows:

<xsd:element name=”IRSubmission1Grp” type=”IRSubmission1GrpType” minOccurs=”0”

maxOccurs=”unbounded”/>

This element ‘IRSubmission1Grp’ allows a minimum of 0 or maximum of unlimited groups.

Beginning and ending tags are necessary for each group submitted. Since the minimum is

0 this element is optional and could be skipped, such as if the transmission includes only

submissions belonging to ‘IRSubmission2Grp’.

The reference element is of Type IRSubission1GrpType. This is a complex data element that

includes complex elements IRSubmission1Header and IRSubmission1Detail.

37 Publication 5718

Figure 3-13: Example of the IRSubmission1Grp Repeating Group

3.2.7 IRIS Schema and Business Rules

A schema is an XML document that species the data elements, structure and rules for the

transmission, submission, and form levels. In addition to formats dened by schemas, infor-

mation 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 attri-

butes or is the parent to one or more child elements.

The Transmitter and Issuer have the responsibility to provide information as specied 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 specied 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. Software Developers

are not required to retest when new schemas (minor or major) are posted. However, IRS

strongly recommends the use of IRIS ATS to retest when Software Developers update their

software in response to schema changes.

38 Publication 5718

Note: If there are critical changes required due to late legislation changes, national disasters,

or errors identied 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:

Each version of the XML Schemas and the corresponding business rules has a unique version

number assigned. It is important to note the following principles regarding version numbers:

• Each information return’s schema version has an associated set of business rules with

the same version number. This ensures that each updated schema version includes an

updated set of business rules.

• The “FormnnnnDetailType” complex element includes a documentation element

and dictionary entry name that identies the form including the major and minor

version numbers of the schema for each return type as well as the effective begin

date for the XML Schema. For example, the “Form1099NECDetailType” from IRS-

Form1099NECType.xsd le shown below identies the schema version as v1.0 with an

effective date of 2021-10-21.

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

• Each business rule document’s version number identies the version and effective

begin date of the business rules.

• The “Active Validating Schema Version” species 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

39 Publication 5718

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

mation 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 select the applicable form type on the

IRIS Schemas and Business Rules page to get information about all active and prior year

schemas and business rules used by IRIS Production and ATS.

3.2.9 Example of Schema Versioning

Below is a sample of the IRIS forms XML schema versioning information:

Figure 3-15: IRIS Form 1099-MISC Type Documentation

40 Publication 5718

3.3 Filing Prior Year Returns

When ling prior year (TY2022 only in PY2024), 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

Amounts to include to calculate Total Reported Amount

Form 1099-B Boxes 1d and 13

Form 1099-C Box 2

Form 1099-CAP Box 2

Form 1099-DIV Boxes 1a, 2a, 9, 10, and 12

Form 1099-G Boxes 5 and 9

Form 1099-INT Boxes 1, 3, 8, 10, 11, and 12

Form 1099-K Box 1a and 1b

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, 12, 14 and 15

Form 1099-NEC Box 1

Form 1099-OID Boxes 1, 2, 5, 6, 8 and 10

Form 1099-PATR Boxes 1, 2, 3, 5, 8, 10 and 11

Form 1099-Q Box 1

Form 1099-QA Box 1

Form 1099-R Boxes 1 and 10

Form 1099-S Box 2

Form 1099-SA Boxes 1 and 2

Form 1099-SB Box 1

Note: Total Reported Amount is optional in the schema. There is no amount total for Form

1099-A

41 Publication 5718

4. Validating the Transmission and Return Data

This section explains how the IRIS System will perform validations of the transmission and

return data via Schema validations and business rule checks. When IRIS receives a trans-

mission, the following tasks are executed in this order:

1. Verify that the UTID is unique for the Transmitter Control Code (TCC) – this happens

before TCC is validated – done by intake service.

2. The transmission payload (xml data) is read and written to persistent storage

3. The Receipt ID and Timestamp are generated

4. The Receipt ID, Timestamp, and Unique Transmission ID are returned to the Transmitter

5. Schema Validation is executed on the Input payload

6. The Payload is queued for processing against the IRIS Business Rules

7. Basic Manifest validations such as TCC and Software ID validations are performed

8. Verify Transmission Type Code, Tax Year and Transmitter and Vendor Information

9. Submission and Form contents are validated as per IRIS Business Rules

10. Errors identied during processing against the IRIS Business Rules are written to the

IRIS database and inserted into error messages. An Error Information Group will be

returned to the Transmitter in the Acknowledgement.

When errors are identied with the transmission or IRIS cannot read or write the payload

to persistent storage, the transmission will be rejected, and the appropriate error code and

description will be returned to the Transmitter in the REST Response message. If the payload

fails Schema validation, the transmission will be rejected. The appropriate error code and

description relevant to Schema validation will be returned when the Transmitter retrieves the

Acknowledgement for the respective transmission. When business rule errors are identied

during processing of the payload, IRIS will record the error codes and descriptions and

return those errors when ler invokes the Acknowledgment Service as REST response

message.

4.1 Transmission Validation

This section describes the checks that are made on the transmission and the errors that

will be returned to the Transmitter if the transmission is rejected before it can be saved for

further processing.

See Section 6.2.1 for Pre-Receipt Validation Error List

42 Publication 5718

4.1.1 Missing or Multiple Attachments

Checks for missing or multiple attachments occur during the transmission synchronous

process. IRIS rst validates at least one submission is in a transmission payload. If there is

no submission in a transmission, IRIS will reject the transmission and return the appropriate

error code and error description.

4.1.2 Error Reading or Persisting the Transmission Payload

If IRIS cannot read, or persist the data, IRIS will reject the transmission and return an error code.

4.1.3 Manifest Veriﬁcation Failure

Manifest verication checks occur after receipt processing (reading and persisting the XML

payload).

IRIS will perform the following checks against the data included in the Manifest and return

any errors found when the Transmitter retrieves the Acknowledgement for the transmission:

• Verify that the Transmitter Control Code is valid and authorized to transmit the

information returns included in the transmission

• Verify Transmission Type Code, Tax Year and Vendor Information

• Verify Foreign Entity Indicator if Foreign Address is present in payload

• Verify Software ID is authorized and set to production

4.1.4 Manifest and XML Payload Schema Validation Failure

Manifest schema validation occurs before the Transmitter has successfully submitted the

transmission to IRS. Transmission Manifest, submission headers and form data will be

validated against the schema after the Transmitter has successfully submitted the trans-

mission to IRS. IRS recommends each return be run against a validating parser prior to

being submitted to IRS. This pre-validation is intended to identify most potential error condi-

tions and minimize the chance of receiving errors. A validating parser compares the XML

document to the dened elements and attributes of the schemas to ensure a well-formed

document that adheres to the XML Schema is transmitted to IRS. Schemas provide the

basic denition for elements (i.e., eld length, data type, prescribed patterns, enumerations,

etc.). Data integrity depends on each data element complying with the data format specica-

tions. If IRIS preparation software uses IRS-dened XML schemas to create the XML infor-

mation return, there should be no data format errors in the return. The IRIS System veries

this by validating each return in the transmission payload against the schemas. The infor-

mation return documents must conform to the version of the XML schema they specify. IRIS

conducts XML schema validation on the payload before processing. Any schema validation

43 Publication 5718

failures are reported back to the originating entity. If the XML does not conform to the XML

Schema (missing required elements or XML not well formed), IRIS will reject the trans-

mission. The Acknowledgement Service REST Response contains the error codes, the error

descriptions, and the XPath reference to the element found to be in error.

5. Acknowledgement 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.

The XML payload is then queued for processing within IRIS.

When IRIS receives a status request, an Acknowledgement response is generated indicating

the status of the transmission (see below) and is available for the Transmitter to retrieve.

If there are no errors found during validation, the Error response is not included in the

Acknowledgement and the transmission processing status will be “Accepted”.

The status of the transmission includes one of the following:

• 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 identied 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

The Transmission Acknowledgement will include:

• Transmitter Control Code

• Unique Transmission ID

• Form Type Code

• Timestamp

• Transmission Status Code: Accepted, Rejected, Processing, Partially Accepted,

Accepted with Errors, Not Found

• Error Information Group (if errors are identied)

44 Publication 5718

5.1 Acknowledgement Schema

The table below shows the structure of the Acknowledgement schema:

Table 5-1: IRIS Forms Acknowledgement Schema Elements

Element Name Explanation

SearchId The search term sent in the request to the Acknowledgement Service.

Either the Receipt ID or Unique Transmission ID.

TransmissionResultGrp.

TransmissionStatusCd

One of: Accepted, Rejected, Processing, Accepted with Errors, Partially

Accepted, Not Found

TransmissionResultGrp.

ErrorInformationGrp

A specic business rule number and description associated with a

Transmission level error

SubmissionResultGrp.

SubmissionStatusCd

One of: Accepted, Accepted with Errors, Rejected, Processing, Not

Found

SubmissionResultGrp.

ErrorInformationGrp

A specic business rule number and description associated with a

Submission level error

SubmissionResultGrp.

RecordResultGrp.

ErrorInformationGrp

A specic business rule number and description associated with a

Record level error

The following elements are included in the Error Information Group:

• Error Message Code (Business Rule number)

• Error Message Text (Business Rule description)

• Error Value Text (Value of element that caused the error)

• Element Path Text (Path identifying the specic data element)

Note: The XPath identies the specic data element and instance in an enumerated group, if

applicable, causing the violation.

45 Publication 5718

6. Corrections and Replacements

Corrections can only be made to previous transmissions that have been “Accepted”,

“Accepted with Errors” or “Partially Accepted”. Corrected information returns MUST be led

electronically if the original return was required to be submitted electronically. Originals led

in FIRE must be corrected in FIRE and originals led in IRIS A2A must be corrected in IRIS

A2A. Transmitters should le corrections with IRS as soon as possible and furnish a copy

of the corrected return to the Recipient. File corrected returns to comply with ling require-

ments. Refer to General Instructions for Certain Information Returns for details.

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 noties the Transmitter of one or more errors on the information returns

(Form1099ADetail) led.

• The Transmitter identies one or more errors on the information returns

(Form1099ADetail) led.

• The Recipient reports an error.

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

The UniqueRecordId assigned by IRIS allow corrections to be linked to the original infor-

mation return.

For example: Form 1099-A data located in Submission 10, Record 2 of a transmission would

have a UniqueRecordId as follows:

2022-63385508791-4a6c57eda|10|2

46 Publication 5718

6.1.1 Transmitting Corrections

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

form was submitted:

1-Step Correction errors 2-Step Correction errors

Recipient name and/or TIN incorrect or missing

Form should not have been led for that recipient.

(In this instance, enter “0” for all amounts on

correction.)

Incorrect payment amounts in a record;

Incorrect code or indicator value

Incorrect form type, e.g.,1099-MISC led rather than

1099-NEC.

Follow the steps below for a 1-step correction:

1. Prepare a new transmission with

TransmissionTypeCd “C” in the Manifest. (Do

not mix original and corrected records in the

same transmission payload.)

2. Include an IRSubmission1Grp for each

form type and issuer being reported. (The

IssuerDetail in the SubmissionHeader(s) must

be the same as the original submission.)

3. Include the complete record for correction. Do

not submit only the corrected data.

4. The CorrectedInd in each correction

record must be set to “1”. Include the

PrevSubmittedRecRecipientGrp with the

UniqueRecordId. This element is optional in the

schema but enforced with a business rule. It

must be present on all corrected records, or the

submission will reject. Recipient Name and TIN

of the original record are optional in this group,

but ensure the correction is associated with the

original record.

Note: An original is only corrected once. If after a

correction is led and accepted, and an additional

correction is needed, use the UniqueRecordId

associated with the most recently accepted

correction.

The steps below for a 2-step correction are only

used if the original was led on the wrong form type:

1. Follow steps above for one-step correction,

entering “0” in all payment amounts.

2. Once the rst correction is Accepted, submit a

new transmission with TransmissionTypeCd “O”

in the Manifest.

3. Include an IRSubmission1Grp with the correct

form type in the IRSubmission1Header and

IRSubmission1Detail.

47 Publication 5718

6.2 Rejected Transmissions

Transmissions can be “Rejected” before or after a ReceiptId is issued. Transmis-

sions rejected before ReceiptId is issued (pre-receipt validation) cannot be replaced by

replacement process. Replacement only applies to Transmissions or Submissions rejected

by IRIS after pre-receipt validation.

6.2.1 Transmissions Rejected in Pre-Receipt Validation

When a transmission is rejected by IRIS before a ReceiptId is issued, the Transmitter must

x the problem that caused the rejection and resend the transmission.

Note: When resubmitting, use the same “TransmissionTypeCd” that was used when the

transmission was rejected by IRIS to resubmit the le. Verify the transmission size does not

exceed the maximum size limit of 100mb.

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 notied

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 notied 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 notied 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 notied via

the http response

(Unable to process

request)

Transmitter Resolves

HTTP/1.1 400 Bad

Request

No submissions in the

transmission

Request Rejected Transmitter notied via

the Acknowledgment

(No Submissions Found)

Transmitter Resolves

Schema Validation Error Error occurred validating

schema validation – data

elements are missing

or schema is not well

formed

Transmission Rejected Transmitter notied via

the Acknowledgment

(i.e. eld is missing but is

required)

Transmitter Resolves

48 Publication 5718

6.2.2 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

• Shared Submission rules: SMFXXX

• Submission1Header rules: S1HXXX

• Submission2Header rules: S2HXXX

• Shared Form rules: F1099SharedXXX

• Individual Form rules: F1099AXXX, F1099BXXX, F1099CXXX, F1099CAPXXX,

F1099DIVXXX, F1099GXXX, F1099HXXX, F1099INTXXX, F1099KXXX, F1099LSXXX,

F1099LTCXXX, F1099MISCXXX, F1099NECXXX, F1099OIDXXX, F1099PATRXXX,

F1099QXXX, F1099QAXXX, F1099RXXX, F1099SAXXX, F1099SBXXX, F1099SXXX

Note: The rst “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.

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.

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 (e.g., Submission Header with Incorrect Tax Year), which will lead

to that Submission rejection (Submission Header and information return records).

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

49 Publication 5718

6.3 Replacing an Original Transmission that Rejected

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 from the date the status

was available, the le will be treated as led on the original transmission received date. If an

acceptable replacement transmission is received after the 60 days, the le will be treated

as led on the date the replacement transmission is received. In this way, any applicable

late-ling 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.

Transmitters can replace rejected Transmissions, as well as rejected Submissions. Replace-

ments can only be transmitted for previously rejected Transmissions or Submissions. IRIS

requires replacements to use specic identiers to reference the original rejected trans-

mission/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 x 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 x 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 xed and retransmitted in a

replacement transmission (“TransmissionTypeCd” is “R”).

Exception: If a submission containing only Form 8809 is rejected, le 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 ‘Original-

ReceiptId’ of the Replacement Transmission. Replacement transmissions must include the

following requirements (see schema and business rules for additional details):

50 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 submission 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 rst (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 rst 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

business rules for additional details):

51 Publication 5718

• 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 Submis-

sion(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 ling 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 Rejected or Partially Accepted, then transmit another replacement transmission

using the Submission IDs from the original rejected submissions. In either case always

replace the rst rejected submission in the chain of rejected submissions when one or more

replacements are rejected.

52 Publication 5718

Note: First rejected Submission(s) in the chain of rejections does not relate to the order of

submission within an individual Transmission.

If ling 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 le 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.

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 le is granted, and the additional extension is led before the

expiration of the automatic 30-day extension. The additional 30-day extension request can

only be submitted by ling a paper Form 8809.

7.2 Extension of Time to Provide the Recipient Copy

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

for an extension of time to provide the Recipient copy must be postmarked by the date on

which the statements are due to the Recipients. The letter must contain the following: Issuer,

Name, TIN, Address, Type of Return, Reason for Delay, statement saying the request is for

Recipient copies, and signature of the Issuer or Authorized Agent.

53 Publication 5718

The request should be mailed to:

Internal Revenue Service

Attn: Extension of Time Coordinator

240 Murall Drive, Mail Stop 4360 Kearneysville, WV 25430

If the extension is granted, it will allow a maximum of 30 additional days to furnish copies to

the Recipients. No additional extensions are allowed.

8. Waiver from Filing Electronically

Final regulations were issued February 21, 2023, by the Department of the Treasury and the

Internal Revenue Service. Treasury Decision (TD) 9972 amend the rules for ling returns and

other documents electronically (e-le). These regulations reduce the 250-return threshold to

generally require electronic ling by lers of 10 or more returns in a calendar year beginning

in Tax Year 2023, Processing Year 2024. For Tax Year 2022 returns, the number remains

at 250. Details on this regulation can be found here: IRS and Treasury ﬁnal regulations on

e-ﬁle.

To determine if you meet the 10 or more threshold to electronically le:

• Identify how many returns of any type covered by TD 9972, you need to le during a

calendar year

• If 10 or more, you MUST le electronically

Example of return types covered by TD 9972 (not all inclusive):

• Information returns (Forms W-2, Wage and Tax Statement and Form 1099 Series)

• Certain income tax returns (example, Form 1065, U.S. Return of Partnership Income, or

Forms 1120-S, U.S. Income Tax Return for an S-Corporation)

• Employment tax returns (example, Forms 940, Employer’s Annual Federal

Unemployment (FUTA) Tax Return, Forms 941, Employer’s Quarterly Federal Tax Return)

• Certain excise tax returns (example, Form 4720, Return of Certain Excise Taxes on

Charities and Other Persons Under Chapters 41 and 42 of the IRC.)

Refer to Treasury Decision (TD) 9972 for more information.

The electronic ling requirement does not apply if you apply for and receive a hardship

waiver. If the ler is required to submit information returns electronically and fails to do so,

and there is not an approved waiver on record, the ler may be subject to a penalty for

failure-to-le 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 led 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 led electronically and

must be submitted to the address shown in the instructions for Form 8508.

Refer to Form 8508 for detailed instructions on completing the form and Publication 1220

for more information.

54 Publication 5718

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

The Combined Federal/State Filing (CF/SF) Program was established to simplify information

returns ling for issuers. Through the CF/SF Program, the IRS electronically sends infor-

mation returns (original and corrected) to participating states.

If you participate in the IRS 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 ling 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 Prot-Sharing Plans,

IRAs, Insurance Contracts, etc

The following table provides the participating states in the CF/SF Program. Each state’s ling

requirements are subject to change by the state. It’s the ler’s responsibility to contact the

participating state(s) to verify their criteria and special data entry requirements.

states

Alabama Indiana Nebraska

Arizona Kansas New Jersey

Arkansas Louisiana New Mexico

California Maine North Carolina

Colorado Maryland North Dakota

Connecticut Massachusetts Ohio

Delaware Michigan Oklahoma

District of Columbia Minnesota Pennsylvania

Georgia Mississippi South Carolina

Hawaii Missouri Wisconsin

Idaho Montana

55 Publication 5718

10. Other Helpful Information

10.1 Due Dates

Filing Form 1099 series occurs on a calendar year basis. For ling due dates for other infor-

mation returns, please refer to the General Instructions for Certain Information Returns

(forms 1096,1097, 1098, 1099, 3921, 3922, 5498 and W-2G).

Form IRS Electronic Filing Furnish Copy to Recipient

1099 Series March 31 January 31 and February 15 for forms

1099-B and 1099-S. This also applies to

statements furnished as part of a consoli-

dated reporting statement

1099-MISC March 31 January 31 and February 15 for amounts

reported in boxes 8 or 10

1099-NEC January 31 January 31

Note: If any due date falls on a Saturday, Sunday, or legal holiday, the return or statement is

considered timely if led or furnished on the next business day,

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)

Name Control for Businesses, see Section 3.11 in Publication 4163, Modernized e-File

(MeF) Information for Authorized IRS e-ﬁle Providers for Business Returns and Correct

Name Control for Corporations and Correct Name Control for Partnerships

Name Control for Individuals, see Exhibit 5 in Publication 4164, Modernized e-File (MeF)

Guide for Software Developers and Transmitters

56 Publication 5718

10.4 Additional Resources

Webpage References Description

www.irs.gov/inforeturn Learn about the differences between IRIS and other ling

systems such as the Filing Information Returns Electronically

(FIRE) system

www.irs.gov/iris Access the Taxpayer Portal, subscribe to QuickAlerts and

locate Help Desk contacts

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

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-le 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

www.irs.gov/iris E-File Forms with IRIS

11. Acronym List

Acronym Description

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

ID Identication

IR Information Returns

IRIS Information Returns Intake System

IRS Internal Revenue Service

iss issuer

jti JWT ID

57 Publication 5718

Acronym Description

JWK JSON Web Key

JWKs JSON Web Key Set

JWT JSON Web Token

kid Key identier

MeF Modernized e-File

OUSID Original Unique Submission Identier

P Production

PY Processing Year

RID Record Identier

RO Responsible Ofcial

SID Submission Identier

SOR Secure Object Repository

sub subject

T Test

TCC Transmitter Control Code

TD Treasury Decision

TFA Taxpayer First Act

TIN Tax Identication Number

TY Tax Year

URID Unique Record Identier

UTF-8 Unicode Transformation Format-8

UTID Unique Transmission Identier

UUID Universally Unique Identier

XML Extensible Markup Language

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