
Pended authorizations fail silently — nobody calls to tell you a request is still sitting. Tracking therefore needs a follow-up clock that surfaces requests by days since submission, not a status field somebody has to remember to update.
Most authorization tracking is a spreadsheet with a status column. It works until a request pends, and pended requests are where the failures live.
Why a status field is not enough
"Submitted" is true the day it is entered and still true three weeks later. Nothing about the field changes as it ages, so nothing prompts anyone to look. The request sits, the service date arrives, and the authorization is discovered missing at the worst possible moment.
Denials announce themselves. Pends do not.
What tracking actually needs
- A follow-up date on every open request, set when it is submitted, based on that payer's realistic turnaround rather than their stated one.
- An owner, by name.
- A link to the service date, so anything approaching its appointment escalates automatically.
- An escalation rule — what happens when a request passes its expected date without an answer.
- Reference numbers for every contact, which is what makes a later appeal possible.
The report that matters
Not "open authorizations". Open authorizations past their follow-up date, sorted by how soon the service is scheduled. That single view is the whole discipline, and it is the one a status column cannot produce.
The upstream check
Equally important is the reverse: scheduled services with no authorization on file at all. Catching those days before the appointment is the difference between rescheduling and delivering a service nobody will pay for.
The escalation nobody plans
Every payer has a point past which a normal follow-up call stops working and the request needs a supervisor, a peer-to-peer, or a formal complaint. Practices rarely define that point, so requests get called weekly forever.
Set a rule: after a defined number of contacts or days, it escalates. Otherwise the follow-up clock produces activity rather than outcomes.
Check the service date against the approval window
An approval is valid for a defined period, and a rescheduled procedure can fall outside it. That is one of the most preventable denials there is, and it is invisible unless someone compares the approval window to the booked date after every reschedule.
Build the check into rescheduling, not into billing. By the time a claim denies, the service has been delivered.
Upstream is where the volume drops
The cheapest authorization is the one not required. Payer policies change, and services that needed authorization last year sometimes do not now. Reviewing the requirement list annually removes work that has simply become unnecessary.
Common questions
- How should a practice track prior authorizations?
- By a follow-up date rather than a status. Every open request needs a next-check date, and the report should surface anything past it automatically.
- Why do pended authorizations get missed?
- Because nothing happens when they stall. There is no denial, no notice and no alert — the request simply sits, and the service date arrives with no approval.
- What report do I need for authorizations?
- Open requests sorted by days since submission, with anything past its follow-up date at the top. A list of authorization statuses is not the same report.
- Who should own authorization follow-up?
- A named person with time allocated to it. Split across whoever is free, it becomes the work that gets dropped when the day gets busy.
- Can I schedule a service before authorization is approved?
- You can, but the risk sits with the practice. An unauthorized service commonly denies with no appeal route and no ability to bill the patient.
Denials Piling Up?
We handle the revenue cycle end to end — coding by certified coders, claim submission, denial management and appeals, and A/R follow-up, with six reported numbers every month.
