The transition to IRIS is usually discussed as a current-year project.
Healthcare payers also need a plan for the past.
Providers may identify errors months after receiving a form.
An audit may uncover an omitted payment.
A CP2100 notice may require research.
A system conversion may reveal an older record that was reported under the wrong taxpayer.
A prior filing vendor may no longer be available.
A historical correction may need to be made after FIRE has already retired.
Beginning after January 1, 2027, IRIS will be the only IRS information-return electronic filing system for current-year returns, prior-year returns, and corrections previously handled through FIRE.
That means the FIRE-to-IRIS transition must include the organization’s historical filing capability.
A payer that can file the current year but cannot reconstruct or correct prior years is only partially ready.
IRIS Supports Multiple Tax Years
The IRS currently states that IRIS can be used to electronically file supported information returns for tax year 2022 and later.
The system also supports corrections and certain automatic-extension requests.
This does not mean every tax year should be handled with the current year’s file structure.
Historical filings remain tied to the requirements that applied to the tax year being reported.
The organization must preserve enough information to determine:
- Which tax year is involved
- Which form was filed
- Which schema and business rules apply
- Which provider data was originally used
- Which amount was reported
- Which identifiers were returned
- Whether the original record was accepted
- Which correction procedure is required
The older the filing, the more likely this information is scattered across systems, vendors, and employee archives.
Use the Correct Tax-Year Schema and Business Rules
Publication 5718 instructs A2A filers to use the schemas and business rules in effect for the tax year being filed.
Current-year schemas should not be used automatically for prior-year returns.
Different tax years also should not be mixed within the same transmission or submission.
This matters because fields, validation rules, required values, version numbers, and supported structures can change.
A file that is technically valid for tax year 2026 may not be valid for tax year 2023.
Similarly, software that supports current-year originals may not support every prior-year correction.
Before engaging a vendor or internal development team, confirm:
- Which prior tax years are supported
- Which forms are supported for each year
- Whether corrections are supported
- Which schema versions are used
- How historical business rules are maintained
- Whether prior-year testing is available
- How the tax year is separated operationally
- How acknowledgments are stored
“IRIS compatible” does not automatically mean “historically complete.”
Do Not Mix Tax Years
The IRS requirement not to combine tax years in the same transmission or submission should also shape internal operations.
Separate:
- Source extracts
- Review workbooks
- Approval files
- Transmission packages
- Receipt IDs
- Acknowledgments
- Correction records
- Recipient copies
- Retention schedules
A folder containing “all corrected providers” across several tax years may be convenient during research.
It is dangerous during transmission.
Each historical filing should remain clearly labeled by issuer, tax year, form, provider, and filing action.
The tax year should be visible in filenames, dashboards, approval records, and vendor requests.
Understand Schema Version Changes
Publication 5718 distinguishes between minor and major schema changes.
When a minor version changes, IRIS may continue accepting returns composed using an earlier version, although validation may occur against the active version.
When a major version changes, older versions may no longer validate and can be rejected.
This creates two operational needs.
First, software teams and vendors must monitor active schema versions.
Second, the payer must know which version was used for each prior-year submission.
The organization should not store only the final data.
It should also preserve enough metadata to identify the filing structure and software context.
Preserve Historical Provider Identity
A prior-year correction should reflect the correct taxpayer information for the year and record being corrected.
That can become complicated when a provider has:
- Changed legal names
- Changed TINs
- Merged with another entity
- Closed a practice
- Moved locations
- Changed billing groups
- Been acquired
- Submitted a new W-9
- Been represented differently across payer systems
The provider’s current information is not automatically the correct information for a historical correction.
The payer should preserve dated W-9s, provider correspondence, payment history, original tax records, and the reason for any identity change.
Otherwise, the current provider master may overwrite the evidence needed to explain the earlier filing.
Retain the Original IRIS or FIRE Evidence
To correct a prior filing, the organization may need:
- Original filing data
- Original acceptance status
- Receipt ID
- Submission ID
- Record ID
- Provider copy
- Payment reconciliation
- TIN and legal-name source
- Correction history
- Vendor transmission evidence
For filings originally submitted through FIRE, historical records may use different identifiers and formats than IRIS.
The migration plan should therefore preserve FIRE-era records even after FIRE becomes read-only.
Do not delete the old filing archive simply because the new filing channel is active.
The filing system changed.
The historical obligation did not disappear.
Review Vendor Support for Prior Years
A third-party transmitter may support current-year IRIS filings but place limits on historical returns.
Ask:
- Which prior tax years are supported?
- Which forms can be corrected?
- Can the vendor ingest records originally filed through FIRE?
- What original evidence is required?
- Can the vendor reconstruct the prior-year format?
- How are historical Receipt IDs or references handled?
- Will the payer receive complete electronic records?
- How are older recipient copies generated?
- What happens if the original vendor filed the return?
- Is prior-year work subject to different pricing or timing?
These questions should be answered before a provider dispute or IRS notice creates urgency.
Build a Historical Filing Inventory
Create an inventory of prior-year filing assets.
For each issuer and tax year, identify:
- Original filing platform
- Filing vendor
- Forms submitted
- Record count
- Storage location
- Available source files
- Available acknowledgments
- Available Receipt IDs
- Available recipient copies
- Known unresolved errors
- CP2100 history
- Correction history
- Retention expiration
- Current owner
The inventory will reveal gaps.
Some years may have complete packages.
Others may have only PDFs.
Others may be trapped in a former vendor portal.
It is better to discover those gaps during transition planning than during a time-sensitive correction.
Run a Prior-Year Correction Exercise
As part of IRIS readiness, select one historical record and walk it through the correction process.
Confirm that the team can:
- Locate the original filing
- Confirm the provider identity
- Reconcile the original amount
- Identify the correct tax-year rules
- Prepare the corrected record
- Obtain approval
- Transmit through the appropriate process
- Retrieve the acknowledgment
- Furnish the corrected provider copy
- Update the retention package
This exercise tests the archive, software, vendor, and people.
It may uncover more risk than another perfect current-year test file.
Avoid Rewriting History Without Documentation
Historical corrections should not be made by silently replacing the old record in the provider database.
The organization should preserve:
- Original value
- Corrected value
- Date of change
- Reason for change
- Supporting evidence
- Approver
- Filing reference
- Source-system update
- Recipient communication
The goal is not simply to make the database look correct today.
The goal is to explain what was originally reported, why it changed, and how the correction was completed.
Final Thoughts
IRIS prior year returns require more than access to a modern filing platform.
They require historical data, tax-year-specific schemas, preserved identifiers, correction capability, provider documentation, and clear separation among tax years.
Healthcare payers should include prior-year filing in the FIRE retirement plan now.
A transition is not complete until the organization can manage both the next filing and the correction that may arrive three years later.
BASELoad Can Help Resolve Historical Provider-Data Problems
BASELoad’s W-9 Corrections process supports healthcare payers with TIN and legal-name research, provider outreach, CP2100 review, B-Notice support, address correction, and processing of files from multiple claim or billing systems.
That experience can help organizations investigate the provider-data issues behind both current and prior-year corrections.
Contact BASELoad to strengthen the historical provider records and correction processes your organization will need for IRIS prior year returns.
