The practical answer
Give every intended batch a stable internal identity, record every transmission attempt against it, and resolve uncertain AIR outcomes before releasing the same original returns again. A new filename or upload attempt does not make the underlying employee returns new.
Duplicate filing usually begins with an operational ambiguity: two operators have the same export, a timeout looks like failure, or a regenerated file loses its connection to the first attempt. This guide helps transmission teams maintain that connection. The controls below are proposed operating practices, with AIR behavior checked against Publication 5165, revised December 2025.
Identify the intended returns before identifying the file
Create an internal batch key before release. Associate it with the employer, tax year, operation, approved source version and exact employee-return population. Give each actual send a separate attempt number. This lets operators distinguish one original batch attempted twice from two legitimately different batches.
Keep a restricted crosswalk of stable internal employee identifiers and the generated return records. Names alone are weak matching keys; employee numbers also need an employer context when different entities reuse them. Track corrections as later versions associated with existing returns, rather than labelling every changed record a new original.
Your batch key is an internal control, not an IRS identifier. Store the actual transmission identifiers and resulting receipt separately. Publication 5165 describes the AIR receipt, submission and record identifiers used to locate returns and their processing results.
Use release states that distinguish uncertainty from rejection
Configure a shared ledger, whether supplied by software or maintained through a controlled process. The labels below are internal operating states. Preserve the exact AIR status in a separate field so an internal label cannot overwrite agency evidence.
| Internal state | What it means | Release control |
|---|---|---|
| Ready | Approved version has no unresolved previous send. | One assigned operator may reserve it. |
| Reserved | An operator owns the pending release. | Other operators cannot independently send it. |
| Outcome pending | A send was attempted; final evidence is incomplete. | Retrieve status before deciding on another attempt. |
| Outcome reviewed | Receipt, acknowledgment and affected scope are recorded. | Close the original or create the appropriate linked follow-up. |
Record who can clear a reservation and what evidence is needed. A colleague taking over an absent operator's work should inherit the ledger and pending outcome, not begin a fresh upload because the first operator is unavailable.
Resolve a timeout before deciding to send again
A browser timeout or missing confirmation does not establish that AIR received nothing. Preserve the attempted file, timestamp, environment and available identifiers. Check the transmitter's history and retrieve the corresponding acknowledgment. If a receipt was lost, use the documented retrieval or support path with the available transmission identity. AIR's receipt and acknowledgment processes are described in Publication 5165, section 6.
Do not convert Processing or Not Found into a local conclusion of Rejected. First check that the lookup uses the intended environment and identifier and that processing time has been allowed. Document the investigation and escalate an unresolved outcome through the transmitter's support process. A deadline approaching changes the urgency of that investigation, not the evidence of what already happened.
Keep the release hold visible to every operator, including a second provider if work is being transferred. An email saying someone will investigate is insufficient when another queue still marks the batch ready to send.
Check file identity and business identity separately
A checksum helps prove which bytes were approved and sent. It does not prove that a newly generated file contains new business records. Sorting the same employees differently, changing formatting or adding a record can change a file while retaining most of the original population.
Publication 5165, section 5.1.4 describes AIR duplicate XML detection using file size and a SHA-256 value in relation to files from the same TCC. Treat that as an agency file check, not a substitute for your own return history. Do not rename or rearrange a file to work around a duplicate response.
Before releasing a regenerated original, compare its employer-year employee population with already accepted originals and unresolved attempts. Investigate overlaps instead of deleting them automatically: a legitimate correction needs an explicit correction operation and prior-record association. The status routing guide explains why accepted and rejected outcomes require different follow-up.
Worked example: two operators and one uncertain response
Fictional example: Birch Crossing has approved 320 original employee returns in batch BC-2025-04, version 2. Morgan reserves the batch and attempts transmission. The browser times out before Morgan sees a receipt. Taylor starts the afternoon shift with a copy of the same export.
The shared ledger shows Outcome pending, so Taylor does not release the file. Morgan retrieves the original attempt's receipt and acknowledgment through the transmitter. The acknowledgment shows Accepted. They attach it to attempt 1 and close the original batch. The population is 320 intended returns with one accepted original submission, not 640 returns created by treating a second attempt as new work.
If the actual acknowledgment had instead shown Rejected, they would preserve attempt 1 and follow the documented replacement route for that rejected scope. If it showed Accepted with Errors, they would investigate the affected records and prepare required corrections. Neither hypothetical outcome is a reason to erase the original ledger entry.
Reconcile pending work at each operational handoff
End a shift by reviewing reservations without sends, sends without receipts, receipts without reviewed acknowledgments, and planned follow-up lacking prior references. Assign the next retrieval action and owner to each unresolved item. Separately list accepted original populations so they cannot silently reappear in a general ready queue.
For a replacement, record the rejected scope and required prior association; for a correction, record the accepted return being corrected. Preserve the approved new version beside the earlier version. Ask a second operator to compare the intended operation, population and history immediately before release.
When a duplicate is suspected after acceptance, freeze further related releases and collect both acknowledgment chains. Do not invent a deletion or cancellation procedure. Have the transmitter or responsible reporting reviewer establish the applicable resolution using the actual records and current AIR guidance.
One batch identity across an uncertain send
Read the workflow as text
- Reserve approved batch. One operator owns the exact employer-year population and version.
- Record the attempt. Save file evidence and identifiers even when the response is uncertain.
- Retrieve actual outcome. Attach AIR evidence before deciding whether any follow-up is needed.
- Close or link follow-up. Keep accepted originals out of new-original queues; associate appropriate next operations.
Put this guide to work
1095-C duplicate transmission prevention ledger
Save the editable text worksheet and use it with your own records. Keep completed copies in your secure working files.
Download the worksheet TXTCommon questions
Does changing the filename prevent duplicate 1095-C reporting?
No. A filename is not a reliable identity for the underlying employee returns. Compare the employer, tax year, intended operation and record population against prior attempts and accepted originals. A changed file still needs a documented reason for release.
Can we retry immediately after a timeout?
Treat the outcome as uncertain first. Preserve the attempted file and available identifiers, then use the transmitter's retrieval and support procedures to establish what happened. A second operator should see the unresolved attempt before receiving permission to release that population.
Should the ledger have one row per batch or per attempt?
Use a stable batch record with a linked row for each send. This preserves the intended population while allowing separate timestamps, file versions, receipts and outcomes. Flattening every attempt into a new batch hides retry relationships.
Does Accepted with Errors mean we should send the original batch again?
No. Investigate the affected accepted records and follow the applicable correction procedure when a correction is needed. Replacements apply to rejected scope under the rules in Publication 5165; the original operation and actual acknowledgment both matter.
What should we export when changing transmission providers?
Export the original population crosswalk, exact sent versions, receipts, acknowledgments and all unresolved follow-up. Make responsibility for pending outcomes explicit. A new provider should not treat the absence of imported history as evidence that the returns were never submitted.
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.
- IRS Publication 5165, revised December 2025
Processing year 2026 AIR identifiers, receipt and acknowledgment handling, duplicate XML detection, corrections and replacements.
