“Subscriber and subscriber id not found” means the payer could not match the patient’s insurance details to a member in its system, so the claim was rejected before processing. The fix is almost always in the registration data: the member ID, name, date of birth, or how the patient and subscriber are set up on the claim.
What does status code 33 mean?
X12 claim status code 33 reads: “Subscriber and subscriber id not found.” It is published in the X12 Claim Status Codes list (opens in a new tab). The payer looked up the subscriber on the claim and found no match.
On the raw 277CA it appears in the STC segment, for example STC*A7:33: the claim status category, then the status code, then the entity code when one is required. A rejected claim never entered the payer’s claims system, so there is nothing to appeal: you fix the data and send the claim again.
Common causes
| Cause | What to check |
|---|---|
| Member ID typed wrong, or a prefix or suffix left off | The insurance card and the eligibility response |
| Name or date of birth does not match the payer’s record | Eligibility response, including spelling and hyphenated names |
| Dependent billed under the subscriber’s ID when the plan issues each member their own ID | Eligibility response for the dependent |
| Coverage changed or ended | Current card and eligibility as of the date of service |
| Medicare claim sent with an old ID instead of the Medicare Beneficiary Identifier (MBI) | The patient’s current Medicare card |
| Claim sent to the wrong payer or plan | Payer ID; see status 116 |
How to fix it
- Run an eligibility check (270/271) for the date of service.
- Copy the member ID, name and date of birth exactly as the payer returns them.
- If the plan gives the patient their own member ID, bill the patient as the subscriber (relationship “self”).
- Update the patient’s registration record, not just the claim.
- Resubmit as a new claim and confirm acceptance on the next 277CA.
How to prevent it
- Scan both sides of the insurance card at every visit.
- Run eligibility before the visit and when coverage changes.
- Use the eligibility response, not typed card data, to fill subscriber fields.
Frequently asked questions
Is status 33 a denial?
No. It is a rejection: the claim never entered the payer’s system, so it is corrected and resubmitted rather than appealed.
The eligibility check works but the claim still rejects. Why?
Compare the claim against the eligibility response field by field. Differences in name format, dependent setup or payer ID are the usual culprits.
Related claim rejection guides
- 277CA claim acknowledgment: how to read a rejection
- Status 562: Entity’s National Provider Identifier (NPI)
- Status 116: claim submitted to incorrect payer
- Status 128: Entity’s tax ID
- Status 145: Entity’s specialty/taxonomy code
- Status 496: submitter not approved for electronic claims
- “This code requires use of an Entity Code”
Status code wording is quoted from the X12 Claim Status Codes list (opens in a new tab) at the time of writing. Clearinghouse reports may show the same codes with slightly different text.
Registration errors causing rejections?
Our eligibility verification checks member details before the visit, so claims match the payer the first time.