.webp){kind=small}
I talk to ABA practice leaders every week. Owners, operators, clinical directors, and billing coordinators. Their organizations range from a handful of BCBAs® to multi-state operations with hundreds of staff. And one of the things I hear over and over, regardless of size, is some version of “We bought the software. We did the implementation. We trained the team. And billing is still a mess.”
These practices have invested in clinical platforms, scheduling tools, and billing systems. The technology is there. So why does the billing team still spend half their week reconciling data between systems that should already agree? Why are BCBAs still getting pulled into billing questions that feel like they shouldn't need clinical input?
The answer, in my experience, has less to do with the specific tools a practice uses and more to do with what happens to data as it move between them.
The assembly line behind every ABA claim
Think about what goes into getting a single claim out the door.
A session happens. The RBT® documents it, and a supervisor reviews the note. Then someone on the billing side pulls data from the clinical system, cross-references the schedule to verify times, checks the authorization to confirm the service is covered, makes sure the modifier reflects who delivered the session and the appropriate place of service, and submits. If there's a credentialing requirement tied to that provider and payer, that gets checked too.
Each of those steps might involve a different screen, a different login, or a different system entirely. And at every handoff, a person is responsible for making sure the data from one place matches the data in another.
Now consider the volume. According to Breaking News ABA's analysis of the RCM industry, a single ABA client receiving 25 hours of weekly therapy generates over 5,000 billable units per year. No other outpatient behavioral health specialty comes close to that volume per patient, and no other specialty demands the same density of real-time authorization tracking.
Multiply that across a full caseload of 20, 30, or 50 clients, and you're talking about thousands of individual data points your team has to reconcile (manually) every billing cycle.
A billing coordinator who spends her afternoon checking session times against the schedule is doing what the workflow demands. The question is why the workflow demands it at all.
When denial rates trend up, billing cycles keep stretching, or good admins are always flooded with work, the instinct is to look at the people or the payer. Rarely does anyone stop to examine the architecture that's forcing all of this manual assembly in the first place.
There's a difference between faster billing and billing that builds itself
Here's what I see in a lot of the ABA software market right now. A practice had a manual billing process. A vendor came along and gave that process a screen. The biller who used to work from paper and sticky notes now works from a dashboard with filters and status labels. The work looks different. It might even be faster. But the biller is still the one assembling the claim from the schedule, the authorization, and the notes, all from separate places.
The billing software made each individual step easier. It did not change the fact that a human being is still the connective tissue holding the whole chain together.
There's another way to design this. If clinical data, scheduling, authorizations, and billing all share the same underlying data from the start, the claim doesn't need to be assembled. It generates from the work that already happened. The authorization was validated when the session was scheduled. The session was documented, with the time recorded. The modifier was determined by the provider's credentials, place of service, and the service type. The claim is the natural output.
That's a fundamentally different experience for the billing team. Their job shifts from building claims to reviewing exceptions. They're looking at the handful of cases where something didn't line up, instead of manually verifying hundreds of claims.
And it changes what happens upstream, too. When the clinician submits a session note, billing-required fields are part of the note itself, not something that gets checked separately later. When the scheduler places a session, the authorization limits are already visible. The work that prevents billing problems happens while care is being delivered.
When practices tell me they want to automate their billing, what they usually mean is they want the manual steps to move faster. That's a reasonable ask. But speed applied to a fragmented workflow just gets you to the same misalignments sooner. If the data underneath aren't connected, the reconciliation work doesn't go away.
📌 Also read: Are Your RBT®s’ Notes Tied to Billing, or Costing You Time and Money?
How the claim builds itself when the data are already connected
The thing to ask of any system you're evaluating is whether the underlying data are shared, or whether it's just a better interface for the same manual work.
We designed Motivity to be different. I say “designed” deliberately, because it isn't a feature that got bolted on. The reason a claim can auto-generate inside Motivity is that the platform was built so that clinical documentation, scheduling, authorizations, and billing share the same data layer. The claim doesn't pull from four separate sources. It reads from one.
The claim follows the care
Motivity session notes can be configured so that when an RBT completes a session, the service type, start and end time, and billing-required fields are automatically included. Those fields can also be made required, helping ensure that critical billing information is captured as part of the note-completion process rather than relying on a biller to identify missing information later.
From there, organizations can build a robust QA workflow around each note, incorporating clinical and operational review as needed. If something appears incomplete or incorrect, the note can be routed back to the RBT for correction. Once the note has made it through that QA process and is signed and approved, the billing workflow picks up from there.
The appointment is then marked complete or rendered, and the claim builds from the connected information already in Motivity, including session data, authorization details, provider credentials, and payer rules. Instead of piecing that information together across different systems, the billing team starts with a claim built from one connected workflow.
Jenny Saavedra, BCBA and owner of ABA Spectrum Therapy, ran clinical on one system and practice management on another before moving to Motivity. Her team used to meet with their billing team every week just to stay on top of it. Now they meet once a month.
”I am more knowledgeable about what is happening with our billing without having to dig, pull reports, ask five different people, send emails.”
A generated claim still needs someone following it
Connected data solve the assembly problem. They don't solve everything that happens after the claim leaves your system.
When things like a payer's rules change, or a modifier that cleared in January gets flagged in March, claims sit in a queue and nobody notices until the filing deadline is uncomfortably close. That work is continuous, and it needs someone whose actual job is watching it. In most practices, that person is also covering scheduling, credentialing questions, and whatever came up that morning.
Some practices have a dedicated biller who can stay on top of it. Others bring in an outside billing company that works from their own system and reports back in spreadsheets. Motivity's RCM services include a team of billing specialists who work inside your Motivity instance, on your data, following claims through submission, denial follow-up, and payment posting.
Bethany Oliver Craig, who owns North Georgia Autism Center, put it plainly when she described what that meant for her:
“Motivity continuing to follow up on claims on almost a weekly basis has meant a lot to me because I don't really have the bandwidth to do that.”
Her collections rate went up 65% in Q1 2026, and her cash flow has been the most consistent since she opened her practice in 2019.
📌 Also read: When session notes aren't connected to billing, admins pay the price.
Start trusting your claims
If your practice has invested in tools and billing still feels like a second full-time job for someone on your team, it's worth asking whether your systems are sharing data or just sitting next to each other, and who actually has the bandwidth to follow the claims once they're out.
That one question tends to clarify a lot. And if you want to see how Motivity answers it, let's talk.
Frequently asked questions
What causes claim denials in ABA practices?
Many ABA claim denials trace back to data misalignment between clinical documentation, scheduling, and authorization systems. A session time that doesn't match the schedule, a modifier that doesn't correspond to the authorization, or a note missing a billing-required field can all trigger a denial. The root cause is often that these data points live in separate systems and someone has to manually verify they match for every single claim.
How is ABA claims processing different from other healthcare specialties?
ABA billing is structurally more complex than comparable behavioral health specialties. A single client can generate over 5,000 billable units per year, with multiple service codes billed concurrently, payer-specific unit limits, supervision ratio rules, and authorization requirements that vary by payer and plan type. That volume and complexity mean that even small misalignments between systems compound into significant manual work and revenue risk.
For more on this, read: Why ABA billing gets harder when you treat it like general healthcare
Why does my ABA practice still have billing problems after buying new software?
Software that digitizes billing steps without connecting the underlying data doesn't remove the manual assembly work. If your clinical platform, scheduling tool, and billing system each hold their own version of the data, someone still has to reconcile them for every claim. The billing problems persist because the architecture hasn't changed, even though the tools have.
