1095-C Rejected vs Accepted with Errors: Plan the Next Step

Capture the transmission status, submission-level details, actual message text, receipt or UTID, and the exact sent-file reference. A transmission may contain more than one submission, so its headline outcome alone may not describe every employee record equally.

Use the original record crosswalk to identify the affected population. Keep a separate internal case state such as “source review assigned” without overwriting the agency status that caused the case.

Record whether the preceding attempt was an original, correction, or replacement. The same displayed rejection can lead to different technical handling depending on that history. Do not discard it when importing the acknowledgment into a work queue.

These distinctions follow Publication 5165, sections 6 and 7. “Accepted with Errors” is not equivalent to rejection, and “Partially Accepted” should not be reduced to either result for the entire packet.

Fictional North Meridian Company transmits one original employer submission containing 500 reviewed employee records. The actual acknowledgment confirms that the submission is rejected because of a structural issue. The operator maps the rejected scope to all 500 records in that submission.

The technical owner repairs the cause, and the transmitter selects the applicable rejected-original procedure using the prior references. The replacement scope follows the documented rejected submission or transmission rules, rather than containing only the first employee mentioned in an error display.

The fictional case illustrates scope: one structural error can prevent a larger submission from being accepted. Local repair and preflight happen before the authorized next attempt, and the operator retrieves its actual outcome afterward.

In a separate fictional scenario, North Meridian's 500-record original submission is Accepted with Errors. The acknowledgment maps the reported issues to 12 distinct employee records. The other 488 have no issue identified in that feedback: 500 - 12 = 488.

The operator opens 12 review cases while preserving the accepted outcome for the original submission. The preparer investigates the facts and identifies the appropriate follow-up for each affected record. The team does not resend all 500 as new originals merely because the dashboard contains errors.

The absence of a reported issue for the 488 is not a guarantee that every underlying fact is substantively correct. It describes the feedback received. The twelve-case queue also remains subject to any indication that error detail was truncated or incomplete.

Processing means a later outcome is still needed. Not Found requires checking the lookup environment and references. Neither result establishes that a new original filing is safe. Use the supported retrieval process before changing the submission history.

If a correction transmission is rejected, Publication 5165 keeps its retry on the correction path rather than converting it into a replacement original. Preserve the original association and full history for the transmitter's review.

For a partially accepted packet, create separate action groups for accepted-with-error records and rejected submissions. Their follow-up populations can overlap conceptually in a project dashboard, but their technical histories must stay distinct.

For every proposed action, record the current agency state, underlying original scope, affected records, source decision, selected procedure, and original references. Have the release reviewer confirm the intended population and that accepted records are not accidentally included as new originals.

Keep complete revised records where correction rules require them and preserve the generated map for the next attempt. The 2025 form instructions supply substantive correction context, while AIR publications govern electronic association and routing.

The downloadable status worksheet helps the team compare like cases. Close an action only after its actual disposition and any required later outcome are recorded. A cleared software warning alone does not establish that the agency follow-up is finished.

If one record produces several messages, retain every message beneath the same review case. Counting messages as employees inflates the proposed follow-up population. Before release, compare distinct affected record references with the actual generated records and explain any difference, such as several messages resolved by one complete correction.