The three authorization errors that survive every audit
An approved authorization is a document that says yes.
It is not a document that says yes to what you asked for. Those are different, and the difference is invisible unless somebody reads the approval against the request, which almost nobody does, because it says APPROVED at the top and there are eleven other things to do that morning.
Error one: the wrong code
You requested 97155 for protocol modification. The approval came back for 97153.
Both are real codes. Both are approved. The document looks correct in every way. And every hour of protocol modification you deliver against it is going to bill against a direct-treatment authorization, which either denies on code mismatch or pays at the wrong rate, depending on how the payer adjudicates.
This happens most often when the request covers several codes and the approval consolidates them, or when a payer’s system maps your request to its own internal service category and prints that instead.
The tell is a unit count that does not match the request. If you asked for 480 units of 97153 and 96 of 97155 and the approval says 576 units of 97153, the codes have been merged and you have a problem that will not surface for three months.
Error two: the wrong span
You requested 1 October to 31 March. The approval reads 1 November to 30 April.
Same six months. Different six months. Everything delivered in October has no authorization, and there is a month of units sitting at the end that you will not use because the client’s next authorization will already have started.
Payers shift spans for ordinary reasons — plan year boundaries, processing dates, an eligibility gap you did not know about. The shift is not an error on their side. It is only an error on yours if you do not notice it.
The tell is that nobody ever reads the dates. The approval is filed, the units are entered, and the span is assumed to be what was requested.
Error three: the wrong units per week
This is the subtle one.
You requested 20 hours a week for 26 weeks, which is 2,080 units of 97153. The approval says 2,080 units — and then adds, somewhere in the body, a limit of 15 hours per week.
The total is right. The weekly cap is not. Your schedule is built for 20, your staffing is built for 20, and every week you deliver 20 you are billing five hours that will deny against the weekly limit.
Worse, the denial reason will read as a unit limit rather than a schedule problem, so it gets appealed rather than fixed, and it keeps happening while the appeal is pending.
Weekly and daily caps live in the fine print of the approval, not in the summary line that gets entered into the system. The field for “units authorized” holds the total. There is often no field at all for the cap.
What the three have in common
Illustrative arithmetic, not a client engagement.
The fourth row is there for contrast. An expired authorization announces itself — the date has passed, anyone looking can see it. The other three do not announce anything. They pass every visual check, get entered correctly against the wrong information, and only surface as a denial two months later, by which time you have delivered another two hundred hours the same way.
The check that catches all three
Read the approval against the request. Side by side, at intake, before the units go into the system.
Four things: does the code match, does the span match, does the total match, and is there a weekly or daily cap anywhere in the document. Two minutes per authorization. One person, at intake, every time.
If a cap exists, it goes into the scheduling system as a hard constraint, not into a note. A cap in a note is a cap nobody enforces.
And if any of the four do not match, that is a phone call now rather than an appeal in March.
Five checks you can run this week
1. Take ten current authorizations and read the approval against the original request. Ten is enough to tell you whether this is a process problem or a one-off.
2. Search your approvals for the words “per week,” “per day,” “maximum” and “not to exceed.” Every hit is a cap. Check each one is in the scheduling system.
3. Compare the span on every active authorization to the span that was requested. Any shift is a window where you have delivered without cover.
4. Pull denials from the last six months coded to unit limits or code mismatch and trace each back to the authorization document. The pattern will name the payer that does this to you.
5. Put the four-point check into the intake checklist. It costs two minutes and it is the only place in this stage where the error is cheap to fix.
The number to actually track
Authorizations where the approval does not match the request on code, span, total or cap — checked at intake, counted monthly.
Pair it with denials coded to unit limits or code mismatch, traced back to the approval document. The pattern will name the payer.
Counting denials alone measures the symptom ten weeks after the cause.
Where this sits
This is the second of eight stages where ABA revenue leaves. Stage 01 is the reservoir — what a client will realistically receive. Authorization burn is what happens when delivery and authorization stop lining up.
These three are the reason a practice can run a careful authorization process and still deliver outside it.
A Leak Map Assessment measures all eight — the reservoir, authorization burn, cancellations, session conversion, conversion to billed, clean claims, rate integrity and recoupments. A claims audit is a different instrument. It starts once a session has been converted and billed, and reconciles the back half of the cycle to cash.
Aimline closes the books, oversees the revenue cycle, and sits in the CFO seat for ABA practices. We run claims audits scoped to a payer book, and Leak Map Assessments that measure the full cycle — three weeks, $7,500 fixed. Either one gives us a verified number to run oversight against, and the report is yours whether or not you engage us to fix what it finds.
