FIRE File Preflight Checklist Before Conversion

Obtain the export directly from the system that created it, together with its export report. Keep an unchanged copy in the filing work area and use a separate working copy. Record the filename, file size, creation or export time, exporting software, and person who generated it. A file hash can help your technical team identify whether two copies contain the same bytes.

Ask whether the export is a complete batch, a filtered group, or a rerun following a correction. Similar filenames are weak evidence. A file called 1099-final.txt may predate a later change to a vendor record.

Open the working copy in an editor that preserves fixed-width text. Avoid saving it from a spreadsheet during inspection: automatic number handling, altered delimiters, and missing spaces can change the source. This preservation step is an operational recommendation, not an IRS-required naming convention.

Record the payment year in the data, each form type, the expected payer count, and whether any returns are corrections. Compare that list with the export report and the converter's current supported inputs. The year you are working in is not necessarily the year of the payments.

The IRS form-availability list distinguishes processing year and tax year. Use the same distinction in your notes: for example, tax year 2025 data being processed during 2026. Do not infer software compatibility just because IRIS supports the form.

Separate unfamiliar cases before the full run. A foreign address, corrected return, special form indicator, or state-specific field may require handling beyond a particular converter's scope. Mark each case as supported, needs confirmation, or routed to another workflow. Do not erase an indicator to make a record pass.

Publication 1220 defines fixed-position records, including issuer A records, payee B records, and related control records. Its payee layout uses 750 positions. Inspect boundaries according to that specification, including its treatment of line-ending positions. A text editor's visible line count may not equal the number of logical records in every export. Publication 1220, Part C.

Have your parser or technical reviewer report logical record lengths and record types. Look for a truncated last record, a blank line introduced by transfer, or a header added by an export tool. If all fields appear displaced by the same amount, investigate encoding and boundary handling before changing individual values.

Check several locations: the beginning, the first payer transition, a middle section, and the end. Review non-ASCII characters and any byte-order marker with the software owner. Re-exporting a damaged file is often more reliable than manually reconstructing missing positions.

Create a separate row for every payer, form, and applicable filing category. Count recipient return records, not every record in the file. Compare that count with the source control information and the export report.

Sum each populated amount field separately. A combined total across all boxes is too coarse: compensation moved to withholding could leave the combined total unchanged. Keep state information separate from federal box totals and distinguish a recipient's address state from reporting instructions.

When the same person receives different forms or forms from different payers, several records can be legitimate. Do not deduplicate by recipient name or identifier alone. Instead, investigate duplicates against the source application's return records and filing intent.

Record every difference even if it is small. A one-cent discrepancy can identify a rounding problem; a one-record discrepancy can identify an omitted recipient. Leave unresolved groups out of the transmission handoff.

Fictional example. Harbor Example Company expects 24 Form 1099-NEC returns and 6 Form 1099-MISC returns for tax year 2025. Its accounting report contains $96,400 in NEC box 1 and $18,000 in MISC rents. The delivered file parses cleanly, but its scope check reveals a missing form group.

The reviewer finds that the export screen was filtered to NEC. Converting that file again cannot recover the missing MISC returns. The team obtains the intended source export and repeats preflight. This is why a structurally valid file still needs comparison with the business's expected batch.

Finish with three outcomes: ready for conversion, re-export requested, or exception needing a supported alternative. Attach the scope sheet, reconciliation results, and references to any unusual records. Use masked identifiers in general project notes, with the actual filing data kept in its controlled work area.

After conversion, perform a second reconciliation against this frozen source. Preflight establishes the baseline; it does not verify the output. Record the converter release and the validation package used so that a later rerun can be compared meaningfully.

For A2A, the software team must select the release applicable to its environment from the IRS schema and business-rule table. Keep local conversion, software testing, and production submission as separate tasks. A preflight checklist is an editorial review tool and does not establish IRS acceptance.