River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

Prior Authorization Tracking Spreadsheet

Two documents and three sheets that check every booked appointment against the authorization meant to cover it, before the patient arrives.

Free download  ·  No account needed

Upcoming Service Cross-check

412 booked visits, checked against five fields each

Six weeks of a fictional practice, Ashgrove Rehabilitation. Generated from the schedule, not from the register, which is why the last row can appear at all.

Status of the booked visitVisitsShareAt riskSeen by an expiry report
Date, units, provider, site and code all match31877.2%
Booked after the valid-through date4110.0%$3,444Yes
Booked past the point the units run out297.0%$2,436No
Rendering provider or site does not match143.4%$1,176No
No authorization on file at all102.4%$840No
At risk in total9422.8%$7,89641 of 94

The other direction is worse. Eighty-seven authorizations expire inside this window and only 23 of them have any visit booked after the expiry, so a report sorted by expiry date asks the practice to chase 64 courses that have already finished.

Remaining columns: Days Away, Auth Valid From, Auth Valid Through, Date In Range, Cumulative Units At This Visit, Units Authorised, Failed Field, Request By, Owner Group, Action, Resolved On.

Every prior authorization tracking spreadsheet on page one is the same object: one row per request, a status column, an expiry date, and conditional formatting that turns the row amber thirty days out. It is a register, and a register cannot show you a problem. Every problem in this area is a collision between an authorization and an appointment, and the register holds only one of the two.

This pack takes both. Every booked visit in the forward window is checked against the authorization meant to cover it on five fields at once. Those five are the date against the valid range, the running unit count including everything booked ahead of it, the rendering provider, the site of service, and the code. A visit fails on any one. Working from the schedule rather than the register is what makes the last category visible at all, because a visit with no authorization has no row to appear on.

Ashgrove Rehabilitation ran it across 412 booked visits and found 94 at risk, worth $7,896 in six weeks. Only 41 of those were visits booked past an expiry date, which is all a register-keyed report can see. The other 53 were units running out on authorizations valid until December, providers and sites that did not match, and visits with nothing on file. Meanwhile 87 authorizations expired inside the window and 64 of them had nothing booked after the expiry.

Every document in the pack

The row no expiry report shows, the date that is earlier than the expiry, and the column that measures the process rather than the week.

The row an expiry report will not show for another ten weeks

Authorization AU-4471. Nothing about it is expiring. Everything about it is about to fail.

Units authorised24 visitsValid through20 December 2026
Rendered to date17Remaining7
Booked before the expiry1217 plus 12 against 24five visits over
Booked visitDateCumulative unitsStatus
6 of 124 October 202623 of 24Covered
7 of 126 October 202624 of 24Covered, last one
8 of 1211 October 202625 of 24Units exhausted
9 of 1215 October 202626 of 24Units exhausted
10 to 12to 25 October 202627 to 29Units exhausted

What each system sees

SourceWhat it says todayWhen it first flags this row
Units used field in the billing system17 of 24, comfortableNever
A 30-day expiry reportNothing, expiry is 97 days out20 November, 40 days after the units are gone
The cross-checkUnits run out on visit 8, 11 OctoberToday

Seventeen of twenty-four looks comfortable because it is a number from the past. Twelve more visits are already booked, and nothing in a billing system counts a booking. The authorization has ninety-seven days left on it and five of its booked visits are uncovered.

This is the group that produces the calls a scheduler cannot answer, because by the time anyone notices, the visits have happened.

The date you actually work to

Request-by, not expiry

The expiry is a fact about the authorization. The request-by date is a fact about the practice, and it is the only one anybody can act on. It is the first uncovered visit, less the payer's decision timeframe, less this practice's own median days from flagged to submitted, less a buffer.

ComponentDaysWhere it comes from
Payer decision, standard7Published, Medicare Advantage, from 1 January 2026
Payer extension, up to14Applied where this payer has taken one before
Flagged to submitted6Ashgrove's own median across 31 cases
Buffer3Set once, applied everywhere
RowFirst uncovered visitLead usedRequest byStatus today
AU-4471, units11 October3011 September3 days late
AU-4471, if this payer had not extended11 October1625 September11 days out
AU-4508, expiry5 October1619 September5 days out

AU-4471 is three days late on a date nothing in the practice computes, against an authorization that does not expire until December. AU-4508 is the ordinary case: valid through 28 September, a visit booked 5 October, seven days past it, and eleven working days to fix.

Two lead times per payer, always. The published figure and what that payer has actually taken. Plan on the second and say that you did.

Lapse Log

The column that measures the process instead of the week

A lapse log that counts lapses is not much use, because the count falls for good reasons and bad ones. Two columns make it useful, and only one of them is obvious.

VisitFailed fieldDiscoveredKnowableGapWhat would have caught it
14 AugUnits exhausted3 Oct2 Jun123 dThe cross-check running at all
27 AugPast valid-through19 Sep11 Jul70 dThe cross-check running at all
2 SepSite mismatch25 Sep2 Sep23 dA register field that was empty
9 SepNo authorization1 Oct21 Aug41 dNothing available to this practice

Knowable is not discovered. It is the earliest date the information needed to catch it existed anywhere in the practice. On a unit exhaustion that is the day the visit consuming the last unit was booked, which is routinely months before anybody notices. The median gap between the two is the number that only improves when the process does.

Nothing available to this practice stays on the list. Remove it and every lapse gets attributed to a preventable cause, which makes the log fiction and makes the prevention work chase things that were never in reach.

No names in this log, ever. A log that is unsafe to fill in stops being filled in, and then the pattern read is built on the lapses nobody minded admitting.

What's in the pack

01

Upcoming Service Cross-check

One row per booked visit, generated from the schedule, with the field that failed and the group that owns the fix. Date and unit failures go to authorizations, mismatches to scheduling, and missing files to intake, where the referral tracking pack gates them before anything is booked.

02

Authorization Register

One row per authorization with the five checkable fields plus units booked ahead, which is the column that turns a number from the past into something that can answer a question about next Tuesday.

03

Request-by dates, computed per payer

The first uncovered visit less the payer's decision timeframe, less the practice's own median from flagged to submitted, less a buffer. Standard Medicare Advantage determinations run to seven calendar days from 1 January 2026, extendable by fourteen.

04

Lapse Log

Records when each lapse became knowable rather than when it was discovered, and keeps 'nothing available to this practice' on the list of causes. Reading denials back the other way is the denial to authorization feedback loop.

05

Tracking Procedure

One page: the two inputs, the window, the run cadence, and which of the three owners each failure mode routes to. Short enough that somebody reads it.

06

Escalation Note

Raised when a booked visit has no realistic route to coverage, so the practice and the patient decide in advance rather than finding out from a remittance. The clinical half is a medical necessity letter.

07

The approval you already hold

A Medicare Advantage organization that approved a service through prior authorization may not later deny it for lack of medical necessity, absent good cause or fraud. Where a continuation genuinely needs new criteria, the payer policy criteria summary builds that checklist.

08

Authorization Expiry and Schedule Watch

A weekly re-run that leads with request-by dates already passed, then the units running out on authorizations nothing else is watching.

How to use it

  1. 1

    Open in River, or download it

    Open the pack in River and let the agent build the register and run the cross check, or download the blank Word and CSV files instantly and work through them yourself.

  2. 2

    Send both inputs, not one

    The active authorizations from the payer portals, and the next six weeks of the schedule. Neither list can show a problem on its own, and the register version of an authorization is often not the payer's.

  3. 3

    Cross every booked visit against five fields

    Date in range, units not exhausted counting everything booked ahead, rendering provider, site of service, code. Start from the schedule so a visit with no authorization still appears.

  4. 4

    Work to the request-by date

    Not the expiry. Computed per payer from what that payer has actually taken rather than what it publishes, and it usually lands several weeks earlier than anybody expects.

Frequently asked questions

Is this template free?

Yes. Download the whole pack as Word documents and CSV sheets with no credit card. "Edit with AI" is a separate, optional path for practices that want the agent to build the register and run the cross-check from their own exports. Other packs are in the template library.

What format are the downloaded files?

Word documents (.docx) for the tracking procedure and the escalation note, and CSV (.csv) for the register, the cross-check and the lapse log, zipped into one file. They open natively in Word, Pages, Google Docs, Excel, Numbers and Sheets.

Why is an expiry column not enough?

Because it only tests one of five fields. It cannot see units running out on an authorization valid for months, a provider or site mismatch, or a visit with no authorization at all. At Ashgrove that was 53 of 94 at-risk visits, and 64 of the 87 expiring authorizations needed no chasing.

How often does the cross-check need to run?

Weekly on a fixed day, plus on demand whenever a block of appointments is booked or moved. A run against last week's schedule reports last week's problems, so both inputs get refreshed every time rather than one of them.

Does an approval already granted protect the visit?

For Medicare Advantage, an approved item or service cannot later be denied for lack of medical necessity except for good cause or reliable evidence of fraud. Whether your approval covers this date, code, provider and site is the question, which is why all five are fields.

What about a patient who changed plans mid-course?

A Medicare Advantage plan must not disrupt or require reauthorization for an active course of treatment for a minimum ninety-day transition period when someone enrolls after starting it. The course start date is a field on the register so this can be shown rather than argued.

What does 'Edit with AI' actually do?

It creates a free River account, installs this exact pack as a private workspace, and opens it ready to read your exports. Getting the authorization approved in the first place is a different job, handled by the prior authorization pack.

Check the schedule, not the register

Download the blank pack as Word and CSV files, or open this exact pack in River and let the agent cross your next six weeks of appointments against your live authorizations.

Edit with AI