The denials you can prevent at verification
Most dental claim denials are decided before the claim is ever filed. They are determined at verification, when a benefit detail is missed, and they surface weeks later — after the chair is empty and the patient has been given a number you now have to walk back.
Denial work has a structural problem: it happens at the worst possible moment. By the time an EOB comes back with an adjustment, the treatment is delivered, the estimate is quoted, and the patient has an expectation. Whatever you recover, you recover through appeals, rebilling, and a conversation nobody wants to have.
Which is why the useful way to think about denials is not "how fast can we work them" but "which of these should never have happened."
The two categories
Every denial falls into one of two buckets, and they call for completely different responses.
Determined at verification. The plan detail existed and was knowable before treatment. Someone either didn't retrieve it, or retrieved a version of it that was incomplete. These are preventable — not by working denials harder, but by verifying more completely.
Determined at submission. The eligibility was right, but the claim went out missing something the payer requires: an attachment, a narrative, a correct code pairing, a tooth or surface designation. These are preventable too, but at a different stage — by scrubbing before the claim leaves.
A denial report that doesn't separate these two is hard to act on, because it mixes a verification problem with a submission problem and produces a single number that points nowhere.
What gets missed at verification
Frequency limitations
The patient is eligible and the procedure is covered — but the plan allows it once every so many months, measured from the last date of service, which may have been at a different practice. Portals often show the benefit without showing the history that constrains it. This is one of the most common preventable denials in dentistry, and it is entirely knowable in advance.
Waiting periods
Coverage is active, so the plan reads as verified. But major services carry a waiting period the patient hasn't satisfied yet. The claim is denied not because the benefit doesn't exist, but because it doesn't exist yet.
Downgrade provisions
The procedure is covered, but the plan pays at the rate of a less expensive alternative — composite paid as amalgam, a porcelain crown paid at a base metal rate. Nothing is denied outright. The payment simply lands under the estimate, and the difference becomes a patient balance that was never discussed.
Missing tooth clause
The plan excludes replacement of teeth extracted before coverage began. It is a single provision, it is rarely surfaced by a portal summary, and it turns an approved-looking bridge or partial into a full write-off.
Annual maximum already consumed
Remaining benefit is a moving number. Verified in January and treated in October, the maximum may be gone — including through claims filed by a specialist you never see. A verification that captures remaining maximum at the time of verification, rather than the plan's annual maximum, is a different and much more useful fact.
Coordination of benefits
Dual coverage misordered, or a secondary plan the practice didn't know existed. The claim goes to the wrong payer first and comes back denied for a reason that has nothing to do with the dentistry.
Why "verified" is not one thing
Every one of the items above is a field, and the practical question about any verification process is which fields it actually returns.
A verification that confirms active coverage and a coinsurance percentage is genuinely verified — it just isn't verified against the things that generate denials. Many payer portals return exactly that and stop. Getting waiting periods, downgrade provisions, frequency measured from last date of service, missing tooth clauses, and remaining annual maximum frequently means a second channel: a call to the payer, a direct API, faxback, or a clearinghouse EDI transaction that carries more detail than the portal page did.
This is the connection people miss. Denial rate is downstream of verification depth. Groups that treat denials as a billing-team problem are usually trying to fix an outcome at the stage where it is most expensive to fix.
What gets missed at submission
The second bucket is narrower and more mechanical, which makes it more automatable.
- Missing attachments — radiographs, perio charting, or a narrative the payer requires for that code. The claim is complete in every other respect and still comes back.
- Code and documentation mismatch — the procedure billed doesn't match what the documentation supports, or a code pairing the payer doesn't accept.
- Missing tooth number, surface, or quadrant — omissions a payer's edits reject automatically.
- Stale eligibility — the claim is filed against benefits verified months ago, and the patient's coverage changed in between.
That last one is worth sitting with, because it is the seam between the two buckets. A claim built from a verification that was accurate when it was performed can still be denied because nothing rechecked it. When verification and claims run on separate systems, that recheck usually doesn't happen — there is no mechanism for it to happen.
How Mila handles it
Verification and claims run on the same engine, which is what makes the recheck structural rather than procedural. The data that cleared eligibility is the data that files the claim — no re-keying, no drift between two systems' idea of the same patient.
Before a claim leaves, the Scrub Agent checks it against live eligibility, CDT codes, and payer rules. The Attachment Agent pulls the narratives, perio charts, and radiographs the payer requires for that submission. The Submission Agent files electronically and tracks status through to adjudication. Human QA reviews high-dollar and high-risk claims before they go out — the ones where being wrong is expensive enough to justify a person.
On the verification side, five channels feed one unified data layer — portal agents, call AI plus a call center, direct payer APIs, faxback, and clearinghouse EDI — which is how the fields that cause denials get retrieved when a portal alone won't return them. Up to 95% of verification completes end-to-end automatically, most of it in under 15 minutes.
To be straight about status: insurance verification has been live for seven years and claim submission is live. Denial management is a layer we are actively expanding, alongside payment posting and patient outreach. We would rather tell you that than describe a roadmap as a product.
How to find your own preventable rate
You do not need a vendor to do this. Pull your last quarter of denials and sort them into three piles:
- Knowable at verification — frequency, waiting period, downgrade, missing tooth, maximum consumed, COB order.
- Knowable at submission — missing attachment, code or documentation mismatch, missing tooth number or surface.
- Genuinely unforeseeable — retroactive terminations, payer error, mid-treatment plan changes.
In most practices the third pile is the smallest by a wide margin. The first two are the ones you are paying for twice: once in the write-off or the appeal, and again in the staff hours spent working a denial that a more complete verification would have prevented.
That number is your actual denial problem. Everything else is triage.