ABA practice management software built around authorizations

Why the authorization drives everything else

An authorization grants a number of 15-minute units of a specific CPT code, to a specific client, over a date range. Everything downstream, what can be scheduled, who may deliver it, what can be billed, is a consequence of that grant.

Take a simple illustration. An authorization grants 1,040 units of a technician-delivered code over six months, 40 units a week. By week ten, the schedule shows 400 units booked to date but the session log shows 352 delivered: cancellations ate 48 units nobody is tracking. Left alone, the period ends with delivery well under the authorized amount, and the shortfall becomes the payer’s argument at re-authorization. The burn-down exists so that gap is visible in week ten, when there is still calendar left to close it, not in a month-end report after the period is spent. (The numbers here are arithmetic, not clinical guidance; what utilization is appropriate for a given client is a clinical decision.)

Both directions are penalized

Over-delivery is unbillable work already paid for. Under-delivery is read by payers as evidence that fewer hours are needed, and future authorizations are cut accordingly. The industry answer is a utilization dashboard with alerts as the balance burns down, plus a scheduled-versus-authorized-versus-delivered reconciliation, surfaced at the moment of booking rather than in a monthly report.

What this ABA practice management software does

The supervision arithmetic is public rather than a feature: the free ABA supervision calculator computes the BACB 5% requirement from an RBT’s direct hours, with the projected shortfall, no signup. What the product adds is the tracking that makes the number arrive before month-end instead of after it.

How payer rules are configured

Almost nothing about ABA billing is universal. Concurrent supervision billing is permitted by some payers and banned by others, credential-tier modifiers differ by payer and by state program, place-of-service acceptance for school-based sessions varies, and telehealth eligibility differs by code.

None of it is hard-coded. Each is a per-payer setting, because a system that encodes one payer’s rules as universal quietly generates denials for every other payer.

How those settings turn a delivered session into a billable charge — units, modifiers, which NPI is reported for technician-delivered service, and what your biller receives — is the subject of ABA billing software, which covers it properly rather than in summary.

ABA software compared: CentralReach, Motivity and Raven Health

One row runs the other way. Raven Health documents full offline data collection. Capture here survives connection loss within a working day whose roster loaded online, which is a narrower capability, and agencies whose technicians start the day without connectivity should weigh that difference.

Each of those three gets more room than a table row allows. Motivity alternative covers where per-learner pricing stops being the cheaper answer as a caseload grows, CentralReach alternative covers what quote-only pricing costs a buyer trying to budget, and Raven Health alternative covers the managed-billing trade. An agency that has already decided wants the migration guides instead — from Motivity, from CentralReach, from Raven — because the question stops being which vendor and starts being what survives the move. The answer is rarely the client list, which any system exports; it is the program and goal library, which is the thing an agency cannot re-enter from memory.

What to test in the first half-hour

The trial is built around one loop: create a client with an authorization, import or build a program, run a mock session on a phone, watch the graph draw with a phase line, and check that the authorization balance decrements. Running that sequence once tells you more about whether MegAligna fits your caseload than a feature list will.