What is an entity code in medical billing? Reading a 277CA rejection
An entity code in medical billing is a short code that says which party on a claim a message is about. When a clearinghouse or payer rejects a claim and the note reads "this code requires use of an entity code", the rejection is pointing at a specific person or organization on the claim, and the fix starts with finding out which one.
What an entity code is
Every electronic claim names several parties. There is the provider who bills, the provider who performed the service, the place it happened, the patient, the person who holds the insurance and the payer itself. The X12 standards that carry claims between practices, clearinghouses and payers give each of those roles a short identifier, called an entity identifier code.
On the claim itself, the 837, those codes label each name and address loop so the payer knows who is who. On the way back, when a claim fails an edit, the same codes tell you whose data failed. A message that says only "invalid NPI" is ambiguous on a claim that carries three NPIs. A message that says "invalid NPI, entity 82" is not: it is the rendering provider.
That is why the X12 claim status code list marks so many of its codes with the note "This code requires use of an Entity Code." Those status codes describe a kind of data, such as a name, an address, an identifier or a date of birth, and they only make sense once you know whose data it is.
Where entity codes show up
Entity codes come back on two transactions, and neither of them is the remittance.
The first is the 277CA, the claim acknowledgment. Clearinghouses and payers send it within a day or two of submission to say whether each claim was accepted into the payer system or rejected at the front door. This is where most practices meet entity codes, usually as a line in the clearinghouse rejection report.
The second is the 277 claim status response, the answer to a 276 status inquiry. It uses the same three-part structure to report where an accepted claim stands, and it can carry an entity code when the status involves a specific party, such as a request for information from the rendering provider.
The 835 remittance does not use entity codes. Once a claim has been adjudicated, problems are reported with group codes, claim adjustment reason codes and remark codes instead, which our guide to denial codes covers. If you are looking at an entity code, the claim has not been paid or denied. It has been rejected or is still in process.
How to read the three-part status
A rejection in a 277CA is reported in the STC segment as three codes joined together. Most clearinghouses display them separated by colons:
- The claim status category code says what kind of outcome this is. A3 is a claim returned as unprocessable, A6 is a rejection for missing information and A7 is a rejection for invalid information.
- The claim status code says what data the problem is about, such as 562 for the National Provider Identifier or 158 for a date of birth.
- The entity identifier code says whose data it is.
Put together, A7:562:85 reads as "rejected for invalid information: the NPI of the billing provider." A6:158:QC reads as "rejected for missing information: the date of birth of the patient." Read in that order, almost every rejection turns into a specific field on a specific loop of the claim.
The entity codes you will see most
| Entity code | Party | Where it lives on the 837P | CMS-1500 box |
|---|---|---|---|
| 85 | Billing provider | Loop 2010AA | Box 33 and 33a |
| 87 | Pay-to provider | Loop 2010AB | Box 33 when it differs from billing |
| 82 | Rendering provider | Loop 2310B, or 2420A at line level | Box 24J |
| 77 | Service location | Loop 2310C | Box 32 and 32a |
| DN | Referring provider | Loop 2310A | Box 17 and 17b |
| DK | Ordering provider | Loop 2420E | Box 17 with the DK qualifier |
| IL | Insured or subscriber | Loop 2010BA | Boxes 1a, 4 and 7 |
| QC | Patient | Loop 2010CA | Boxes 2, 3 and 5 |
| PR | Payer | Loop 2010BB | Payer name and address at the top of the form |
The box numbers follow the CMS-1500 instructions in the Medicare claims processing manual. Practice management systems build the 837 from those same fields, so the box is usually the quickest place to look.
Common entity code rejections and their fixes
Most entity rejections are not typing errors on the claim. They are mismatches between the claim and a record the payer checks it against.
Billing provider, entity 85
The payer compares the billing provider NPI, legal name, tax ID and address against its enrollment file. Common failures are an individual NPI sent where the group NPI belongs, a name that does not match the IRS record exactly, and a post office box in the billing provider address. The 837 requires a street address for the billing provider, and a post office box can only go in the pay-to loop. Check the group record in NPPES and the payer enrollment, then make the practice management system match both.
Rendering provider, entity 82
A valid NPI rejects here when the provider is not linked to the billing group with that payer, or the taxonomy code on the claim does not match the one the payer has on file. New providers are the usual source: the claim goes out before credentialing and enrollment have finished linking them to the group.
Subscriber and patient, entities IL and QC
These come from the payer eligibility file. The member ID, name spelling, date of birth and relationship to the subscriber all have to match. A married name the plan never received, a dependent billed under their own ID when the plan expects the subscriber, or a transposed date of birth will each reject. Running eligibility verification before the visit catches most of these while the patient is still at the front desk.
Service location and referring provider, entities 77 and DN
Service facility rejections usually mean the facility NPI is missing or the address is incomplete, often because the claim was built from a location record that was never finished. Referring provider rejections show up on specialties and services that require a referral, when the referring NPI is missing or belongs to a provider who is not enrolled with Medicare.
Rejection, not denial: what to do next
Because a rejected claim never entered adjudication, there is nothing to appeal and nothing to correct. The payer has no claim on file. Fix the field and send the claim again as a new claim, with claim frequency code 1. Sending it as a corrected claim with frequency code 7 usually produces a second rejection, because there is no original claim for it to replace.
The clock matters more than the code. The timely filing limit runs from the date of service, which for Medicare fee-for-service is one calendar year, and a rejection does not stop it. A claim that sat in a rejection queue for three months has used three months of its filing window. Work the 277CA report daily, not when the A/R report shows the gap weeks later.
Keep the rejection report with the resubmission. If a filing limit is ever in dispute, the acknowledgment shows when the claim first reached the payer, even if the claim was rejected.
Stopping the same rejection twice
A rejection that repeats is a setup problem, not a claim problem. Track rejections by entity code and status code for a month and the pattern is usually obvious: one provider's taxonomy, one location's address, one payer's enrollment that never linked a new hire.
Fix the record, not just the claim. Update the provider or location master file in the practice management system, confirm the payer enrollment matches NPPES, and add a scrubber edit for the pattern so the clearinghouse stops the claim before the payer does. A claim submission process that clears these edits first sends claims that are accepted on the first pass, and those are the claims that get paid on time.
Questions This Article Gets Asked
It is a usage note printed beside many claim status codes in the X12 code list. The status code on its own says what kind of data failed, such as an NPI or a date of birth, and it needs an entity code next to it to say whose NPI or whose date of birth. Look for the two-character code after the status code in the rejection.
In the 277CA claim acknowledgment it sits in the STC segment as the third part of the status, after the category code and the claim status code. Most clearinghouse portals print the three together, often as A7:562:85, and many add a plain-English translation of each part beside it.
No. A rejection happens before the payer adjudicates the claim, so there is no remittance, no reason code and no appeal. A denial comes after adjudication on an 835 remittance with a claim adjustment reason code. Rejections are fixed and resubmitted, while denials are corrected or appealed.
Usually not. A rejected claim never entered the payer system, so there is nothing to correct or replace. Send it again as a new claim with frequency code 1. A corrected claim with frequency code 7 is for claims the payer has already processed and assigned a claim control number.
Because the payer is matching more than the NPI. The billing provider name, tax ID, taxonomy code and address are checked against the payer enrollment record together. A legal name that differs by one word, a taxonomy that does not match NPPES or a post office box in the billing address will reject a claim with a valid NPI.