Authorization to Claim: The ABA Revenue Cycle Explained

Ask an ABA billing manager where revenue leaks and they will rarely blame the payer. They will point to the gap between the authorization letter and the claim form — the weeks in which sessions get scheduled by one system, delivered according to another, documented in a third, and billed from a spreadsheet that reconciles none of them.

This article explains the ABA authorization to claim workflow as a chain of linked records. It is the revenue path TargetFlo's architecture is built around, and understanding it will help you evaluate any billing or scheduling tool, including ours.

What is the ABA revenue cycle?

The ABA revenue cycle is the sequence of operational and clinical events between a payer approving treatment and the center receiving payment. In ABA it has five linked steps: an Authorization (approved units per CPT code for a date range), a ScheduleBooking (a recurring slot that allocates those units), a SessionInstance (one calendar occurrence of that booking), a SessionNote (the clinical documentation for that occurrence), and a Claim (billable units multiplied by contracted rate). Each step depends on the one before it. When the links are explicit, unbillable sessions become nearly impossible; when they are implicit, they become routine.

The five-step chain

Step 1: Authorization defines the ceiling

Everything begins with the payer's approval. A typical letter authorizes something like 480 units of 97153, 64 units of 97155, and 32 units of 97156 for a six-month period. Those numbers are not targets — they are ceilings.

Before the authorization exists, the family has already passed through eligibility verification and the intake pipeline. TargetFlo's Insurance and Eligibility module runs real-time 270/271 checks and tracks the authorization sub-stages (physician verification, submitted, pending, authorized) inside the Pending Authorization stage. That record — units per code, dates, payer — is the anchor for everything downstream. For the code-by-code breakdown, see CPT Codes for ABA Therapy Explained.

Step 2: ScheduleBooking allocates the units

A schedule booking is a recurring commitment: Tuesdays and Thursdays, 3:00 to 5:00 PM, client A with technician B, code 97153. In a connected system, creating that booking does two things at once. It places sessions on the calendar and it forecasts unit consumption against the authorization.

That forecast is the single most valuable calculation in the revenue cycle. If the booking consumes 16 units a week and the authorization has 480 units over 26 weeks, the center will run out in week 30 — fine. If it consumes 24 units a week, the authorization runs dry in week 20 and the last six weeks are unbillable unless someone requests more units in time. Scheduling software that cannot see the authorization cannot warn you. We go deeper on this in Why Scheduling Must Connect to Authorizations in ABA.

Step 3: SessionInstance records what actually happened

A booking is a plan; a session instance is reality. Sessions get cancelled, shortened, extended, or covered by a different technician. Each instance should carry the actual start time, end time, rendering provider, and status (completed, cancelled by family, cancelled by staff, no-show).

Session instances are where units are truly consumed. A booking of eight units that ends 30 minutes early consumed six. Bill what was delivered, not what was planned.

Step 4: SessionNote documents the service

The note is the clinical evidence behind every billed unit. Payers expect it to be completed and signed by the rendering provider within a defined window, to reference the treatment goals in the Plan of Care, and to match the times on the session instance.

Disconnected systems make mismatches inevitable: the scheduler says 3:00 to 5:00, the note says 3:10 to 4:55, and the claim says eight units. Connected systems generate the note from the instance so that times and codes are consistent by construction. Session notes are on the TargetFlo roadmap for exactly this reason.

Step 5: Claim converts units to revenue

Finally, the claim aggregates delivered units per code per date of service, applies the contracted rate and any required modifiers, and submits to the payer or clearinghouse. In a well-linked system a claim is a projection of records that already exist rather than a fresh data-entry task.

The payoff is visible in denial rates. Most ABA denials trace to a broken link upstream: units beyond the ceiling, a lapsed authorization, a missing note, a provider modifier that does not match the credential on file. Fix the chain and the claim largely takes care of itself.

Where the cycle usually breaks

• Authorization tracked in email. Nobody knows the true remaining balance.
• Scheduling in a generic calendar. Bookings are created with no reference to units.
• Notes in a separate documentation tool. Times and codes drift from the schedule.
• Claims built from spreadsheets. Manual re-entry introduces errors and delay.
• Eligibility never re-checked. Coverage terminates mid-authorization and the last month of sessions denies.

Each break is a handoff between tools that do not share a record. The remedy is not more diligence; it is a shared data model.

How TargetFlo models the revenue path

TargetFlo's architecture is designed around the five-record chain described above. Today, the front half is live: the intake pipeline carries the family through eligibility and the authorization sub-stages, and the client record holds insurance context, documents, and the signed Plan of Care. The back half — scheduling with authorization-aware bookings, session instances, session notes, and claims submission — is on the roadmap and described on the Billing and Claims and Scheduling pages.

We are deliberate about that sequencing. Claims are only as clean as the authorization and session data beneath them, so the data model came first. Centers adopting TargetFlo now for intake, fax, and eligibility are building the foundation the revenue cycle will run on.

Questions to ask any ABA billing vendor

1. Can a schedule booking see the remaining units on the authorization it draws from?
2. Does a session note inherit times and codes from the session instance, or are they re-typed?
3. When an authorization is about to run out, who gets alerted and how early?
4. Are eligibility checks repeatable after intake, not just at intake?
5. Can I trace one claim line back to its note, session, booking, and authorization without leaving the system?

If the answer to any of these is "export and reconcile," the chain is broken and revenue is leaking. The ABA revenue cycle is not complicated — it is five records that must stay linked. Choose systems, and processes, that keep them that way.