Prior Authorization Cost Calculator
Prior authorization is rarely on a budget line, which is why it is rarely managed. This model puts the staff hours and the dollars in one place, then shows what a realistic coverage figure does to both. It deliberately does not assume automation lowers your denial rate, because that depends on your payers rather than on your software. Every input is yours to change and every formula is printed below.
Updated August 5, 2026Free, no signupRuns in your browser
Your volume
Submissions, not procedures. One procedure can generate more than one.
Gathering, submitting and chasing. Portal waiting time counts if a person is sitting there.
Wage plus benefits and employer taxes, divided by hours actually worked.
Rework
Anything that comes back for more information, not only formal denials.
Appeal, peer to peer and resubmission time, averaged.
Automation scenario
Payers and procedures with a workable electronic path. The rest stays manual.
Review and exception handling. An agent that needs no human at all is not a scenario we would sign off.
Your model
Annual staff cost avoided
$25,480
$2,123 a month, from 17.5 staff hours returned each week.
Staff hours per week on prior authorization
Both bars carry the same rework load. Only handling time on covered requests changes.
Modeling estimate, not a quote or a guarantee. Assumptions are editable and every figure above is derived from the values you entered. Returned hours are only a saving if the role is genuinely rescoped. Otherwise they are capacity, which is worth having but is not a budget line.
How this is calculated
reworked requests per week = requests per week x share denied or returned
minutes today = (requests x minutes per authorization) + (reworked requests x minutes per rework)
minutes with automation = (covered requests x minutes on a covered request) + (uncovered requests x minutes per authorization) + rework minutes, unchanged
monthly cost = weekly hours x staff hourly cost x 52 / 12
full time equivalent = weekly hours returned / 40
Methodology and assumptions
What the model does, and what it refuses to guess
Two scenarios, five formulas and one deliberate refusal. All of them are visible.
What it calculates
Weekly minutes today are your request volume multiplied by the staff minutes each request takes, plus the rework load: the share of requests that come back multiplied by the minutes a rework consumes. Divide by 60 for hours, then multiply by your fully loaded staff hourly cost and by 52 divided by 12 to get a monthly figure.
The automation scenario splits your volume in two. The share an agent can cover is charged at the reduced handling time you enter, the rest stays at your current minutes per request, and the two are added back together with the rework minutes unchanged. The difference between the scenarios is the saving. The full time equivalent figure divides the weekly hours returned by a 40 hour staffing week, which is stated rather than hidden because a different assumption there changes the headline.
Where the defaults come from
Two of them are anchored to a published figure and the rest are placeholders. State them as such if you take this anywhere.
Minutes per authorization, default 20. An American Medical Association survey of 1,000 physicians conducted in late 2024 found that practices complete an average of 39 prior authorization requests per physician per week, and that physicians and their staff spend an average of 13 hours a week completing them. Thirteen hours across 39 requests is almost exactly 20 minutes each. That is a national average across specialties and payer mixes, and yours will differ, but it is a defensible starting point rather than an invented one.
Requests per week, default 150. On the same survey figure of 39 requests per physician per week, 150 is roughly a four physician practice. Scale it to your own clinician count or, better, take the real number from your practice management system.
Everything else is a placeholder. The hourly cost, the share denied or returned, the minutes per rework, the coverage share and the minutes on a covered request are starting values chosen to make the calculator usable on first load. None of them is a benchmark. Replace all five before showing anyone the output.
What it refuses to assume
That automation lowers your denial rate. Rework volume is held constant across both scenarios. Faster and more consistent submissions plausibly reduce denials, but the size of that effect depends on your payer mix and the reason codes involved, and building a guess into the maths would inflate every answer this tool gives. If you have measured the effect in your own data, model it by lowering the denial rate input directly and watch both scenarios move together.
That the covered share needs no people. The minutes on a covered request default to a non zero figure on purpose. An agent that submits without review is not a workflow we would sign off, and a model that assumes one is modelling a system you should not buy. The prior authorization use case page sets out where the human checkpoints belong.
What it leaves out
Software cost, implementation, integration work and the internal owner's time are all real and none of them are in here. Compare the annual figure against a vendor quote plus your own implementation estimate, not against zero. The vendor selection page covers how to build a total cost of ownership figure that survives finance review.
It also excludes the clinical cost of delay. Time to decision is usually the reason a health system takes this work on at all, and it does not appear in a labour model. That absence is a limitation of the model, not evidence that the effect is small.
Finally, it models today's process. The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) phases in payer requirements including prior authorization APIs, which will change the electronic path available to you and therefore the coverage share that is realistic. The rule page sets out the dates. Re-run this model once you know what your major payers actually support.
Questions we get asked
How many minutes does a prior authorization actually take?
The default here is 20 minutes, derived from an American Medical Association survey of 1,000 physicians in late 2024 that found 39 requests per physician per week taking 13 hours of physician and staff time. That is a national average across specialties, so treat it as a starting point. Your own figure will depend on your payer mix and how much of your volume runs through portals rather than fax and phone.
Why does the model not reduce denials when automation is switched on?
Because we cannot know by how much, and a number invented at this point compounds through every other figure on the page. Consistency and completeness at submission plausibly help, but the size depends on your payers and their reason codes. Hold it constant, get a defensible labour figure, and treat any denial reduction as upside you have to prove separately.
What coverage percentage is realistic?
It depends on how many of your payers and procedures have a workable electronic path, which is a question about your payer mix rather than about the technology. Start by counting the share of your volume running through payers with a documented electronic prior authorization route, then run the model again at half of it. First deployments rarely cover everything the first survey suggested.
Should returned hours be counted as a saving?
Only if the role is genuinely rescoped or a position is not backfilled. Otherwise the hours are capacity, which is worth having and is often the real goal, but it is not a budget line and presenting it as one loses credibility at the first review. The full time equivalent figure in the results exists to make that conversation concrete.
Does this include the cost of delay to patients?
No. This is a labour model. Time to decision is frequently the reason an organization takes prior authorization work on at all, and it does not appear here. Treat the dollar figure as a floor on the value of the work rather than as its full extent.
Will the CMS prior authorization rule change these numbers?
It should change the coverage share, which is the input with the most leverage. The final rule phases in payer obligations including prior authorization APIs, so more of your volume becomes electronically reachable over time. It does not change your minutes per request on the payers that are not in scope, so re-run the model when you know what your own major payers support rather than assuming a step change.
Can I use this in a business case?
Yes, provided the inputs travel with it. A range with visible assumptions survives scrutiny; a single number does not, and the first question in the room will be where it came from. Print this page and the assumptions print with it.
Find out what an agent could safely do today
The readiness assessment scores your data, systems, staffing and governance against what agents actually require, and tells you which use cases are reachable this year.
Book an evaluation call at any point. No obligation.