A rejection is not a denial, and the difference decides what you do next

Three places a claim can stop

Follow one claim out of the operatory. The treatment is completed, the codes and the fee go onto the claim, and the claim leaves your practice software. From that moment it passes through three separate parties, and each one of them can stop it for its own reasons.

The first is the clearinghouse. It checks the shape of the claim: whether the required fields are present, whether the identifiers look valid, whether this payer is one it can route to. It is not reading the dentistry. If something fails here the claim comes straight back, usually the same day, and it never reached the payer at all. That is a rejection.

The second is the payer’s intake. The claim has arrived and been accepted as readable, but the payer cannot decide it on what it has. It needs a narrative, an image, a chart, or the primary carrier’s remittance. It writes back asking. That is a request for information, and the claim is now pending on your office rather than on the payer.

The third is adjudication. The payer has everything it needs, applies the plan, and decides. If it declines to pay some or all of the claim, that is a denial, and it is the only one of the three that carries a decision about the treatment.

The order matters for a practical reason. The further along the path a claim stops, the more expensive it is to fix. The early stops are clerical: somebody typed a card wrong, a field was left empty, an identifier does not match. The late stops are contractual, and arguing with a contract takes documentation, time and often a person on the phone.

A rejection never reached a decision

Rejections are boringly consistent in what causes them, and every cause is something a human entered or a system failed to supply.

• A member identifier that does not match what the payer has on file, usually because a card was read quickly or a subscriber changed plans.
• A subscriber date of birth that does not match, which is a common one on dependents, because the patient’s date of birth was entered where the subscriber’s belongs.
• A missing or invalid provider identifier, including the case where the treating provider is right but the billing entity is not.
• A group number typed from the card incorrectly, or a group number that was correct last year.
• A procedure code that is not valid for the date of service, which happens every time the code set turns over and a favourite code stops existing.
• A required field left empty, which the payer or the clearinghouse simply will not accept.

Here is the good news that offices consistently miss. A rejection has no clinical meaning and no contractual meaning. Nobody looked at the dentistry. Nobody decided anything. It did not use up an appeal, because there is nothing to appeal. In most cases it also has not started the trouble an office fears with a filing deadline in the way a denial does, because as far as the payer is concerned nothing was ever filed. Fix the identifier, send it again, and the claim continues as if the false start had not happened.

So the standing instruction is short and it does not change. Somebody reads the acknowledgement report every single day, and that person owns it by name, not by rota. The day it is not read is the day a claim starts ageing for no reason at all, and the day you find out is the day the deadline has already passed. Timely filing is the one deadline you cannot argue your way back from, which is covered in the guide on timely filing denials.

A request for information is pending

The payer has your claim. It is not refusing it. It is telling you that it cannot decide yet and naming what it needs. The usual triggers are predictable.

• A narrative required for a procedure the plan reviews rather than pays automatically.
• A radiograph, or an image showing the condition that justified the treatment.
• A periodontal chart, where the plan wants to see the measurements before it benefits.
• The primary carrier’s remittance on a secondary claim, because the secondary plan cannot calculate anything until it knows what the primary paid.
• A coordination of benefits question, where the payer is unsure which plan is responsible first. That one has its own workflow, described in the guide on coordination of benefits denials.

This is the most damaging of the three to misclassify, and offices misclassify it constantly. If a request for information is filed as a denial, two things go wrong at once. Somebody builds an appeal for a claim that was never denied, which the payer cannot act on because there is no decision to reverse. And the thing that was actually asked for never gets sent, so the claim sits pending until it closes unpaid and finally does become a real problem.

Recognising one on a remittance is easier than it sounds once you know to look. Read the message, not the status. A request asks you for something: it names a document, an image, a chart, a date. A denial states a reason for refusing: a limit, a clause, an exclusion, a date range that has passed. If the sentence ends with something you are supposed to send, it is pending, and the correct next action is to send it rather than to argue.

A denial is a decision

The payer adjudicated the claim and declined to pay some or all of it. That is the whole definition, and it is worth being strict about, because the word gets used for all three events and only this one earns it.

Every denial belongs to one of two families, and sorting it before you touch it is the distinction the rest of this subject is built on.

The plan working as written

A frequency limit, a missing tooth clause, an alternate benefit, a plan exclusion, a waiting period, an annual maximum already met. These are not errors. The payer applied the contract the employer bought and got the answer the contract specifies. Appealing one of these without new clinical information is not a long shot, it is a guaranteed loss, and the real work here is a conversation with the patient about a balance they now owe.

Something that can change

A coding issue, a missing attachment, coordination of benefits ordering, a credentialing or provider identifier problem, timely filing where the proof of submission exists. These are workable. Something about the claim, the documentation or the payer's record of your practice can be corrected, and the same treatment resubmitted with that correction can be paid.

Classifying a denial into one of those two families before working it costs almost nothing. It is a judgement made once, at the moment somebody reads the remittance, while the message is in front of them.

An office that does it stops spending its appeals on exclusions, where nothing was decided incorrectly and there is nothing for an appeal to change. The appeals it does write go to the claims where a correction genuinely changes the answer. The parent guide, why dental claims get denied, walks the common reasons in each family and what to do about each one.

Why merging them ruins your numbers

Once you see the three events as separate, the reporting problem becomes obvious. A denial rate that includes rejections is not measuring payers. It is measuring your own clearinghouse hygiene, which is a real and useful thing to measure and is a completely different management question with a completely different owner. A rate that includes pending requests for information is measuring turnaround, yours and the payer’s together, which is a third question again.

Neither of those tells you what an office thinks it is asking when it asks how much this payer denies. And because the three are so often merged, two practices with identical payer behaviour can report wildly different numbers depending on nothing more than whether their software rolls rejections into the same bucket.

This is a large part of why the denial figures in circulation for dentistry disagree with each other so badly. Different sources are counting different events under the same word, usually without saying which. We looked into what is actually published and wrote up what we found, which is why you will not find a figure quoted anywhere on this page, not even as something to argue with.

Telling them apart in your own software

The practical part. Monday morning, with the software you already have.

1. 1Find where rejections live, and it is probably not your practice software. They usually arrive in the clearinghouse portal as an acknowledgement or a claim status report, separate from anything the practice software shows. Log in and look, even if you have been told the two are connected.
2. 2Separate the other two by the message, not the status field. Requests for information and denials both arrive on the remittance. The status value attached to them is configured per practice, and it very frequently collapses both into one thing. The message text is the reliable signal: asking for something means pending, stating a reason means decided.
3. 3Define your own three way classification and write it down. Rejected, pending on information, denied. Three words, agreed once, used by everyone who touches a claim.
4. 4Record it on the claim, not in a spreadsheet. A spreadsheet beside the software is a second source of truth that goes stale the first week somebody is out, and it cannot be read by whoever picks the claim up next.
5. 5Confirm what your stored values actually mean before you trust a filter. Open a handful of claims you already know the outcome of and check that the value on each one says what you expect. A filter built on a status nobody verified will return a clean looking list of the wrong claims, and it will do it silently.

The habit this all reduces to

Three events, three owners. Rejections go back to whoever prepares claims, because they are clerical and they are fast. Requests for information go to whoever can pull the image or the chart, because the claim is waiting on a document and nothing else. Only real denials need somebody to read a contract or call a payer. An office that routes on that basis is not working harder than one that does not. It is just sending each claim to the person who can actually finish it.