Three insurance denials a visit-based system cannot see
Most billing software assumes a visit: one encounter, a code or two, a claim. ABA is a weekly stream of sessions per client against a grant of 15-minute units in the 97151–97158 family, delivered by staff at different credential tiers, under a payer that may or may not let a BCBA bill protocol modification while the RBT they are observing bills direct service.
Three failures follow, and a visit-based system models none of them: units delivered past what was authorized; a modifier that matches the delivering person but not the tier that payer recognises; and a technician’s NPI reported where the payer wanted the supervising BCBA’s. Each is a clean denial, and each surfaces only after submission. Billing software for ABA providers has to model all three before the charge reaches your biller.
One session record, three outputs
The charge is computed from the session itself (the code booked, the delivering staff member’s credential, the start and stop times already captured for the note) not typed separately by whoever bills. Units are the session minutes divided by the payer’s unit length, rounded down to whole units unless you choose otherwise, because rounding up bills time that was not delivered.
The same record decrements the authorization. So the burn-down on the parent page, the note, and the line on the export are three views of one fact. When a payer asks for the documentation behind a billed unit, it is the record the unit was computed from.
What lives on each payer record
Each payer carries its own answers: which modifier each credential tier gets (HM, HN, HO and HP for some payers, U-modifiers or nothing for others), whether the rendering or supervising provider is reported on technician-delivered sessions, whether concurrent supervision billing is allowed, the telehealth modifier, and rates per code and modifier. A setting left blank produces no modifier rather than a guessed one, and the settings screen previews the resulting line before you save.
No table of “what payer X allows” is published here: those policies change, and each agency confirms them against its own contracts. The software turns a confirmed rule into a setting rather than knowledge held by one biller.
The CSV, and what stays with your biller
Finished lines leave as a CSV with the authorization number, code, up to four modifiers, units, place of service, diagnosis pointers, and the rendering and supervising providers with their NPIs, resolved under that payer’s rules. The printable CMS-1500 and superbill are held back until we sign the AMA CPT licence.
Claims are not transmitted to payers, by design. Agencies that already submit electronically should read that as the gap it is; agencies that keep a biller, most of this market, get the slow part done, which is assembling clean charge data. A biller’s seat costs nothing. Where each field lands on the claim is in the CMS-1500 field guide: Box 23 for the authorization, Box 24J for the rendering provider, Box 33 for who is paid.
Common questions
Does this replace our biller?
Can 97155 be billed alongside 97153?
What happens when a session would exceed the authorized units?
Can we use the billing side with another scheduler?
Bill a mock week for a made-up learner
Create a made-up learner with a test authorization, run a week of RBT and BCBA sessions, and read the charge lines and the remaining balance. Keep real learners out of it until a business associate agreement is signed.