The difference between claim rejections and denials

Big takeaway: A rejection stops a claim before it’s processed – or adjudicated – by the payer. Denials happen after adjudication. Knowing which one you’re dealing with determines what you can do next.

Rejections and denials are two of the most common – and misunderstood – claim outcomes.

Both mean something went wrong with the claim. But they happen at different points in the claim lifecycle, mean different things, and require different fixes.

What is a claim?

A claim is a bill that a healthcare provider, like a doctor or dentist, sends to an insurer, called the payer. It lists the services provided to a patient and requests payment based on the patient’s plan benefits.

You can send and track claims using Stedi’s API, SFTP, or the Stedi portal.

How a claim moves through processing

To track a claim, you have to follow several transactions through different stages.

The following diagram gives you a high-level map. The sections below explain each stage and the various states a claim can end up in. For a deeper dive on each transaction type, like 837 claim submission, see How claims transactions fit together.

Adjudication

Adjudication is the process where the payer reviews the claim and decides which services to cover, how much to pay, and whether to deny (not pay) any part of it.

While most claims are adjudicated automatically, some still require someone to review the claim, which can delay payment.

Validation

Because adjudication can take time, payers run validation checks on claims before accepting them for processing. These checks confirm that the claim is properly formatted, includes all required data, and doesn’t contain obvious errors.

These checks are part of a broader set of automated rules, called claim edits, that payers use to review claims before or during adjudication.

Because payers can be slow to respond, Stedi also runs edits on claims before sending them to payers. We maintain a growing library of payer-specific edits to help you troubleshoot problems early.

If you submit claims through our API, we run edits synchronously, so you’ll see any rejections right away. That lets you fix issues quickly and keep claims moving. If you submit claims using SFTP, you’ll receive rejections from Stedi asynchronously in 277CA claim acknowledgments.

The goal of validation is to produce a claim that’s complete, accurate, and ready to be adjudicated. This ensures the provider is paid more quickly and creates less rework for staff.

Rejections

A rejection happens when a claim fails a check during validation, either with Stedi or with the payer.

Claims can be rejected for many reasons, including missing or invalid data, formatting issues, payer-specific requirements, or duplicate claim submissions. In most cases, you can fix the error and resubmit the claim.

You typically get rejections in 277CA claim acknowledgments. Both Stedi and the payer send claim acknowledgments. They confirm that your claim was received, and whether it passed validation. If a claim is rejected, the acknowledgment includes details about what went wrong and how to fix it.

Denials

A denial means the payer reviewed the claim but decided not to pay, or to pay only part of it.

If a claim is denied, it’ll be noted in the claim’s 835 Electronic Remittance Advice (ERA). ERAs, also called remits, are payment summaries and can cover multiple claims. The ERA lists which claims were paid, how much was paid, which were denied, and why.

When a claim is marked as paid or denied, it’s considered finalized. That means the payer has completed processing the claim and won’t send further updates.

Resubmission and appeals

Just because a claim is finalized as denied doesn’t mean you don’t have options.

Rules for handling denied claims are often covered in the provider’s contract with the payer. Some payers may let the provider correct and resubmit the claim. Other payers may require a more formal appeals process that’s specific to the payer.

If the payer supports it, you can use Stedi to resubmit previously denied claims. For guidance, see our related claim resubmission docs:

• Resubmit professional claims

• Resubmit dental claims

• Resubmit institutional claims

Timely filing limits

Timely filing limits are deadlines that determine how long a provider has to submit a claim that’s accepted by the payer for adjudication. The timeline is typically set in the provider’s contract with the payer.

Rejected claims haven’t been accepted for processing by the payer, so they’re still subject to timely filing limits. If a claim isn’t accepted within the timely filing window, the payer can legally refuse payment. This isn’t true for denied claims.

Once a claim has been accepted and adjudicated, even if it’s denied, the timely filing limit no longer applies. Instead, payers may set separate deadlines for corrected claims or appeals, which are handled under different rules.

Rejections after adjudication

Technically, rejections only apply to claims that never made it into the payer’s adjudication system. Once a claim is accepted for adjudication, it can no longer be rejected, only denied.

However, in practice, some payers send denials that function like rejections. For example, if a validation error slips through and the claim enters adjudication anyway, the payer may deny it.

Payers don’t always treat the same error the same way. One payer might reject a duplicate claim. Another might deny it during adjudication.

Real-time claim status checks

Both claim acknowledgments and ERAs are asynchronous transactions, sent from the payer to the provider.

If you don’t want to wait, you can use a real-time claim status check to get the current state of the claim from the payer. A claim status check can tell you if a claim is accepted, rejected, denied, paid, or assigned another claim status.

Note: A claim status check might not return anything for a claim that was recently submitted and is still sitting in a queue on the payer side.

Claim status codes

Claim acknowledgments and real-time status check responses include two types of codes that describe the claim’s status: a claim status category code and a claim status code. Some claim status codes also require an entity identifier code that tells you who or what the claim status relates to.

Together, these codes show exactly where your claim stands with the payer.

When written out, each code is often separated by a delimiter, such as a colon (:). For the above example, you may see A7:562:1P (Rejected because of a problem with a provider’s NPI).

For an example without an entity identifier, you might see A7:31 (Rejected because the subscriber’s name is mismatched to the policyholder).

Where to find a claim’s status

Here are the fields where claim status category and claim status codes show up in Stedi’s JSON API responses:

For example, here’s how a rejection looks in a Real-Time Claim Status JSON response:

{
  "claims": [
    {
      "claimStatus": {
        "statusCategoryCode": "A7",	// Rejected as unprocessable.
        "statusCode": "562",		// Problem with the entity's NPI.
        "entityCode": "1P",		// The entity is the provider
        "trackingNumber": "0123456789",
        "tradingPartnerClaimNumber": "0123456789",
	 ...
      },
      ...
    }
  ],
  ...
}

ERA codes

ERAs don’t include claim status codes. Instead, Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs) explain how the payer paid each claim and give reasons for denials in greater detail. For more information, see the ERA reference docs.

Putting it all together

Stedi helps you manage the claims process – from submission to acknowledgment and remittance.

Get started today. Our Basic plan gives you 100 free claim submissions and 100 free ERAs for paid claims each month.