CentralReach vs. Custom ABA Software: When Your Practice Has Outgrown Off-the-Shelf

CentralReach is the dominant EHR in the ABA market for good reason. It covers data collection, billing, scheduling, and credentialing in one platform, it's HIPAA-compliant, and it has a large support ecosystem. For the majority of ABA practices, it's the right choice. But there's a specific set of scenarios where it stops being the right choice — and when practices hit those scenarios, they usually don't realize it until they've already built a year's worth of workarounds.

I'm a BCBA who builds custom software for ABA practices. I've worked inside agencies running CentralReach, and I've built tools for practices that outgrew it. This comparison isn't a takedown — CentralReach is genuinely good at what it does. It's a map of where its edges are, so you can recognize when you've reached them.

---

What CentralReach Does Well

Before the limitations, the strengths — because a fair comparison starts here.

HIPAA-compliant data collection and session notes

CentralReach's core data collection toolset is purpose-built for ABA. Discrete trial, interval recording, task analysis, ABC data — it handles the primary measurement systems BCBAs use without requiring customization. The data lives in a HIPAA-compliant environment and the audit trail is built in. For practices that don't need to deviate from standard measurement protocols, this is a significant operational advantage.

Integrated billing and authorization management

The billing module handles claims submission, ERA/EOB processing, and authorization tracking in a single environment. For practices billing Medicaid and commercial insurance, having data collection and billing in the same system reduces the risk of billing errors caused by mismatched session data. It's not perfect, but it's substantially better than the alternative of bridging two separate systems manually.

Scheduling and credentialing

CentralReach's scheduling covers client appointments, staff availability, and credentialing deadlines in one place. For a practice with 20–50 active clients and a mixed staff of BCBAs, BCaBAs, and RBTs, this is a real workflow benefit. Credential expiration alerts and supervision hour tracking are built in at a basic level.

A large vendor ecosystem

CentralReach has been in the market long enough that most consultants, billing services, and ABA-adjacent tools know how to work with it. That ecosystem has value — it's easier to hire a billing specialist who knows CentralReach than one who knows your custom system.

---

The Five Scenarios Where Practices Outgrow CentralReach

Scenario 1: Multi-State Operations with Varying Compliance Requirements

CentralReach is built to a general HIPAA standard. When you're operating in multiple states, you're not just dealing with federal HIPAA — you're dealing with state-specific Medicaid billing rules, state licensing board requirements, and sometimes state-specific data retention policies that differ from federal minimums.

A California-based BCBA supervising a case in Florida faces different credentialing documentation requirements than one supervising within a single state. A practice with centers in Texas, Colorado, and Virginia has different Medicaid billing requirements in each state. CentralReach doesn't natively manage state-by-state compliance variations — it requires manual configuration and workarounds that accumulate technical debt over time.

If you're operating in more than two states, or planning to expand, the compliance management layer above CentralReach often needs to be custom-built.

Scenario 2: Unique Clinical Protocols That Don't Map to Standard Data Collection

CentralReach's data collection framework covers the standard ABA measurement systems well. What it doesn't do well is accommodate clinical programs that deviate meaningfully from those standards — custom behavior measurement tools, proprietary protocol variations, or research-grade data collection requirements.

If your agency has developed a proprietary protocol for a specific population (early intensive intervention approaches, verbal behavior programs with non-standard probe structures, or hybrid behavioral/educational models), you've probably already experienced the CentralReach workaround: creating a series of generic data sheets that approximate your measurement tool without actually capturing what your clinical team needs to see.

Workarounds compound. A year of data collected in a non-native format is a year of data you can't analyze cleanly.

Scenario 3: Research Collaborations or Grant-Funded Programs

ABA agencies partnering with universities, submitting outcome data to research collaborators, or operating grant-funded programs face data export and sharing requirements that CentralReach wasn't designed for. IRB-approved research protocols have specific data structure requirements. Grant reporting formats don't match the built-in CentralReach export schema. University partners need data in formats that require significant manual reformatting from CentralReach exports.

If your practice is doing any research-adjacent work — even informally — you're probably spending more time reformatting data exports than you should be.

Scenario 4: Caregiver Portal Requirements Beyond Basic Communication

CentralReach has a caregiver portal, but it's limited to what CentralReach built for it. Practices that need caregivers to actively engage with programming — viewing data graphs, completing caregiver training modules, submitting behavior logs from home, or accessing session recordings — routinely find that the native portal doesn't cover the use case.

The workaround is a patchwork of third-party tools: a video platform for parent training, a separate data-sharing tool for home behavior logs, a HIPAA-compliant messaging tool for daily communication. Every additional tool is another BAA to manage, another login for caregivers to forget, and another integration gap where data falls through.

A custom caregiver portal built on a HIPAA-compliant infrastructure that integrates with CentralReach data can collapse all of this into a single interface. It's not cheap — but when you calculate the staff time spent managing the patchwork, it often pays for itself within two years.

Scenario 5: Billing Workflow Automation Beyond What CentralReach Supports Natively

CentralReach's billing module handles the core claims workflow. What it doesn't do natively is automate the adjacent workflows that consume billing staff time: authorization renewal alerts sent to the right person at the right time, prior authorization submission triggered automatically when an authorization is within 30 days of expiry, Medicaid eligibility verification run automatically before each session, or insurance verification results feeding back into the scheduling system to flag sessions that shouldn't be billed.

These workflows exist in the gap between CentralReach and your billing team's manual process. Filling that gap with a no-code HIPAA-compliant automation tool like Keragon — or with a custom integration layer — can reduce billing staff administrative time by 30–50% for a mid-size practice, without replacing CentralReach as the system of record.

---

Build vs. Buy: The Decision Framework

Custom software is not the right answer for most ABA practices, most of the time. Here's the honest framework for deciding which path makes sense:

Stay with CentralReach (or an off-the-shelf EHR) if:

• Your clinical protocols match standard ABA measurement systems
• You're operating in one or two states with straightforward Medicaid billing
• Your caregiver communication needs are covered by a HIPAA-compliant messaging add-on
• You have fewer than 50 active clients and a team of under 20
• Your billing team can manage the authorization workflow manually without significant time cost

Consider a targeted custom layer if:

• You have one or two specific workflows that CentralReach handles poorly and that consume meaningful staff time
• You need a caregiver-facing interface that the native portal doesn't cover
• You need to automate billing-adjacent workflows (authorization alerts, eligibility checks, prior auth submission)
• You have supervision tracking requirements that exceed the native CentralReach module

Consider a full custom build if:

• You're operating in multiple states with divergent compliance requirements
• You have a proprietary clinical protocol that requires a custom measurement framework
• You're doing research-grade data collection that requires specific export formats
• The cumulative cost of your patchwork of tools and manual workarounds exceeds the cost of a unified system

---

What "Custom ABA Software" Actually Means in Practice

The phrase "custom software" often triggers the mental image of a two-year, six-figure project that ends up over budget and under-delivered. That's a real risk with the wrong partner — but it's not inherent to custom development.

For most ABA practices considering custom software, the scope is narrower than they expect: a targeted integration layer that fills a specific gap, not a full EHR replacement. The three most common scopes we work on:

• A custom caregiver portal that reads data from CentralReach via API and presents it in a parent-friendly interface, with HIPAA-compliant messaging built in. Typical build: 6–10 weeks, built around your specific program structure.
• A Keragon-based billing automation layer that automates authorization alerts, eligibility verification, and prior auth submission workflows. Typical setup: 2–4 weeks, built on Keragon's HIPAA-compliant no-code infrastructure with custom configuration for your payer mix.
• A supervision tracking dashboard that tracks BCBA/BCaBA/RBT supervision hours against BACB ratio requirements, with automated alerts when ratios are approaching limits. Typical build: 4–6 weeks, designed around your supervision model and credentialing requirements.

None of these replace CentralReach. They extend it — filling the specific gaps where it falls short for your practice's particular situation.

---

What to Look for in a Custom ABA Software Partner

Not every development shop can build effectively for ABA. The clinical domain is specific enough that a partner who doesn't understand the BACB requirements, the CentralReach data model, or the Medicaid billing landscape will cost you more in discovery and correction time than a domain-fluent partner who starts on solid footing.

Questions worth asking any developer you're evaluating for ABA software work:

• Do you have a BAA template ready to execute? (If they don't know what a BAA is, stop there.)
• Have you worked with CentralReach's API before? What integrations have you built on it?
• How do you handle PHI in your development and testing environments?
• Do you have experience with Medicaid billing workflows specifically, or just general healthcare billing?
• Can you describe the BACB's supervision ratio requirements for RBTs?

That last question is revealing. A developer who can answer it without looking it up has done ABA work before. One who can't will spend your engagement budget learning what you already know.

At Auth Software, our founder is a BCBA. We sign BAAs on day one, we know the CentralReach data model, and we've built the specific workflow types described in this article. If you're evaluating whether custom software is the right move for your practice, a free discovery call will usually tell you within 30 minutes whether you need us or whether CentralReach configuration will solve your problem.

If you want to understand the HIPAA compliance side before thinking about custom development, the BCBA's guide to HIPAA-compliant ABA practice management covers the compliance layer in detail. And if you're curious about what AI-driven automation looks like in a healthcare context more broadly, our HIPAA-compliant AI automation overview has the full picture.