Convert FIRE Flat Files to IRIS XML

FIRE File Structure: Publication 1220 Record Layout

The IRS FIRE system uses fixed-width flat files specified in IRS Publication 1220. Every file follows a strict positional format where each field occupies a predefined byte range within a record. Each record is exactly 750 characters, padded with spaces.

A valid FIRE file contains five record types, always in this order:

T Record (Transmitter)

One per file. Identifies the organization transmitting the data to the IRS. Contains the transmitter's TIN, Transmitter Control Code (TCC), and contact information.

Position   Field                        Length  Description
1          Record Type                  1       Always "T"
2-10       Payment Year                 4       Tax year (e.g., "2025")
6-14       Prior Year Indicator         1       "P" if prior year, blank if current
10-18      Transmitter TIN              9       9-digit EIN, no hyphens
19-58      Transmitter Control Code     5       IRS-assigned TCC
59-98      Blank                        7       Reserved
99-138     Test File Indicator          1       "T" for test, blank for production
139-178    Foreign Entity Indicator     1       "1" if foreign, blank if domestic
179-218    Transmitter Name             80      Left-justified, blank-filled
219-258    Transmitter Name (cont.)     80      Continuation of name
259-298    Company Name                 80      Left-justified, blank-filled
...        (continues to position 750)

A Record (Payer)

One per payer per form type. Identifies who is issuing the information returns. Contains the payer's TIN, name, address, and the type of return being filed (e.g., 1099-NEC, 1099-MISC).

Position   Field                        Length  Description
1          Record Type                  1       Always "A"
2-5        Payment Year                 4       Tax year
6          Combined Federal/State       1       "1" if CF/SF, blank otherwise
7-11       Blank                        5       Reserved
12-20      Payer TIN                    9       9-digit EIN or SSN
21-24      Payer Name Control           4       First 4 chars of payer name
25         Last Filing Indicator        1       "1" if final filing
26-27      Type of Return               2       "A"=1099-A, "NE"=1099-NEC, etc.
28-43      Amount Codes                 16      Which amount fields are used
...        (continues to position 750)

B Record (Payee)

One per recipient. This is the core data record containing the payee's TIN, name, address, and payment amounts. Each B record represents one information return (one 1099 form sent to one recipient).

Position   Field                        Length  Description
1          Record Type                  1       Always "B"
2-5        Payment Year                 4       Tax year
6          Corrected Return Indicator   1       "G" for corrected, blank if original
7-10       Name Control                 4       First 4 chars of payee last name
11         Type of TIN                  1       "1"=EIN, "2"=SSN, blank=unknown
12-20      Payee TIN                    9       9-digit TIN, no hyphens
21-40      Payer Account Number         20      Payer's internal account ID
41-54      Payment Amount 1             14      Right-justified, zero-filled (cents)
55-68      Payment Amount 2             14      Same format
...
181-194    Payment Amount A             14      Up to 10 amount fields
...        (continues to position 750)

C Record (End of Payer)

One per A record. Contains control totals (number of payees and sum of amounts) for the preceding payer group. Used for IRS validation.

F Record (End of Transmission)

One per file. Contains the total number of A records in the file. Marks the end of the transmission.

The key thing to understand: FIRE files are flat. Every piece of data lives at a fixed byte position. There is no hierarchy, no nesting, no element names. The structure is entirely implicit.

IRIS XML Structure: Schema and Element Hierarchy

IRIS uses XML, a fundamentally different paradigm. Instead of byte positions, data is organized into named elements with an explicit hierarchy. The schema is defined in IRS Publication 5717 and published as XSD files for A2A (Application-to-Application) integrations.

A simplified IRIS XML submission looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Manifest>
  <SubmissionId>unique-submission-id</SubmissionId>
  <TaxYear>2025</TaxYear>
  <Transmitter>
    <TIN>123456789</TIN>
    <TCC>ABCDE</TCC>
  </Transmitter>
</Manifest>

<FormData>
  <Form1099NEC>
    <Payer>
      <PayerTIN>987654321</PayerTIN>
      <PayerName>
        <BusinessName>Acme Corporation</BusinessName>
      </PayerName>
      <PayerAddress>
        <Address1>123 Main Street</Address1>
        <City>Springfield</City>
        <State>IL</State>
        <ZipCode>62704</ZipCode>
      </PayerAddress>
    </Payer>
    <Payee>
      <PayeeTIN>111223333</PayeeTIN>
      <PayeeName>
        <FirstName>Jane</FirstName>
        <LastName>Doe</LastName>
      </PayeeName>
      <PayeeAddress>
        <Address1>456 Oak Avenue</Address1>
        <City>Chicago</City>
        <State>IL</State>
        <ZipCode>60601</ZipCode>
      </PayeeAddress>
      <NonemployeeCompensation>50000.00</NonemployeeCompensation>
      <FederalIncomeTaxWithheld>0.00</FederalIncomeTaxWithheld>
    </Payee>
  </Form1099NEC>
</FormData>

Notice the differences: XML uses named elements, has a clear parent-child hierarchy, separates payer from payee data explicitly, and uses decimal amounts instead of zero-padded integers. For a complete walkthrough of IRIS XML elements and validation rules, see our IRIS XML format guide.

Mapping FIRE Fields to IRIS XML Elements

The core of any FIRE-to-IRIS conversion is the field mapping. Here are the key mappings for a 1099-NEC (the most commonly filed form). Similar patterns apply to other 1099 variants:

FIRE Record	FIRE Position	FIRE Field	IRIS XML Element	Notes
T	10-18	Transmitter TIN	<Transmitter><TIN>	Same 9-digit format
T	19-23	TCC	<Transmitter><TCC>	Must be IRIS TCC, not FIRE TCC
A	12-20	Payer TIN	<Payer><PayerTIN>	Same 9-digit format
A	133-212	First Payer Name Line	<PayerName><BusinessName>	Trim trailing spaces
A	293-332	Payer City	<PayerAddress><City>	Trim trailing spaces
A	333-334	Payer State	<PayerAddress><State>	2-letter code, same format
A	335-343	Payer ZIP	<PayerAddress><ZipCode>	May need to trim 9-digit to 5+4
B	12-20	Payee TIN	<Payee><PayeeTIN>	Same 9-digit format
B	249-328	First Payee Name Line	<PayeeName><FirstName> / <LastName>	Must parse name into components
B	41-54	Payment Amount 1	<NonemployeeCompensation>	Convert from cents integer to decimal
B	55-68	Payment Amount 2	<FederalIncomeTaxWithheld>	Convert from cents integer to decimal
B	6	Corrected Return Indicator	<CorrectedReturnIndicator>	"G" in FIRE maps to correction element in XML

This table covers the most common fields, but a full 1099-NEC has dozens of fields, and other form types (1099-MISC, 1099-INT, 1099-DIV, 1099-R) each have their own unique amount fields and element mappings.

Common Conversion Challenges

A straightforward field-to-element mapping sounds simple, but real-world FIRE files introduce several challenges that make conversion non-trivial:

1. Character Encoding

FIRE files are ASCII-only. Names, addresses, and other text fields are restricted to the ASCII character set with no support for accented characters or Unicode. IRIS XML uses UTF-8 encoding. While this is generally backwards-compatible with ASCII, you must ensure your XML declaration specifies encoding="UTF-8" and that any extended characters in your source data are handled properly. Characters like ampersands (&), angle brackets (<, >), and quotation marks (") must be XML-escaped.

2. Amount Formatting

FIRE stores all payment amounts as right-justified, zero-filled integers representing cents. For example, $50,000.00 is stored as 00000005000000 in a 14-character field. IRIS XML uses decimal notation with two decimal places: 50000.00. Your conversion must divide by 100 and format correctly. Watch for edge cases like zero amounts (which may need to be omitted entirely in XML) and negative amounts in correction scenarios.

// FIRE: 14-character zero-padded integer (cents)
00000005000000  =>  $50,000.00

// IRIS XML: Decimal with two decimal places
<NonemployeeCompensation>50000.00</NonemployeeCompensation>

3. TIN Handling

Both systems use 9-digit TINs without hyphens or formatting characters. However, FIRE's B record includes a Type of TIN indicator (position 11) that distinguishes EINs from SSNs. IRIS XML handles this distinction through element naming or attributes depending on the form type. Make sure your conversion preserves TIN type information. Also note that IRIS validates TINs more strictly — invalid patterns that FIRE might have accepted may be rejected by IRIS.

4. Name Parsing

FIRE stores payee names in up to two 80-character lines of plain text. IRIS XML often requires structured name elements: <FirstName>, <MiddleName>, <LastName>, <Suffix>, or <BusinessName>. Parsing a FIRE name field like "DOE JANE M" or "SMITH JR ROBERT" into its component parts is error-prone, especially with business names, trusts, and estates.

5. Address Normalization

FIRE address fields are fixed-width and space-padded. IRIS expects trimmed, properly formatted address elements. Foreign addresses require different element structures in XML than domestic addresses. The FIRE foreign entity indicator must be mapped to the correct XML address schema.

6. State Filing (Combined Federal/State)

FIRE handles Combined Federal/State Filing (CF/SF) through a flag in the A record and state-specific fields in the B record. IRIS structures state filing information differently. Make sure state income tax withheld and state identification numbers are mapped to the correct IRIS XML elements.

Validation Differences Between FIRE and IRIS

FIRE and IRIS apply different validation rules, which means a file that passed FIRE validation may fail IRIS validation:

Validation Area	FIRE Behavior	IRIS Behavior
TIN format	Basic 9-digit check	Pattern validation (EIN vs SSN prefixes)
Amount fields	Accepts zero-filled fields	May reject if no amounts are populated
Required fields	Relatively lenient	Strict schema validation — missing required elements cause rejection
Error reporting	Acknowledgment file with codes (e.g., "Error Record 0014")	Structured XML error responses with specific messages
Real-time feedback	Batch processing, results available later	A2A can provide faster feedback; Taxpayer Portal shows errors immediately
Schema validation	Position-based checks only	Full XSD schema validation before acceptance

This means conversion is not just about reformatting data — you may also need to clean up data that FIRE accepted but IRIS will not.

DIY Conversion: What It Takes

If you are considering building your own FIRE-to-IRIS conversion pipeline, here is what is involved:

Step 1: Parse the FIRE File

Write a parser that reads each 750-character record, identifies the record type (T/A/B/C/F), and extracts fields by byte position. You must handle:

• Variable record types with different field layouts
• Multiple payer groups (A+B+C blocks) within a single file
• Amount code interpretation (which amount positions are active, per the A record)
• Trailing spaces in every text field
• The relationship between A records and subsequent B records

// Pseudocode: Parsing a B record
string record = ReadLine();  // 750 characters
string recordType = record.Substring(0, 1);    // "B"
string paymentYear = record.Substring(1, 4);   // "2025"
string corrected = record.Substring(5, 1);     // "G" or " "
string tin = record.Substring(11, 9);          // "111223333"
string amount1 = record.Substring(40, 14);     // "00000005000000"
decimal amt = decimal.Parse(amount1) / 100m;   // 50000.00

Step 2: Map to IRIS XML Structure

Transform parsed data into the hierarchical XML structure defined by the IRIS schema. This involves:

• Grouping B records under their parent A record (payer)
• Splitting flat name fields into structured name components
• Converting amounts from integer cents to XML decimal format
• Mapping FIRE form type codes to IRIS XML form element names
• Generating required XML elements that have no FIRE equivalent (submission IDs, manifest data)

Step 3: Validate Against IRS XSD Schemas

Before submitting, validate your generated XML against the official IRS XSD schemas. The schemas define every required element, data type, and constraint. Invalid XML will be rejected immediately.

Step 4: Handle Edge Cases

Real-world FIRE files contain edge cases that simple parsers miss:

• Multi-payer files with different form types (1099-NEC and 1099-MISC in one file)
• Corrected returns (the "G" indicator) requiring specific XML correction structures
• Foreign payees with non-standard address formats
• State filing data when CF/SF is active
• Files with more than 250 returns per payer (IRIS batch size considerations)

Step 5: Test Thoroughly

Use the IRIS testing sandbox to validate your XML before filing production returns. Test with multiple form types, correction scenarios, and edge cases. The IRS testing environment may have different availability windows than production.

Estimated effort for a production-quality converter: 4-12 weeks of development time for a team familiar with both FIRE and XML, depending on the number of form types supported and edge cases handled.

The BoomTax Approach: Upload FIRE Files, Done

BoomTax eliminates this entire conversion project. Instead of building and maintaining a FIRE-to-IRIS converter, you upload your existing FIRE-format files to BoomTax. We handle the rest:

• Automatic parsing: BoomTax reads all Publication 1220 record types and extracts every field
• Intelligent name parsing: Our parser handles individual names, business names, trusts, estates, and ambiguous name formats
• Amount conversion: Zero-padded cent values are converted to proper decimal format automatically
• Schema-compliant XML: Generated XML passes IRS XSD validation every time
• Multi-form support: 1099-NEC, 1099-MISC, 1099-INT, 1099-DIV, 1099-R, 1099-K, 1099-B, 1099-S, 1099-C, 1099-SA, 5498-SA, W-2G, and more
• Correction handling: FIRE correction indicators are mapped to IRIS correction XML structures automatically
• Error reporting: Clear, record-level error messages instead of cryptic FIRE acknowledgment codes
• IRIS submission: BoomTax transmits through IRIS and tracks acceptance status

The FIRE system shuts down December 31, 2026. You can spend months building a converter, or you can upload your next FIRE file to BoomTax and be done today.

For organizations that want to build native IRIS XML generation into their systems instead, see our IRIS XML format guide and IRIS API integration guide.

Frequently Asked Questions