Rejected claim
A rejected claim generally fails an edit before it completes adjudication. The response may come from a clearinghouse, payer front-end edit or acknowledgement transaction. The team should identify the exact rejection source and correction required before resubmitting.
Denied claim
A denied claim has generally reached adjudication, but the payer did not pay it as submitted. The remittance information, reason codes, payer policy, documentation and appeal or correction path should be reviewed together.
Do not choose the action from the label alone
Different systems may use similar words for different events. Confirm the actual response and the period it covers. A useful review starts with the acknowledgement, claim-status response, remittance advice or payer portal—not with a general dashboard total alone.
- Which system produced the response.
- The edit or rejection code.
- Whether the batch or one claim failed.
- What must be corrected.
- Who owns resubmission and by when.
- The adjustment or reason codes.
- The payer explanation and policy.
- Documentation or authorization requirements.
- Correction, reconsideration or appeal options.
- The filing or appeal deadline and owner.
Use patterns to prevent repetition
Grouping responses by payer, reason, location, provider and responsible workflow can reveal whether the recurring problem begins with eligibility, registration, authorization, documentation, coding, claim creation or follow-up. A category alone does not prove the cause; it tells the team where to investigate first.
Primary reference
CMS describes front-end claim edits, acknowledgements and status checks in its Checking Medicare Claim Status fact sheet. Commercial payer terminology and procedures may differ, so always verify the applicable payer response.
No vendor can guarantee reversal or payment. The appropriate action depends on the claim, payer response, documentation and applicable requirements.
Explore Denials support