Ask a practice manager where their A/R problems come from and you will hear about denials, coding edits and slow payers. Ask them how many hours a week go into prior authorisations and you get a different answer, the exasperated one. Prior authorisation is the single process that consumes the most staff time, delays the most care, and produces the largest share of “we did everything right and still didn’t get paid” claims.
What this covers
- The claim has to match the authorisation on code, units, dates, provider and place of service.
- Impacted payers must decide within 72 hours (urgent) or 7 calendar days (standard) from 2026.
- A denied authorisation must now carry a specific reason, which is appeal evidence.
- Approvals carry expiry dates and unit ceilings, and somebody has to watch both.
An authorisation is approval for a defined service. It is not blanket approval for anything related to it.Why approved services still get denied
It is also the process most likely to change in 2026 and 2027, because federal rules now require the payers who use it most heavily to answer faster and explain themselves. Understanding both halves of that, the operational discipline you need today, and the timelines payers now have to meet, is what turns prior authorisation from a cost centre into a controlled process.
What prior authorisation is, and where it sits
Prior authorisation is a payer’s advance decision that it will cover a specific service for a specific patient, usually with a defined number of units and a defined validity period. It sits in front of the claim: the service happens, then the claim must prove it matches what was approved.
That “must match” is where most losses occur, and it is not one field, it is a chain:
- Patient and plan, the right member, the right plan year, the right primary payer.
- Service: the correct CPT or HCPCS code, including the specific code the payer approved rather than a related one.
- Units and dates: quantity and service dates inside the approved window, not only near it.
- Rendering provider and place of service, the auth belongs to a provider and a location, and both must appear on the claim.
- Diagnosis: supporting the authorised service, consistent with what was submitted for review.
Break any link and the claim is denied for authorisation reasons even though an authorisation exists, which is the frustrating part. The practice did the work and got the approval. What it did not do was keep the approval and the claim describing the same thing.
The four ways prior authorisation costs you money
1. The request itself
Clinical and administrative staff chasing portals, faxes and telephone queues is a real cost, and it is usually invisible because it is spread across people rather than billed to a code. The characteristic symptom is a practice that has clinicians spending time on authorisation paperwork or administrators spending hours on hold, while the actual billed service waits.
2. Approval obtained, claim denied anyway
The mismatch chain above. The most common single cause we see is an authorisation approved for a code or unit count that differs from what was finally documented, four units approved, six delivered and documented; a procedure authorised for one approach and performed with another; a drug approved at one dose and administered at a higher one.
3. Authorisation expiry
Authorisations carry end dates and often a maximum span from the approval date. A surgery postponed three weeks, a series of infusions scheduled across a plan year boundary, or a therapy plan continuing past the approved visit count can all land outside validity. The service is still appropriate; the authorisation is simply no longer live.
4. Service delivered without authorisation
Sometimes because the requirement was not identified, sometimes because clinical urgency overrode the process. Retrospective authorisation exists with some payers and in some circumstances, but it is discretionary and frequently refused. In most cases, the honest accounting is that the service becomes a write-off or a patient-balance conversation, the worst outcome for the practice and for the patient.
Approval means the payer has agreed the service is covered for this patient under these terms. It does not guarantee the claim pays, and it does not override eligibility problems, benefit limitations, timely filing or correct coding. Practices that treat an auth number as proof of payment are the ones surprised by the denial.
What has actually changed in the rules
The federal picture shifted with the CMS Interoperability and Prior Authorization final rule (CMS-0057-F, finalised in 2024). It does not cover every plan, it applies to what the rule calls impacted payers: Medicare Advantage organisations, state Medicaid and CHIP fee-for-service programmes, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the federal exchanges. Commercial employer group plans are largely outside it and still set their own timelines.
For the payers it does cover, the substantive requirements are:
| Requirement | Timing |
|---|---|
| Prior authorisation decisions for expedited (urgent) requests | Within 72 hours |
| Prior authorisation decisions for standard (non-urgent) requests | Within 7 calendar days |
| A specific reason provided for a denied prior authorisation request | From 2026 |
| Public reporting of prior authorisation metrics | Annually, first posting covering calendar year 2025 due by 31 March 2026 |
| Prior Authorisation API supporting electronic requests and decisions | By 1 January 2027 |
| Provider Access API so providers can retrieve claims, encounter and prior auth data | By 1 January 2027 |
First: denial reasons. If an impacted payer denies a prior authorisation, it now has to say specifically why. That is a lever, a vague denial is worth challenging, and a specific one tells you exactly what to fix for the resubmission. Treat the reason field as appeal evidence rather than a formality.
Second: published metrics. Impacted payers must post prior authorisation metrics annually. Those disclosures are public and specific to each payer, denial rates, turnaround times, volume. They are the first honest way to compare payers, and a rational basis for deciding where to invest your appeal resources and where to renegotiate.
Where authorisation pain concentrates by specialty
- Imaging and diagnostics, approval is per modality, per body part and often per laterality, so a change in technique invalidates the authorisation.
- Infusions and biologics: J-code billing, dose calculation and wasted-drug documentation all have to reconcile with the approved quantity, and payers read all three.
- Surgery: the procedure, the assistant, and sometimes the facility each need their own authorisation; approving one does not approve the rest.
- DME and supplies: authorisation tied to quantity, frequency and length of need, with documentation requirements that closely mirror the auth request.
- Behavioural health and ABA, authorisations are expressed in units and hours per week with an end date, so continuing care past the authorised amount is unbillable by definition.
- Therapy services: visit caps per plan year, with recertification requirements that are easy to miss mid-episode.
The system that keeps authorisation from leaking
None of this requires a new platform. It requires the authorisation to live somewhere that has dates and owners attached:
- A live authorisation register. One record per auth with the payer, auth number, approved code, units, span, rendering provider, place of service, and the patient’s next scheduled service date.
- An expiry watch. Sorted by what expires soonest, reviewed weekly, with re-request triggered by remaining units or remaining days, not by a calendar reminder you set months ago.
- A no-auth, no-schedule rule. The authorisation is confirmed before the appointment is booked, not discovered at billing. This is the single highest-impact change and it belongs at scheduling, not in the billing office.
- Auth-to-claim reconciliation. Every claim with an auth number checked against that number’s approved scope before submission, the mismatch chain above, checked mechanically rather than remembered.
- A denial-reason log. Each denied auth request recorded with the stated reason and the outcome of the resubmission, so the same avoidable error does not repeat every month.
In our experience the register is the whole game. Prior authorisation does not fail because staff are careless; it fails because the approval lives in a PDF and the schedule lives in an EMR and nothing ties them together. Our denial management process works authorisation mismatches as a denial category with its own root cause, alongside billing and coding, and for specialties where authorisation is the dominant denial driver, it is the first thing we rebuild.
Questions we get about prior authorisation
For impacted payers under CMS-0057-F. Medicare Advantage, Medicaid and CHIP programmes, Medicaid managed care plans and qualified health plan issuers on the federal exchanges, 72 hours for expedited or urgent requests and seven calendar days for standard requests, with compliance beginning in 2026. Commercial employer group plans are outside that rule and set their own timelines, so payer-specific turnaround expectations still matter operationally.
Because the claim and the authorisation described different things. The usual mismatches are units or dates outside the approved span, a CPT or HCPCS code that differs from what was approved, a rendering provider or place of service that does not match the authorisation, or a diagnosis that does not support the service reviewed. An authorisation is approval for a defined service, not blanket approval for anything related to it.
Sometimes, if the payer offers retrospective authorisation and the clinical documentation supports urgency or an emergency. It is discretionary and frequently refused, so it is a fallback rather than a workflow. Where retrospective approval is not granted, the service generally becomes a write-off or a patient responsibility conversation, so the authorisation check belongs before scheduling rather than before billing.
The units beyond the approved amount are generally not payable, even when the service was clinically necessary and properly documented. The prevention is monitoring consumption against the approved units and triggering a re-request at a defined remaining-units threshold, so the new approval arrives before the old one is exhausted.
Impacted payers are now required to publish annual prior authorisation metrics, volumes, denial rates and turnaround times. For the payers covered by the rule, those public disclosures support a genuine comparison rather than a feeling. For commercial plans outside it, the equivalent comparison comes from your own denial and resubmission data, tracked by payer and by authorisation reason.
No: it changes where the data lives, not whether anyone watches it. The Prior Authorisation API requirements taking effect in 2027 let requests and decisions move electronically through an EHR, which removes the fax-and-phone burden. Approvals will still carry units, spans and providers that somebody has to reconcile against scheduled and delivered services. Automation shortens the transaction; it does not own the calendar.
The bottom line
Keep the authorisation in the same place as the schedule, with dates and units attached, and check the claim against it before submission rather than after a denial. The register is the whole game.
How much of your A/R is waiting on authorisation?
Send us a month of denied claims and your authorisation log. We will show you how much of the denial volume traces back to an auth mismatch, an expired approval or a missing authorisation, and what rebuilding the process is worth.
Request a free denial analysisPrior authorisation requirements, turnaround expectations and retrospective review policies vary by payer, plan and state law. The federal timelines described here apply to the payers defined as impacted payers under CMS-0057-F and do not cover commercial employer group plans generally. Confirm current requirements with each payer, and check the CMS fact sheet and FAQ for authoritative compliance dates.
