FIRE to IRIS transition: Reconcile Each Client Before Cutover

The FIRE to IRIS transition requires accounting firms to prove that each client's filing population survives the move. Before approving cutover, reconcile payment records to prepared return amounts, confirm who will transmit, and preserve correction evidence. A successful software import is one checkpoint; it doesn't establish that the right payments reached the right returns.
Why the FIRE transition matters now
The IRS transition announcement, published 2026-08-24, sets three separate checkpoints: November 1 for final FIRE test submissions, November 9 for changes to existing IR TCC applications, and November 19, 2026, at 3 p.m. ET for final FIRE production submissions. Tax year 2026 information returns move to IRIS for the 2027 filing season.
Don't use the end of December as the working deadline for a final FIRE submission. Put the November production cutoff in the firm's transition calendar, including its stated time zone. Give every affected client an earlier internal readiness date so a missing authorization or unresolved data exception doesn't consume the remaining window.
NATP's practitioner guidance, published 2026-09-01, explains that FIRE and IRIS TCCs are separate and distinguishes software use from engaging another party to transmit. It also highlights prior-year filings and corrections. Those distinctions belong in the engagement handover, not just the technology team's notes.
For a firm closing many client files at once, the practical question is whether each filing workflow has enough evidence to proceed. The process below is a proposed firm control, not an IRS-prescribed reconciliation template. It connects payment evidence, return preparation and approval without pretending a financial reporting system replaces tax filing software.
Build a client register before choosing a filing route
Start with one row per legal filer, supported form family and tax year. A client group with three entities needs three identifiable filers even if one partner manages the relationship. Record the legal name, internal entity identifier, preparer, reviewer, intended transmitter and unresolved readiness issues. Keep sensitive taxpayer identifiers in the firm's approved secure systems rather than in a broadly shared project sheet.
Use specific status labels. Data prepared, reviewer approved, transmitted and filing status retrieved describe different events. A single green cell marked ready hides the distinction between a clean export and a completed filing. Each status should have a dated evidence reference and the person who recorded it.
Record the current route and proposed route separately. Ask the provider who actually transmits, whose authorization is used, and how the firm retrieves processing evidence. Don't infer those answers from a purchase receipt or a successful login. Document the provider's response and verify it against the workflow available to the firm's account.
Assign correction ownership before migration. A new provider may be able to prepare current returns while staff still need evidence from an earlier filing to resolve a later correction. Record where prior submissions, recipient copies, acknowledgments and approved amounts are retained. Identify who can access them when the original preparer is absent.
| Checkpoint | Evidence to retain | Suggested owner | Release condition |
|---|---|---|---|
| Filer identity | Approved entity and year mapping | Client manager | No unexplained entity mismatch |
| Payment population | Dated export and inclusion bridge | Preparer | Every adjustment has support |
| Prepared returns | Amount and recipient reconciliation | Reviewer | Control totals and sampled records agree |
| Transmission route | Authorization and provider confirmation | Filing lead | Responsible transmitter identified |
| Correction handover | Historical evidence and access record | Client manager | Named owner can retrieve prior records |
Apply the register to a small pilot before copying it across the client base. Choose a client with ordinary payments and a manageable exception set. Avoid selecting only the cleanest file: one duplicate vendor record or a payment reversal provides a useful test of whether the handover procedure explains differences.
Reconcile source payments to prepared return amounts
A filing reconciliation starts with a defined population. State the legal entity, tax year, extraction date, source reports, included payment methods and intended forms. An expense-account total alone isn't a complete payment population. Bills, payments, reversals and vendor changes can affect different reports in different ways.
Keep the original export unchanged. Create a separate working version for classification and reconciliation, with a stable transaction reference on each row. When staff correct a payee mapping or remove a duplicate export record, they should be able to point back to the original evidence and explain the change. Renaming a vendor should not erase the transaction trail.
The reconciliation should answer two questions: did the source population transfer completely, and did the tax preparer approve the treatment of every adjustment? The first is a data control. The second requires current form instructions, payment facts and professional judgment. Don't let a spreadsheet formula silently decide reportability.
A worked payment-population bridge
Suppose a firm's illustrative client export contains $184,000 of payments for the selected year and scope. The preparer identifies $6,000 of repeated export rows representing the same underlying transactions. That leaves $178,000 of unique source payments. The repeated rows are an extraction issue, not evidence that the client paid twice.
After reviewing the relevant facts and form instructions, the tax preparer approves $38,000 of documented exclusions from this particular filing population. The expected prepared-return amount is therefore $140,000: $184,000 minus $6,000 minus $38,000. These amounts illustrate the reconciliation method; the example does not establish a tax rule for excluding any payment category.
The destination preparation report totals $138,800. The $1,200 shortfall remains an open exception. Comparing recipient-level totals reveals that a payment mapped to an inactive vendor record did not enter the intended prepared return. Staff investigate the mapping, correct the preparation data and rerun the comparison. They don't increase a return amount merely to make the grand total agree.
After correction, the prepared-return total is $140,000. The reviewer also compares recipient counts, selected individual payments and form-box assignments. Equal totals alone are insufficient: a $1,200 omission for one recipient and a $1,200 overstatement for another would leave the grand total unchanged. The control must test identity as well as amount.
Keep unresolved items visible
Give each exception an identifier, amount, recipient reference, explanation, owner and due date. Distinguish missing source evidence from a mapping error and from an unresolved tax classification. Those problems need different people. A preparer can fix a duplicate import row, while a tax reviewer may need to resolve treatment of an unusual payment.
If the team uses a dashboard, show both the value and count of unresolved exceptions. One large item and twenty small items create different review burdens. Keep resolved exceptions in the record with their supporting explanation instead of deleting them after the dashboard turns green.
Existing vendor-spend analysis can help identify unexpected supplier movements and unusual payment patterns. Use that view to target investigation. It doesn't determine which recipients require information returns, and a management-reporting category should not substitute for the preparer's documented tax classification.
Accounting controls for approval and correction ownership
Source data: preserve the evidence boundary
The source data should include the approved extraction, entity mapping, payment references, relevant payee documentation and prior filing evidence. Record when each item was retrieved. If a client changes its vendor master after the export, document whether the preparation population was refreshed and which records changed.
Keep bank evidence, ledger records and tax preparation records distinguishable. A bank withdrawal supports a cash movement, while an expense posting may support recognition in a different period. A vendor payable is a balance at a date. These are related records, but they answer different questions and shouldn't be substituted for one another.
Calculation: make the bridge repeatable
The deterministic calculation sums the defined payment population, removes confirmed extraction duplicates, applies separately approved inclusion adjustments and compares expected amounts with prepared returns. Group by legal filer, recipient, tax year, form and box where relevant. Retain the formula version or transformation steps so another staff member can reproduce the totals.
Use a consistent sign convention. Payments can be shown as positive population amounts and supported reversals as negative adjustments, provided the policy is documented and the underlying accounting treatment remains intact. Preserve debit and credit fields when examining ledger entries. Don't strip signs simply because an absolute-value total looks easier to reconcile.
Compare flows across the same period. Year-to-date payments cannot be reconciled directly to a year-end accounts payable balance without explaining opening liabilities, bills, payments and other movements. If a liability rollforward is needed, build it separately and retain the components. Don't label a point-in-time balance as annual vendor spend.
Review: test the assumptions behind agreement
The review should cover extraction scope, duplicate removal, approved exclusions, entity assignment and recipient matching. Sample records from the source to the prepared returns and from the prepared returns back to the source. Testing both directions helps identify omissions and unsupported additions.
Set the firm's release criteria before seeing the result. For this proposed workflow, unexplained amount differences, missing filer identity or unassigned correction ownership prevent approval. A reviewer can document an explained difference, but an explanation needs evidence and a responsible person. A note saying software issue is not enough.
Use the same discipline described in audit-ready close controls: assign duties, retain evidence and make the approval observable. A repeatable review packet also helps a replacement staff member understand what changed without reconstructing the entire client file.
Decision: name the person who authorizes release
The decision owner should approve the client workflow only after the filing lead confirms the route and the reviewer clears the reconciliation. Depending on the engagement, client authorization may also be required. Record approval separately from the technical act of transmission, and retain the exact prepared version that was approved.
A filing acknowledgment is a later piece of evidence. It does not retroactively prove that the client approved the amounts or that staff used the right source population. Assign someone to retrieve processing status and investigate exceptions after submission. Otherwise, the firm can finish preparation while leaving the last operational step unattended.
Migration discrepancies should not automatically generate journal entries. If investigation finds a genuine duplicate payment recorded in the ledger, the controller evaluates the accounting correction and its supporting evidence. If the problem is a duplicate export row or tax filing classification, fix the affected preparation process without changing valid books.
Run an October pilot and document the limits
Use October to complete one end-to-end rehearsal with approved historical or test data appropriate to the selected environment. Never submit a live duplicate return merely to demonstrate that a connection works. Define the permitted test activity with the filing provider and keep test evidence separate from production records.
The pilot packet should contain the client register, original export, reconciliation bridge, exception history, prepared-output comparison, route confirmation and reviewer approval. Add a short handover note stating who retrieves acknowledgments and who handles later corrections. A new staff member should be able to follow the packet without relying on the preparer's memory.
Measure preparation time, review time and unresolved exceptions separately. A quicker import may create more review work if it changes recipient mappings or hides adjustment detail. Decide whether the workflow is ready using the evidence, rather than treating a shorter upload time as the only success measure.
Scale by client cohort after the pilot. Group clients by filing route, data source and complexity, then assign readiness dates before the relevant November checkpoints. A firm-wide schedule is useful, but retain entity-level approvals. One successful client doesn't establish readiness for a group with different forms or a different transmitter.
This reconciliation is not a determination of filing thresholds, due dates, reportable payment categories or state obligations. Consult the applicable current instructions for those decisions. The transition also doesn't justify assuming that every historical form or correction is available through every provider. Verify the specific year and form before promising a client a correction route.
Finally, separate financial reporting from information-return transmission. Consistent entity and account mapping, as discussed in shared chart of accounts mapping, makes source investigation easier. Tax preparation and filing evidence still belong in their dedicated workflow, with explicit links back to the supported accounting records.
Frequently Asked Questions
When does FIRE stop accepting information returns?
The IRS lists November 19, 2026, at 3 p.m. ET as the last time to file information returns through FIRE. Plan migration work before that cutoff.
Does a FIRE TCC carry over to IRIS?
No. FIRE and IRIS TCCs are not interchangeable. Confirm who will transmit each client's returns and whether that transmitter has the appropriate IRIS authorization.
Does an accepted filing prove the payment amounts are correct?
No. Filing status is evidence about processing. A reviewer still needs to reconcile the prepared return amounts to the approved payment population and investigate differences.
Should migration differences change the general ledger?
Only when investigation identifies a genuine accounting error. A filing classification difference or duplicate export row does not, by itself, justify a journal entry.
For the financial reporting side of client review, explore FinBoard to support consistent reporting while your dedicated tax workflow manages preparation, transmission and filing evidence.


