The practical answer

Review a converted value in three stages: the exact characters in the FIRE record, the meaning assigned by its payer/form context, and the resulting XML element. A value is only mapped correctly when all three agree.

This is a practical tracing exercise for the person reviewing a conversion, not a complete implementation specification. It uses a fictional Form 1099-NEC record and the tax year 2025 FIRE layout in Publication 1220, revised May 2026. The current converter release and receiving schema still need their own compatibility check.

Start with the payer group, not the amount alone

An amount field is not self-describing. Locate the issuer A record that governs the payee B record, identify the form type, and read the declared amount codes. For Form 1099-NEC, Publication 1220 associates amount code 1 with nonemployee compensation and code 4 with federal withholding. For another form, the meaning of a code can differ. Publication 1220, Part C, issuer and payee layouts.

In your trace sheet, label the source file, payer group, B-record sequence, payment year, and account reference. Use a synthetic or masked recipient label in material shared outside the filing work area. Do not start by searching the XML for a common name: that name may occur under several payers.

Keep the form label beside every amount comparison. The number $1,250.50 is insufficient by itself; the review needs to establish which payer reported it, for which recipient, in which tax year, and in which box.

Read a position range without shifting it

The example below uses only two slices of a fictional B record. It deliberately omits the other positions, so it is not a complete record suitable for conversion or filing. Position numbers are one-based and inclusive.

Fictional source context: 1099-NEC, tax year 2025
B record positions 55-66:  000000125050
B record positions 91-102: 000000015000

These twelve-character fields encode $1,250.50 and $150.00 respectively. In this FIRE layout, the two rightmost amount positions represent cents. Read the characters first, then normalize the amount once. A second division by 100 would turn $1,250.50 into $12.505, which is a conversion defect. Publication 1220, payment amount fields.

If the captured range is the wrong length or contains an unexpected character, resolve that before comparing XML. Many apparent amount problems actually begin with an off-by-one position or a text editor that changed spacing.

Separate raw text, numeric value, and output

Use a three-column trace so the reviewer can see whether the error arose during parsing or writing. The XML element names below match the site's inspected converter mapping for NEC, but the fragments omit their enclosing groups and namespace. They illustrate a field trace and are not a standalone IRIS document.

Fictional NEC source-to-output trace
Source sliceParsed meaningIllustrative XML fragment
55-66: 000000125050125,050 cents of compensation<NonemployeeCompensationAmt>1250.50</NonemployeeCompensationAmt>
91-102: 00000001500015,000 cents of withholding<FederalIncomeTaxWithheldAmt>150.00</FederalIncomeTaxWithheldAmt>

Store exact cents or another exact decimal representation in the review calculation. Preserve identifiers and account references as text. The rule used for an amount must not accidentally strip leading zeros from a taxpayer identifier or account number.

Reconcile each field to the appropriate source amount, not to a combined sum. Compensation and withholding are separate reported values. Subtracting the second from the first does not produce a substitute value for either box.

Review identity fields and context alongside money

Inspect the issuer name and identifier at the group level, then the recipient name, identifier type, identifier, and address at the return level. A technically valid amount under the wrong issuer is still the wrong result.

Name handling deserves a separate check. A fixed-width source may have business-name lines without reliable first-name and last-name boundaries. Do not assume that splitting on the first space creates an accurate person name. Inspect warnings, compare the source's intended identity, and determine what the receiving workflow supports.

Also review empty and zero values. An absent optional output element, an explicit zero, and a missing required source value are different cases. Record which transformation was intentional. If a field cannot be represented by the selected converter, obtain a supported path instead of accepting silent loss.

Worked example: a valid number in the wrong element

Fictional example. A reviewer expects compensation of $1,250.50 and withholding of $150.00. The preview contains both amounts, but they are reversed. The total of the two fields remains $1,400.50 before and after conversion, so an all-box total would miss the defect.

The reviewer checks the raw slices and confirms that they were parsed correctly. The next trace step shows that the output writer assigned code 1 to the withholding element. The correction belongs in the mapping, not in the accounting data. After the software owner fixes it, the reviewer checks both fields and similar NEC records in the same batch.

Run a small boundary set as well: a cents-bearing amount, a large amount within the supported range, and a zero or omitted optional amount where appropriate. Use deliberately synthetic identities for test material. This example describes a review method; it does not assert that the current converter contains that defect.

Keep the mapping sheet with the release

Save the source specification edition, converter release, target schema version, and the exact field trace. State whether you inspected a fragment, a complete converted file, or a submitted return. This lets another reviewer repeat the comparison after an export-system or schema change.

For A2A, element placement, order, types, and required groups depend on the applicable schema. The IRS release table distinguishes testing and production dates. A familiar element name alone does not prove that the complete document is valid for the receiving environment.

Use the downloadable worksheet to capture one representative ordinary record and each unusual case in the source. Finish by reconciling the full batch by payer and form. Spot checks find mapping patterns; they do not replace batch totals or the later review of the IRS filing outcome.

Trace the fictional compensation amount

Trace the fictional compensation amount: Source slice; Form context; Normalized amount; Output comparison
This partial example uses the tax year 2025 FIRE layout. It is not a complete FIRE record, XML document, or IRS acceptance test.
Read the workflow as text
  1. Source slice. B positions 55-66 contain 000000125050.
  2. Form context. The governing payer group identifies NEC amount code 1.
  3. Normalized amount. 125,050 cents becomes 1250.50 exactly once.
  4. Output comparison. Check NonemployeeCompensationAmt and the correct issuer/recipient.

Put this guide to work

FIRE-to-IRIS field mapping trace sheet

Save the editable text worksheet and use it with your own records. Keep completed copies in your secure working files.

Download the worksheet TXT

Common questions

Does amount code 1 always mean NEC box 1?

No. Interpret amount codes within the source's form type and specification. The fictional trace here is specifically for Form 1099-NEC.

Can I use the displayed XML as a submission?

No. It is an illustrative fragment. A submission needs the complete applicable XML structure and the transmission workflow's requirements.

Why keep the original characters after parsing?

They let you distinguish a source error from a parser or mapping error. Without the raw slice, an incorrect normalized value is harder to diagnose.

Do matching monetary totals prove that recipients are correct?

No. Amounts could have been assigned to the wrong recipient or payer. Check identities and grouping separately from the amounts.

Should I repair an XML value by hand?

Identify the cause first. Repairing only the output leaves the next conversion vulnerable to the same error and can invalidate totals or related fields. Prefer a traceable source or mapping fix followed by regeneration.

Official sources and scope

Sources checked September 5, 2026. Use the edition for the tax year and filing method you are working with; later instructions may change thresholds, fields, or procedures.

  1. IRS Publication 1220, tax year 2025, Rev. May 2026

    NEC amount-code meanings, one-based payment-field positions, and implied cents.

  2. IRS: IRIS schemas and business rules

    Verify the target XML package and environment-specific effective dates.

  3. IRS Publication 5718, processing year 2026

    Complete A2A document and transmission requirements are separate from a field fragment.