No claim becomes AR90+ at day 90. It becomes AR90+ at day 35, when a status nobody checked turned out to be a denial. Or at day 50, when the payer's information request sat unanswered in a portal. Or at day 70, when the one biller who knew about it went on vacation.
If claims age into AR90+ through a series of small, dateable misses, then a series of small, dateable checkpoints can catch them, and that is what this playbook is: a checkpoint system at days 30, 45, 60, 75, and 90, with a question to answer, actions to take, and an exit rule at each stop. Healthy groups keep less than 10% of AR past 90 days. The way they do it is not heroic rescue work at day 90; it is boring, scheduled attention at every checkpoint before it. (Already sitting on a large 90-plus bucket? Start with our companion guide to reducing AR90+, then come back here to shut off the pipeline that keeps refilling it.)
Why day 90 is too late
Three clocks run against an aging claim. Collection odds fall below 50% once receivables pass 90 days, so even claims you eventually work from that bucket return half value on average. Payer appeal windows typically run 30 to 90 days from the denial date, which means a denial discovered late may be unappealable on the day you find it. Also, timely filing limits close the door entirely on corrected claims that wait too long. Put together: the same claim that is a five-minute status check at day 30 becomes a formal appeal at day 60 and a write-off at day 100.
This is why the operating principle of this playbook is simple: a claim should never be able to surprise you. Not because your team works more hours, but because every claim hits a scheduled checkpoint where someone, or something, is forced to answer one question about it. Queues ordered oldest-first produce busy teams and aged AR. Checkpoints ordered by claim age produce boring reports, and boring reports are the goal.
Days 0–30: the clean launch window
The question this window answers: did every claim leave clean and land confirmed?
Most AR90+ claims initially contained an error: a transposed ID, an unverified plan, a missing attachment. The launch window is where the front-end disciplines from our 12-step revenue cycle checklist are encouraged: eligibility verified before the visit, documentation and coding completed same day, every claim scrubbed against payer-specific rules before it leaves, and, the step most teams skip, every submission tracked to an accepted status rather than assumed accepted because it went out.
Two habits close the window. First, work rejections daily: a claim bounced by the clearinghouse has not started aging at the payer, so a rejection fixed same-day is a claim that never enters the danger pipeline. Second, post what has been paid promptly, because unposted remittances make healthy claims look aged and bury the stuck ones under noise. By day 30, the routine claims have paid, and that is what makes day 30 a checkpoint: whatever has not been paid is now of interest.
Exit rule for day 30: every claim more than 30 days old has a current, known status. Not “submitted.” A status: pending, in review, information requested, denied, or paid-not-posted. “No status” is the first quiet miss.
Days 30–45: the status checkpoint
The question: what does the payer say, and what does the claim need next?
This is the highest-leverage window in the whole playbook, because everything is still cheap. A pending claim needs nothing but a re-check date. An information request needs the attachment sent, this week, not at day 70. A denial discovered here has its entire appeal window still ahead of it. The failure mode of this window is not bad decisions; it is silence, claims that sit statusless because getting a status means a portal login or twenty minutes of hold music per claim.
So the operational move at day 30–45 is to make statuses cheap. This is where automation is important: InsideAssist syncs daily with practice management systems and payer portals, pulls live claim statuses and denial reasons in bulk, and surfaces a next best action on each claim, so the checkpoint question gets answered across the whole portfolio without a biller hunting claim by claim. Whether you automate it or staff it, the standard is the same: by day 45, no claim is waiting on you.
Exit rule for day 45: every open claim has an owner and a next action with a date. Information requests answered. Denials logged with reason codes and routed for correction or appeal. Anything pending has a scheduled re-check. The claim may still be unpaid, but it may not be unowned.
Days 45–60: the escalation window
The question: why is this specific claim still here, and who is forcing it forward?
Claims that cross day 45 unpaid have declared themselves exceptions, and exceptions need pressure. Denials get corrected and resubmitted, or formally appealed, now, while windows are comfortably open. Underpayments get contested against the fee schedule rather than absorbed. Payers whose “pending” has stretched past their own published processing times get called or escalated. Additionally, the patient-responsibility portion moves through its second statement cycle with a payment option attached, before the balance hardens into the kind nobody collects.
This window is also where prioritization starts deciding real dollars. Worked oldest-first, a queue spends its afternoon on a $40 claim while a $4,000 crown with a closing appeal window waits. Worked by dollars and deadline, the same afternoon protects the revenue that matters. The sort order is the strategy.
Exit rule for day 60: nothing crosses day 60 without a documented reason and an active plan. As a distribution target, healthy groups hold AR past 60 days under roughly 20% of total AR; a growing past-60 share at flat production is the earliest reliable warning that this checkpoint is being missed.
Days 60–90: the last cheap exit
The question: which of these claims are racing a deadline, and are we ahead of it?
Everything in this window is triage, and triage runs on two sorts being appeal and filing deadlines first, dollars second. Some payer windows opened at the denial date are already in their final weeks here, so the first pass every week is deadline-driven, where what becomes unappealable in the next 14 days is prioritized. The second pass is value-driven, so of what remains, where are the largest recoverable balances. A useful ritual at day 75 is to do a supervisor review of every claim approaching the line, five minutes per claim, one decision each, escalate, appeal, correct, or, with eyes open, release. What must not happen is the default path which is the claim that crosses into AR90+ because no one decided anything.
Exit rule for day 90: no claim crosses into AR90+ undecided. Every crossing is either actively in appeal, formally escalated, or consciously written off with a reason code, and every write-off gets counted as the loss it is, not buried in contractual adjustments where the lesson disappears.
Day 90+: containment and the postmortem habit
Whatever crosses anyway gets two treatments. The first is containment: work the bucket by deadline and dollars exactly as at day 60–90, accepting that recoveries here run at reduced odds; the full rescue methodology is in our AR90+ reduction guide. The second treatment is the one that actually shrinks next quarter's bucket: the postmortem. Every claim that reaches AR90+ names the checkpoint that missed it. Statusless at 30? The launch window leaked. Denial found at 70? The status checkpoint failed. Attachment request unanswered? Day 45's exit rule was not enforced. Run that tally monthly and the pattern will be concentrated, usually two or three misses, at specific offices, with specific payers, and each one is a process fix. AR90+ stops being a bucket you drain and becomes a defect count you drive toward zero.
Making it run at DSO scale
A single office can run this playbook on discipline and a spreadsheet. A group cannot, for the same reason a group cannot manage to a blended AR days number: at scale, the playbook is only as strong as its least consistent location, and manual checkpoint-keeping drifts the moment staff turn over. Three things make it durable across a portfolio.
Same checkpoints, every office. The days, questions, and exit rules do not vary by location. What varies is the local payer mix and the volume because the moment offices improvise their own thresholds, the group's aging report stops meaning one thing.
Visibility by location and payer. Leaders need to see checkpoint compliance the way they see production: which offices have statusless claims past 30, where past-60 share is drifting, which payers generate the day-75 pileups. Blended numbers hide exactly the office the playbook exists to catch.
Automation for the mechanical layers. The playbook's first two checkpoints are mostly information retrieval, and information retrieval is what should not consume skilled biller hours. InsideAssist keeps the checkpoint data continuously current, live statuses, denial reasons, and EOBs pulled daily across every location, and keeps the work sorted by dollars and deadline, so the humans spend their judgment on days 45 through 90. That division of labor, software answers the questions, people make the decisions, is what lets a 20-location group run the same playbook a great office manager runs on willpower.
How you know it is working
The playbook's scoreboard is the aging distribution, read monthly, by location. AR past 90 days trends toward and under 10% of total AR, and stays there without heroic cleanup pushes. AR past 60 holds under roughly 20%. The share of claims crossing day 45 without an owner trends toward zero, and, the most satisfying line, the monthly postmortem count of new AR90+ entries shrinks quarter over quarter as the upstream fixes land. Days in AR under 30 follows on its own, because AR days are downstream of everything this playbook controls.
30/45/60/90 playbook FAQ
Why do dental claims end up in AR90+?
Rarely because payers are slow, and usually because a fixable problem went undiscovered: a statusless claim, an unanswered information request, a denial found after its appeal window opened late. Aging is the accumulation of small misses at specific, predictable windows, which is why age-based checkpoints prevent it.
What should happen to a claim at day 30?
It should have a current, known payer status: pending, in review, information requested, denied, or paid awaiting posting. “Submitted” is not a status. The day-30 checkpoint exists to convert silence into information while every fix is still cheap.
How do payer appeal windows change follow-up timing?
Appeal windows typically run 30 to 90 days from the denial date, not the service date, so a denial discovered late arrives with its window partly spent. The playbook front-loads status discovery at days 30 to 45 precisely so the full window is available, and triages days 60 to 90 by deadline before dollars.
What is a realistic AR90+ target for a dental group?
Under roughly 10% of total AR, held steadily rather than achieved through periodic cleanup pushes, with less than 20% past 60 days as the upstream check. A 90-plus share that only looks healthy right after a write-off sweep is not healthy; it is being laundered.
How is the playbook different for a DSO than a single office?
The checkpoints are identical; the enforcement is not. A group needs the same exit rules at every location, per-location visibility into checkpoint compliance, and automation for the status-gathering layers, because manual playbook-keeping is exactly the discipline that drifts as locations and staff multiply.
Claims age one quiet week at a time
AR90+ feels like a fact of dental billing because its causes are invisible at the moment they happen: nothing announces the day a claim silently misses its checkpoint. The playbook makes those moments loud. Five checkpoints, five questions, five exit rules, and a postmortem habit that turns every miss into an upstream fix. Groups that run it stop rescuing revenue at day 90 because there is less and less at day 90 to rescue.
Want the checkpoint data, live statuses, denial reasons, and dollars-and-deadline priorities, kept current automatically across every location? See InsideAssist in action.
