Both documents describe how to hand 1099 data to the IRS. Publication 1220 does it with character positions in a text file. Publication 5718 does it with XML and a schema. The data is identical. Almost everything about how you express it is not.
- Pub 1220
- FIRE · fixed-width ASCII · retires Dec 31, 2026
- Pub 5718
- IRIS A2A · XML · required from Jan 2027
- Record length
- 750 characters per Pub 1220 record
- Pub 1220 records
- T · A · B · C · K · F
- Pub 5718 root
- IRTransmission
- Transmission
- Manifest + submissions + records · max 100MB
- Types
- O original · C correction · R replacement
- Amount fields
- Codes 1-9 then A-J · I is skipped
Which publication is which
Six numbers get cited interchangeably and they are not interchangeable. Keep this straight and most IRIS documentation stops being confusing.
- Pub 1220
- FIRE fixed-width specification. The format that is going away.
- Pub 5718
- IRIS A2A specification. XML, schemas, business rules, transmission.
- Pub 5717
- IRIS Taxpayer Portal user guide. The web route, not the API.
- Pub 5719
- IRIS assurance testing package. The transmitter communication test and the Test to Production move.
- Pub 5903
- Tutorial for the IRIS Application for TCC.
- Pub 1099
- General instructions for information returns. Deadlines and penalties.
How the records map
A Pub 1220 file is a sequence of 750-character records, each opening with a type letter. Those types have IRIS equivalents, though two of them stop being your responsibility.
The C and F records are the interesting losses. In FIRE you compute and write your own issuer totals and terminate the file yourself. In IRIS both are structural, which removes a whole class of arithmetic bug and a whole class of truncated-file bug.
What actually changes
- 01
Position versus name
In Pub 1220 a field is defined by where it sits. Payee state lives at positions 488 to 489 and nothing in the file says so. In Pub 5718 the same value is a named element, so a reader can tell what it is without a spec open beside them.
- 02
Silence versus rejection
A fixed-width file with a field one character off is still a valid file. It just means something different. XML validated against a schema fails loudly instead, which is better, with one sharp caveat covered below.
- 03
Implicit versus explicit structure
Pub 1220 relies on record order: an A record opens a payer block, B records follow, a C record closes it. Break the order and meaning changes silently. XML nests the same relationship, so a payee cannot float free of a payer.
- 04
One file versus one transmission
Pub 1220 thinks in files you upload. Pub 5718 thinks in transmissions you send, each with a manifest, a receipt, and an acknowledgement you fetch back. The unit of work changes, not just the syntax.
Five traps in the conversion
These are the ones that produce a file the IRS accepts and a filing that is wrong, which is far worse than a rejection.
- 01
Amount codes are not box numbers
The single most expensive misunderstanding in the whole conversion. In a Pub 1220 B record, the money fields are keyed by payment amount code, running 1 through 9 then A through J, with I skipped to avoid confusion with the digit 1. Those codes are not the box numbers printed on the paper form. On a 1099-DIV, federal income tax withheld is box 4 on paper but amount code A in the file. Map by code and the dollars land in the right IRIS element. Map by box, and you produce a file that is structurally valid, passes schema validation, and reports the wrong numbers to the IRS. Our amount-code lookup lines up every code with its paper box and IRIS element, for all seven forms.
- 02
Amounts are in cents, right-justified and zero-filled
Twelve characters per amount field, no decimal point, leading zeros. A payment of $15,000.00 is written as 000001500000. Software that writes a decimal point, left-justifies, or pads with spaces produces a file FIRE would have taken and a converter will reject.
- 03
A schema-invalid transmission cannot be replaced
This is the caveat to “XML fails loudly.” Per Publication 5718, a transmission rejected for schema validation errors still receives a ReceiptId, but you cannot use the normal replacement process. You must refile it as a new Original, with a new filing date. Validating before you transmit is not a nicety.
- 04
The schemas are not public
You can read Pub 5718 as a PDF, but the actual XSDs and business rules arrive in your e-Services mailbox and only once you hold a TCC, as the IRS schemas page states. Anyone planning to build against the format needs the TCC first.
- 05
The schema changes every tax year
A new schema version ships per tax year, and returns filed in January 2027 are tax-year 2026 returns. Tooling built and tested against the TY2025 schema is not automatically correct for the season it will actually be used in.
How a 5718 transmission is built
A transmission is an XML payload with a manifest and one or more submissions, each holding one or more records. The manifest carries the transmitter data and the transmission data, including the Unique Transmission Identifier, the TCC, and the type code. Each submission holds one form type for one tax year, and the record count in the header must match the records inside. Omit tags for optional elements left empty. Per Publication 5718, one transmission holds one type only: Original, Correction, or Replacement.
The payload cap is 100MB. A transmission with several submissions may mix submission groups, forms, and issuers, but each submission keeps one form type and one tax year.
Schemas plus business rules: two gates
The schema checks structure. The business rules check content. A file must pass both. The IRS ships one schema for the transmission and submission levels and one schema per form, each with its own rule set. Software must place data per the schema and satisfy the rules at the same time.
Versions move per tax year. A transmission names its version in the manifest element SchemaVersionNum; VersionNum and VersionDt are the schema package's own stamps, inside the XSD header, not elements you emit. The IRS validates against the active validating schema version for the return type, so a file built on an older minor version may still be accepted but is judged against the active version. Schema and rule packages arrive through the e-Services mailbox after TCC approval, and QuickAlerts announce revisions. Build against the tax year you will file, not the one you tested last spring.
See the IRS schemas and business rules page for the current package and start dates.
A2A prerequisites, in order
TCC first. Then the API Client ID application with a JWKS upload, then the consent step that yields the IRIS User ID. Each token request signs two short lived assertions, one for the client and one for the user. Submission is a multipart upload of the IRTransmission XML. Status and acknowledgement are separate fetches by ReceiptId or UTID.
Start the TCC early. Approval takes 30 to 45 days, and the schemas stay gated until it lands. The TCC guide covers the application queue.
- 01
Accepted
The IRS processed the transmission and accepted it. Keep the acknowledgement with the ReceiptId.
- 02
Rejected
The IRS could not process the transmission. The acknowledgement lists the errors. Fix them and send a replacement or a new original, as the rules below require.
- 03
Processing
The IRS has not finished. Poll again with the ReceiptId or UTID.
- 04
Partially Accepted
At least one submission was accepted and at least one was rejected as unusable. Fix the rejected submissions and resend them in a replacement transmission.
- 05
Accepted with Errors
The transmission was accepted but some records carry errors. The acknowledgement lists them. Correct the accepted records that need it.
- 06
Not Found
The ReceiptId or UTID does not exist in IRIS. Check the identifier before retrying.
Rejections, replacements, corrections
A transmission rejected for schema errors still receives a ReceiptId, but it cannot be replaced. Fix the XML and resend it as a new Original with a new identifier. A transmission rejected before receipt, such as a duplicate UTID or an oversize payload, is fixed and resent under the same transmission type.
A rejected Original becomes a Replacement carrying the OriginalReceiptId of the rejected transmission. A replacement received within 60 days keeps the original received date for penalty purposes. After 60 days the replacement date controls. Wait for the acknowledgement to read Rejected or Partially Accepted before replacing.
A rejected Correction resends as a Correction, not a replacement. A rejected submission inside a Partially Accepted transmission is fixed and resent inside a replacement transmission. One exception: a rejected Form 8809-only submission refiles as an Original. Sources: Publication 5718 sections 5 and 6, plus Publication 5719 for the test path.
In assurance testing, anything short of Accepted is fixed and resent as a new original until the transmission reads Accepted. A Help Desk call then moves the TCC from Test to Production. Test TINs start with three zeros. The transmitter group carries the real TCC EIN and name.
Three rejections we hit, and what caused them
From our own assurance testing against the IRS in September 2026. Two of the three come from the business rules rather than the schema, which is the point of the section above.
- 01
TMFST020: the Software ID year must match the tax year
The rule: the first two digits of the Software ID must equal the last two digits of the tax year. We sent a tax year 2025 transmission with a 26M Software ID, because that is the package the TCC application had issued. Fixing it meant adding a tax year 2025 software package to the application, not changing the XML. Check this before assurance testing opens, not during it.
- 02
S1H017: the form totals group is required
The rule: a Submission 1 must carry a totals group for its form type, and one per elected Combined Federal/State Filing state. The schema marks that group optional, so a generator that follows the XSD alone omits it and every production filing rejects. The business rules, not the schema, are what require it. This is the clearest case for treating the two as separate gates.
- 03
SMF027: test filings need 000-prefixed TINs
The rule: when the test code is T, the first three digits of the issuer TIN must be 000. Publication 5719 says to use test TINs, and the IRS enforces it at submission. Real client data cannot be used for assurance testing, so a validator that rejects a 000 TIN as malformed blocks its own test path.
Portal or A2A for a 200-return firm
The Portal caps each submission at 100 returns. A 200-return firm needs at least two Portal submissions plus manual upload work each time. A2A sends the same 200 returns in one transmission within the 100MB cap.
The fields match and the containers do not. The Portal takes CSV and the API takes XML, and neither accepts the other. A2A needs a TCC, a Client ID with JWKS, and consent, with weeks of lead time. The Portal needs an IRIS account. One small client under the cap points to the Portal. Many clients or anything above the cap points to A2A, and the setup repays itself in the first January.
What to do with this
If you are buying software, the question to ask a vendor is not whether they support IRIS. It is which tax year's schema they target, and whether they map payment amounts by Pub 1220 code or by paper box number. The second question separates tools that were built from the specification from tools that were built from a screenshot of a form.
If you are building it, get the TCC first, because the schemas are gated behind it, and read Publication 5719 early so assurance testing is not a surprise. If you are staying on the free web route, Publication 5717 and our Portal limits guide are the relevant reading.
Either way, the file you feed the process decides the outcome. Our free FIRE file validator checks a Pub 1220 file against these rules in your browser, including whether each amount code is legal for its form. Nothing is uploaded.
Questions
- What is IRS Publication 1220?
- The specification for the fixed-width ASCII file format used by the FIRE system. It defines record types, field positions, and payment amount codes for 1099-series and other information returns. FIRE retires on December 31, 2026, so Pub 1220 stops being a filing format after that.
- What is IRS Publication 5718?
- The specification for IRIS Application-to-Application filing. It defines the XML transmission format, the schema validation rules, the business rules, and how transmissions and acknowledgements move between you and the IRS.
- Is Publication 5718 a replacement for Publication 1220?
- In practice yes, though they are not parallel documents. Pub 1220 describes one file layout. Pub 5718 describes a transmission protocol with a schema attached. The data is the same 1099 data; almost everything about how it is expressed changes.
- Are Pub 1220 amount codes the same as the box numbers on the form?
- No, and assuming they are is the most common conversion error. They diverge on several forms. On a 1099-DIV, federal income tax withheld is box 4 on the paper form but amount code A in the file. A converter that maps by box number produces a valid file with the money in the wrong places.
- Can I keep producing a Pub 1220 file after FIRE retires?
- You cannot file one with the IRS, but the file itself is still useful. Converters accept Pub 1220 fixed-width as input and emit the IRIS XML the IRS now expects, so an existing export from accounting or payroll software does not have to be rebuilt.
- Which publication covers the free IRIS Portal?
- Publication 5717. Pub 5718 is the A2A API specification and does not apply to Portal filing.
- How do I know whether my Pub 1220 file is correct?
- Validate it against the specification before conversion. Structure, record lengths, TIN formats, state and country codes, and whether each payment amount code is one the form actually permits. IRISfile offers a free browser-based validator that checks all of those.
- What is inside a Publication 5718 transmission?
- A manifest, one or more submissions, and one or more records per submission. The manifest identifies the transmitter and the transmission with a Unique Transmission Identifier. Each submission holds one form type for one tax year, and the header count must match the records inside. The whole transmission must stay under 100MB.
- What is the difference between a replacement and a correction?
- A replacement fixes a rejected transmission or submission and carries the original ReceiptId forward. A correction fixes a record the IRS already accepted and references the accepted record. A schema-invalid transmission cannot be replaced at all and must be resent as a new original.
- What does Accepted with Errors mean?
- The IRS accepted the transmission but flagged errors on specific records. The acknowledgement lists them. Review each flagged record and file a correction where the data was wrong.
- Do I need an API Client ID for Portal filing?
- No. The Client ID, the uploaded JWKS key set, and the consent step that yields an IRIS User ID apply to A2A API filing only. Portal filing needs an IRIS account and a TCC, not a Client ID.
- What do IRIS rejection codes S1H017, TMFST020, and SMF027 mean?
- S1H017 means the submission is missing the totals group its form type requires, which the business rules demand even though the schema marks it optional. TMFST020 means the first two digits of the Software ID do not match the last two digits of the tax year. SMF027 means a test transmission carried an issuer TIN that does not start with 000. We hit all three during assurance testing in September 2026.
- Should a 200-return firm use the Portal or A2A?
- The Portal caps each submission at 100 returns, so 200 returns means at least two uploads plus manual handling each time. A2A sends them in one transmission up to 100MB. Firms that file for many clients or above 100 returns repay the TCC and Client ID setup in the first January.