Create a 1094-B Batch Control Log

Use a stable internal batch ID for the intended filing scope. Use a version for a changed population or generated artifact, and an attempt reference for each actual transmission event. These are suggested organizational labels, separate from the IRS receipt and submission identifiers described in Publication 5165.

Record the filer, tax year, operation and intended environment at the batch level, then preserve the exact included statement set for each release version. An attempted upload should point to that version instead of a folder whose contents may later change.

Retain prior entries. If version 4 supersedes version 3 before filing, record the reason and the superseded state. Do not erase version 3 in a way that makes an earlier review or attempted transmission impossible to interpret.

A file fingerprint is a reproducibility control, not an electronic signature or evidence of IRS acceptance. Store sensitive payloads in the protected evidence location and place references in the ledger.

Publication 5165's duplicate XML discussion describes IRS checks using file size and a SHA-256 checksum with the same TCC, and notes different treatment for rejected files. That technical check should not be your sole business duplicate control.

Regenerating or reordering a file can change its bytes without changing the underlying intended returns. Compare the filer, year, operation and included statement references against the existing release history. A different hash is not a reason to assume that the business population is new.

Conversely, an identical filename does not prove identical content. Save file identity information at the time of review and release. If two operators use different local copies, the ledger should make the version difference visible before either transmits.

Assign one active release owner for each intended scope, with a clear handoff when that owner changes. Other preparers can continue reviewing source work without independently transmitting the same approved packet. Record an actual reservation or release decision in the team's chosen system rather than relying on an informal expectation.

When an attempt produces an uncertain outcome, leave the version in an investigation state. Consult the submission tracker and retrieve the acknowledgment before deciding whether another attempt is needed.

For a confirmed rejection, use the triage process to establish the repair operation and scope. A new version number alone does not turn previously accepted returns into an appropriate original filing population.

Fictional example: Lake Alder prepares batch LA-31 version 2 containing 40 original 2025 returns. An operator transmits it and saves the actual receipt, but the acknowledgment has not yet been reviewed.

A second operator sorts the same 40 statements differently and generates version 3. The file fingerprint changes because the serialized order changes. The return-set comparison nevertheless shows 40 shared statement references and zero new returns.

The ledger flags the overlap with version 2's pending outcome. The second operator pauses release and retrieves the earlier acknowledgment. If that result is Accepted, the team marks version 3 as an unnecessary duplicate draft and does not send it as another original packet.

If the result instead identifies a rejection, the team follows the applicable repair procedure using that evidence. The same inventory comparison supports investigation, but it does not predetermine the filing operation before the outcome is known.

The example's internal version labels and fingerprints are illustrative; it supplies no real IRS receipt or invented valid tax identifier.

Compare expected releases against the ledger and identify versions that are approved but unattempted, attempted but awaiting evidence, or assigned for repair. This reveals lost work as well as duplicates. Count unresolved scopes explicitly instead of burying them among completed rows.

Reconcile accepted outcomes to the intended population without double-counting repeated attempts. Two attempts concerning the same 40 returns do not represent 80 distinct returns. Preserve replacement or correction lineage when interpreting the final inventory.

Apply the actual record-retention and access controls for your organization and filing obligation. Keep enough connected evidence to reconstruct what was approved, sent and returned. The electronic preflight checklist supplies the release inputs; the ledger preserves how those inputs moved through the process.