FIRE accepted a fixed-width Publication 1220 text file, but IRIS accepts self-describing XML, which means a legacy file cannot simply be uploaded as it stands. Converting it is a three-part job: you parse each FIRE record by its character position, you split the fields the IRS now wants kept separate — the payee name most of all — and you emit the named XML elements that the schema and the business rules will accept. Because FIRE retires after December 31, 2026, every filer still on the old format has exactly one conversion ahead of them, and if your deadline will not wait, a provider that already holds an IRIS TCC can file from the files you produce today.
In this story
Why a FIRE File Cannot Just Be Uploaded
A FIRE submission is a stream of fixed-width records built to IRS Publication 1220, where the transmitter, payer, payee, and end records each pin every field to a known character position. IRIS does not read that layout at all, and that single fact is what forces a conversion rather than a re-upload.
IRIS is built on XML, a format in which every value lives inside a named element instead of a column range. That is not a cosmetic difference. A position-based file is just bytes until something parses the layout and tells you which characters mean what, whereas an XML document carries its own structure with it, and that self-description is exactly what lets the IRS validate the file the instant it arrives. So “converting” is never a reformat — it is the work of reading the meaning out of each FIRE position and re-expressing that meaning as the element the IRIS schema expects. The broader move off the old system is covered in our step-by-step FIRE-to-IRIS migration walkthrough; this guide zooms all the way in on the file itself.
The IRIS schema, its element definitions, and the assurance test scenarios are spread across three publications: the Portal guide in Pub 5717, the A2A specification in Pub 5718, and the assurance testing package described in Pub 5719. The legacy layout you are converting from is the one defined in Publication 1220. The element names used throughout this guide follow IRS schema conventions, and where an exact name matters you should treat the published schema as the source of truth.
The Record-Layout Map: FIRE Records to IRIS Levels
Before you touch a single field, line up the two structures against each other. FIRE’s flat records collapse into the three nesting levels IRIS uses — a Transmission that wraps Submissions, each of which carries a Payer and that payer’s form records. The row to watch is the B record, because that one fixed-width line explodes into the most XML, and it is where most conversions go wrong.
| FIRE record | What it carries | IRIS equivalent |
|---|---|---|
| T record | Transmitter, TCC, test/prod flag | The Transmission level — the manifest, the TCC, and a TestFileCd set to T or P. |
| A record | Payer name, EIN, address | The Payer group inside each Submission. |
| B record | Payee name, TIN, amounts, state data | The form record, such as Form1099NEC — the name splits, the address becomes a structure, and each box becomes its own element. Most conversion errors live here. |
| C / K / F records | Totals and end-of-file controls | Largely implicit — IRIS derives totals from the records themselves rather than from hand-keyed control lines. |
From Flat File to XML: The Name Split
The single most common transformation in the whole conversion is the payee name. In FIRE, the B record holds the name as one fixed-width blob sitting at a known position, padded out with spaces to fill its column range. In IRIS, an individual’s name splits into discrete, typed elements — PersonFirstNm and PersonLastNm — while a business uses a business-name line instead of either of those. Getting this split right is the heart of the conversion, which is why it deserves a worked example before anything else. Hover a line on either side to see how each position maps to its element.
<Form1099NEC>
<PayeeNm>
<PersonFirstNm>MARIA</PersonFirstNm>
<PersonLastNm>RODRIGUEZ</PersonLastNm>
</PayeeNm>
<NonemployeeCompensationAmt>1500.00</NonemployeeCompensationAmt>
</Form1099NEC>Field-Level Mapping: What Splits, What Stays
Most FIRE positions map cleanly to a single element, but a handful either split into several elements or change type along the way, and those are the conversions worth keeping a checklist for. The element names below follow IRS schema conventions, and each row tells you not just the destination but what the transform actually has to do to the value.
| FIRE field (B record) | IRIS element(s) | What the conversion does |
|---|---|---|
| Payee name line | PersonFirstNm + PersonLastNm | One blob splits into two elements, and a business is routed to a business-name line instead of either of these. |
| TIN + TIN type position | TINTypeCd + TIN | Strip any hyphens down to nine bare digits; the type code is what distinguishes an EIN from an SSN or ITIN. |
| Address block | USAddressGrp | One free-text region becomes separate street, city, StateAbbreviationCd, and ZIP elements. |
| Payment-amount fields | Named amount element per box | Each numbered amount position becomes its own named element, such as NonemployeeCompensationAmt, typed and decimal-formatted. |
| State withholding positions | StateAbbreviationCd / StateTaxWithheldAmt | The CF/SF character positions become a structured group that is validated as a set — the most error-prone part of the conversion. |
How to Convert, Step by Step
Once you have the field map in front of you, a reliable conversion becomes mechanical. The trick is to work in the order below, because each step removes an entire class of error before the next one can compound it — you parse before you transform, you transform before you emit, and you validate before anything reaches the IRS.
Parse the FIRE file by position
Read the T, A, and B records against the Publication 1220 layout and pull each field out by its character range into a clean, typed value. Do not skip the test/prod flag on the T record, because it is what becomes TestFileCd in the manifest.
Normalize and split fields
Trim the padding, strip the hyphens from TINs so they are nine digits, split the payee name into first and last or route it to a business-name line, and break the address into its component elements.
Transform layerBuild the three-level XML
Emit a Transmission that wraps one Submission per payer, with each submission carrying its Payer group and its form records, one named element per amount box, and the full CF/SF group wherever it applies.
Validate against the XSD locally
Run your output through the published IRIS schema before any of it reaches the IRS. Every structure error and every type error surfaces here, instantly and for free, on your own machine.
Schema checkPass ATS, then transmit
An A2A transmitter must clear the IRIS Assurance Testing System described in Pub 5719 before it can file in production. Send with TestFileCd set to T, confirm acceptance, and only then flip it to P for the live file.
Two Layers of Validation: Schema vs Business Rules
Your converted XML is checked twice, and the two checks fail for completely different reasons, so knowing which layer rejected you immediately tells you whether the bug is in your structure or in your data. Treating them as one thing is the fastest way to waste an afternoon fixing the wrong layer.
Layer 1 — Schema (structure & types)
The schema layer asks whether the document is well-formed: are the required elements present, are they in the right order, and does each value match the type it is declared to hold? A missing element, a TIN that still carries a hyphen, or a stray letter inside an amount field all fail here, before the IRS has looked at what the numbers actually mean. This is precisely the layer your local XSD validation catches for you.
Layer 2 — Business rules
Once the shape is valid, the IRS applies its catalog of business rules, which are cross-field checks with stable rule IDs that test what a schema simply cannot — that a CF/SF block is internally consistent, that totals reconcile, that a state code is a real one. You can read the full IRIS business-rule catalog to see exactly what this layer enforces and where it bites. Clear both layers and IRIS returns a Receipt ID confirming that your submission was accepted.
Stressed about hand-building this conversion?
e1099f reads the FIRE-format Publication 1220 files you already produce and emits validated IRIS XML — every field split and every state group generated for you.
Common Rejection Reasons (and How to Avoid Them)
Four conversion mistakes account for the bulk of first-time rejections, and each one maps to a specific validation layer. The good news is that they are all converter bugs rather than data problems — fix each one once in your transform logic and it never comes back.
Cause: the whole FIRE name blob is pushed into a single element, or a business name is forced into PersonFirstNm and PersonLastNm when it should never have been. Fix: detect the entity type during the transform step and route individuals to the person-name elements while routing businesses to the business-name line.
Cause: a TIN carried over with its hyphens intact, or an amount that kept currency symbols, commas, or the implied decimal that the fixed-width field used. Fix: normalize in the transform step so that TINs are nine bare digits and amounts are plain decimal numbers typed exactly as the schema declares them.
Cause: a non-USPS value lands in StateAbbreviationCd because a position was mis-parsed, or state withholding is emitted without its matching state block. Fix: use valid two-letter codes and emit the full CF/SF group together, because the rule layer checks that group as a single consistent set.
Cause: the T-record test/prod indicator was dropped on the way in, or an old FIRE TCC was reused — and a FIRE TCC does not work on IRIS. Fix: set TestFileCd explicitly and supply your IRIS TCC, because nothing inside the transmission is even read until the manifest itself validates.
Validate Before You File
Two cheap habits prevent almost every conversion rejection, and both of them happen well before any production data leaves your network. The first runs entirely on your own machine, and the second is a mandatory step the IRS already built for you.
- Validate against the XSD locally. Running your output through the published schema catches every schema-layer error before a single byte reaches the IRS; it is instant, it costs nothing, and it confirms that your converter is emitting the structure the schema expects.
- Run the ATS scenarios. Every A2A transmitter has to pass the IRS Assurance Testing System described in Pub 5719 before going to production, and it exercises the business-rule layer with both known-good and known-bad cases, which is exactly where state and cross-field bugs come to the surface.
For the element-by-element reference behind every tag named above — including the structure, the required elements, and how to validate a complete submission — see the IRIS XML schema and validation guide.
Never Hand-Build the Conversion
You can write and validate the parser, the field splits, and the XML emitter yourself, and this guide is meant to make that entirely doable. The alternative is to skip the whole pipeline: e1099f turns the FIRE-format files you already produce into schema-valid, rule-checked IRIS XML, so the conversion becomes something you upload rather than something you build.
FIRE files in, XML out
Upload your Publication 1220 flat files and every field is parsed and mapped to the right IRIS element, including the name split that trips up most converters.
Both layers pre-checked
Schema and business rules are both validated before submission, so what comes back is a Receipt ID rather than a rejection.
CF/SF handled
State elements are emitted and validated automatically, with no character-position guesswork left on the B record.
Valid IRIS XML for every form type — without writing a single line of converter code.
Frequently Asked Questions
Can I upload my FIRE flat file straight into IRIS?
What is the single hardest field to convert?
PersonFirstNm and PersonLastNm and routes businesses to a separate business-name line. Mishandling that split is the most common rejection.Does my FIRE TCC carry over to IRIS?
How should TINs and amounts be formatted in IRIS XML?
What happens to the C, K, and F control records?
How do I handle combined federal/state (CF/SF) data?
StateAbbreviationCd, the withholding amount, and the payer’s state account elements — that must be emitted and validated together. Emitting the pieces individually triggers a business-rule rejection.Can I test my converted XML before filing for real?
Where are the official element definitions?
How long do I have to convert before FIRE goes away?
Does e1099f require me to understand any of this conversion?
Not tax advice. This is general information about IRS procedures. The element names and record layouts here follow IRS schema and Publication 1220 conventions and may change as the IRS updates IRIS; Publications 5717–5719 and the published schema are authoritative. Consult a tax professional for your situation and verify current requirements before building against them.