Codes, Units, Dates and Goals: Preventing Internal Conflicts in ABA Authorization Requests

For ABA clinicians, authorization teams, and revenue-cycle leaders. Sources checked August 13, 2026. External review by an ABA prior-auth specialist, an RCM/coding reviewer, and a BCBA is pending.

A coherent request can still be denied, and an authorization can still face claim edits or benefit conditions. This guide is an operational quality-control resource. It does not determine coverage, replace licensed coding resources, promise approval or payment, or direct care for an individual.

Lock the configuration key before auditing ABA authorization units and codes

Start each review with a configuration key that identifies the rule set for this request. Record the payer legal entity, plan or product, state, funding program, member ID, network, benefit, request type, service period, rendering group, service location, submission channel, form version, and every policy or manual effective date. Add the eligibility-check date and the person who verified it.

The key prevents a familiar error: applying the right requirement to the wrong product or period. A commercial policy, state Medicaid manual, managed-care form, and employer plan under one brand can differ. Preserve the exact source and effective date beside each rule instead of relying on a remembered payer preference.

Four records need separate labels throughout the packet:

The CMS prior-authorization workflow likewise separates treatment recommendation, coverage-requirement discovery, submission, and payer response. The CMS Prior Authorization API FAQ says an impacted payer's response identifies approval and duration, denial and reason, or a need for more information. That federal API framework has defined payer and implementation scope; it supplies no universal ABA coverage rule.

Assign one source of truth to every field

A packet becomes fragile when several documents appear authoritative. Name the field owner, authoritative source, and permitted downstream copies before review.

The BACB ethics landing page directs certificants to check periodically for current ethics documents. The current Ethics Code for Behavior Analysts addresses accurate service identification, required billing and reporting information, timely correction of discovered inaccuracies, and high-quality documentation. The CASP guideline page describes its 2024 practice guideline as supporting ABA assessment, treatment planning, implementation, and evaluation; licensed access governs the full text.

Audit code, provider, and setting as one service identity

Review each requested line as a combined identity: service code, provider role, provider identifiers, group, setting, delivery mode, modifier question, unit definition, and service dates. A code copied from an old authorization proves little about current eligibility.

Use a current, licensed code reference and the payer's current materials. This article intentionally omits CPT descriptors. CMS explains that HIPAA transactions use adopted diagnosis and procedure code sets, while the AMA's CPT licensing FAQ addresses permission to use, reference, or display CPT content. The ABA Coding Coalition offers adaptive-behavior coding resources, yet the member's payer and current code-set sources still control the live request.

For every line, verify:

1. The code is active for the proposed dates and fits the intended service under the licensed source.
2. The payer accepts that code for the member's product, request type, and setting.
3. The proposed rendering and supervising roles meet applicable credential, license, enrollment, contract, and supervision conditions.
4. Individual, group, group-practice, and facility identifiers occupy the correct fields.
5. The planned location matches the form's setting selection and any required claim place of service. CMS maintains the national Place of Service code set, while the relevant insurer answers jurisdiction-specific coding questions.
6. Telehealth, school, home, clinic, community, and multi-client rules are verified for this plan instead of inferred from another product.
7. Any modifier comes from a current applicable rule. Never add one solely to force a code combination through an edit.

Define the unit before doing arithmetic

Write the unit definition at the top of the calculation sheet. A unit can represent a time interval, event, day, month, or item depending on the service and program. Record the source, effective date, rounding convention, partial-unit treatment, daily limit, weekly representation, and authorization-period field instructions.

For a time-based service, the basic calculation is:

units per session = billable service minutes / payer-defined minutes per unit

Then calculate the proposed period from scheduled occurrences:

period units = sum of units for every planned occurrence inside the requested date span

Avoid multiplying a weekly amount by a decimal month estimate when the form asks for an exact date span. Count service dates, partial weeks, closures, known vacations, planned assessment days, and cadence changes. Keep requested capacity distinct from forecast utilization. Apply the controlling rounding rule only after confirming it.

The June 2026 Indiana Medicaid universal prior-authorization instructions illustrate why a universal conversion fails: their units field may refer to days, months, or items as applicable, and requested dates must coincide with treatment-plan dates. Those instructions apply to Indiana Medicaid's named form and submission process.

Reconcile frequency, duration, and dates from both directions

Perform a forward calculation from the session plan and a reverse calculation from the requested total. A mismatch exposes a transcription error or an unstated assumption.

Forward: sessions per week x units per session x full service weeks + partial-week units.

Reverse: requested period units / units per session = supported session count.

Compare the result with the treatment-plan frequency, provider capacity, caregiver availability, school or work schedule, other services, requested start and end dates, and anticipated transition points. Check whether start and end dates are inclusive, whether the payer uses calendar days or a fixed span, and whether a continuation request creates a gap or overlap with the current authorization.

Dates deserve their own stop check. Goal introduction dates, baseline periods, assessment dates, signatures, proposed service dates, form date, prior authorization expiration, and requested period should tell a plausible chronology. A plan signed after the proposed start date or a goal with a mastery date outside the request needs explanation or correction.

Connect services to goals without inventing one-to-one mappings

The clinical crosswalk explains why each service component supports the individualized plan. It should never imply that each code belongs to exactly one goal. One service may address several goals during a session, and one goal may require direct treatment, clinical direction, caregiver work, coordination, or reassessment across the period.

For each service component, document its clinical purpose, relevant assessed needs, goal clusters, provider role, setting, proposed cadence, measurement plan, and review decision. Then compare those fields with the schedule and request table. The BCBA owns the clinical relationship. Authorization or billing staff can flag missing or conflicting logic and return the item for clinical resolution; they should not create clinical rationale or adjust intensity to fit an administrative field.

Goal dates and service dates also need a coherent relationship. New-goal work may start after an assessment or protocol revision. A maintenance or generalization objective may use a different cadence. Record those distinctions instead of making every goal span the full authorization period.

Keep requested, approved, scheduled, rendered, and billed values distinct

Store each state in its own field and preserve its source document. The clinical recommendation may propose 300 units, the submitted request may contain 288 after a corrected calendar count, and the payer may approve 240 for a narrower date span. Scheduling then uses the approved parameters while respecting the current clinical plan. Billing follows the rendered, documented service and applicable claim rules.

Authorization status cannot validate the eventual claim by itself. The Texas Medicaid Provider Procedures Manual states, for Texas Medicaid, that prior authorization is a condition of reimbursement for specified services and is not a guarantee of payment; claims can still deny under coding edits. The CMS coding overview similarly explains that obtaining a code does not determine coverage or payment.

Never edit the original request or payer notice to make later records look aligned. Post the decision as a new state, communicate any clinical impact to the BCBA, and obtain a revised plan or payer action when required.

Route overlap, concurrency, and modifier questions to current rules

An overlapping time block raises several separate questions: clinical feasibility, documentation, payer coverage, authorization configuration, code-pair edits, provider eligibility, modifier use, and claim reporting. Build an issue record with the member, dates, time intervals, participants, locations, service lines, rendering providers, supervisors, planned activities, and source being evaluated.

Route clinical feasibility and treatment integrity to the BCBA. Send code-pair, modifier, unit-limit, provider, and place-of-service questions to a qualified coding or RCM reviewer using the current payer manual, contract, fee schedule, form, code-set release, and applicable edit files. CMS's Medicaid NCCI page defines procedure-to-procedure and medically unlikely edits for Medicaid and warns that an edit file's inclusion of a code does not establish state coverage. Apply that source only where Medicaid NCCI governs.

Document the payer or coding response, representative or reference number, effective period, and reasoning. An unsupported modifier, assumed exception, or unresolved overlap remains a stop-ship issue.

Crosswalk the form to the plan before submission

Use this field-level crosswalk for every requested service line:

Current program forms show why each field needs a scope label

Indiana Medicaid's fee-for-service behavioral health module, published July 23, 2026, requires requested hours, a service schedule, and appropriate providers in the ABA treatment plan. Its practitioner-identifying claim modifiers are absent from the prior-authorization request. Apply that distinction only to the Indiana program and dates it governs.

Nevada Medicaid and Nevada Check Up's FA-11E, updated July 13, 2026, places dates, code, modifier, units per day, days per week, and total units on each requested line. Its companion instructions add provider-role and request-timing rules. Those controls belong to the named Nevada programs.

The January 2026 Tennessee multi-MCO ABA request asks for 15-minute units, weekly and authorization-period totals, applicable MCO modifiers, requested dates, and setting. That unit instruction applies to the plans and form named there. It supplies no default for another payer.

Worked synthetic packet: find the conflict before the payer does

This fictional example contains no patient information and represents no real payer rule. “North Harbor Plan” and “Service A” are invented. The omission of a code descriptor is intentional.

Configuration: North Harbor's current fictional rule defines Service A as 15 minutes per unit for this product. The plan proposes three 180-minute visits weekly. The requested span includes one partial opening week with a single 90-minute visit, followed by eight full weeks. The BCBA links Service A to three goal clusters and explains the combined teaching plan. No one-to-one code-to-goal claim appears.

Controlled calculation: A 180-minute visit equals 12 units. Each full week contains 36 units. Eight full weeks produce 288 units, and the partial 90-minute visit adds 6. The correct request is 294 units across 25 planned visits.

Conflicts found: The portal shows 300 units. The form lists 10 units per visit and three visits weekly, which would produce 240 units for eight full weeks before the partial visit. Its start date omits the partial week. The treatment plan says “up to 12 hours weekly,” while the actual schedule represents nine. A clinic setting is selected, although two planned visits occur at home. The rendering provider's enrollment record covers the clinic only. One modifier was copied from a different product's prior approval without a current North Harbor source.

Disposition: Stop submission. The BCBA clarifies the clinically intended nine-hour schedule, mixed settings, goal logic, and service rationale. The prior-auth or RCM reviewer confirms the unit rule, provider eligibility, setting fields, modifier requirement, and date span with North Harbor. After correction, the worksheet, plan, form, portal, and attachment inventory must all show the same 294-unit calculation or explicitly explain each permitted difference. This clean reconciliation improves reviewability and offers no approval guarantee.

Classify conflicts and require dual signoff

Use a compact taxonomy so each issue reaches the right owner:

Mark severity as stop ship, correct before release, or monitor after submission. Stop ship applies when the conflict can change service identity, quantity, dates, provider eligibility, setting, clinical recommendation, attestation, or submission validity. It also applies when the governing rule cannot be identified.

Final approval needs two named signoffs. The clinical signer confirms assessed need, goal relationships, recommended service mix, intensity, setting, schedule assumptions, and clinical attestations. The prior-auth or RCM signer confirms configuration, code-set version, payer rule, provider fields, units, dates, arithmetic, form, attachments, and transmission route. The HHS OIG compliance resources support organization-specific compliance infrastructure and risk controls for federal healthcare programs; they do not replace the exact program rule.

Control corrections as new versions

Log every change with packet ID, field, old value, new value, source, reason, requestor, editor, timestamp, and required approver. A clinical field returns to the clinician. A coding or payer field returns to the designated reviewer. If a change affects another field, reopen the linked checks.

Generate a fresh packet inventory after edits. Retire superseded files from the active submission folder, preserve them under retention rules, and prevent accidental upload. Capture the final file names, sizes or hashes, page counts, signatures, version IDs, portal fields, destination, submission time, and receipt. A post-submission correction gets its own chronology and proof.

The BACB code calls for timely correction and documentation when reporting or billing inaccuracies are found. Local law, payer instructions, contracts, privacy rules, and organizational policy determine the exact correction route.

Stop-ship checklist

Release the request only when every answer below is yes or a qualified owner has documented an accepted resolution:

• [ ] The configuration key identifies the exact payer, product, program, request type, period, setting, channel, and current source versions.
• [ ] Clinical recommendation, payer policy, submitted request, payer decision, and billing records have separate fields and owners.
• [ ] Each code is current for the proposed dates and checked against a licensed source plus payer rules.
• [ ] Provider role, identifiers, credentials, enrollment, network, supervision, and setting agree for every service line.
• [ ] The unit definition, rounding rule, and limits are cited; no conversion rests on habit.
• [ ] Session, weekly, partial-period, and total calculations reconcile forward and backward.
• [ ] Frequency, duration, date span, schedule, signatures, goal dates, and current authorization form a coherent chronology.
• [ ] The service-to-goal crosswalk states clinical purpose without forcing one code per goal.
• [ ] Requested, approved, scheduled, rendered, and billed values remain distinct.
• [ ] Concurrent, overlap, modifier, and place-of-service questions have current payer-specific answers.
• [ ] Form, portal, treatment plan, calculation sheet, provider roster, and attachments agree or explain permitted differences.
• [ ] Clinical and prior-auth or RCM reviewers completed their assigned signoffs.
• [ ] All corrections are logged, superseded files are controlled, and the exact submission packet is reproducible.
• [ ] The receipt and follow-up owner will be stored immediately after transmission.

This audit improves internal consistency and leaves payer judgment intact. The treating clinician remains responsible for clinical decisions. Payers apply the member's current benefit and review criteria, while qualified coding and billing professionals apply current reporting rules to services actually rendered. External ABA prior-auth, RCM/coding, and BCBA review of this draft remains pending.

Related resources

Browse the parent guide, Prior Authorization and Medical Necessity, for the complete clinical authorization library.

• ABA Concurrent Authorization Checklist: Progress, Barriers and the Next Treatment Period
• How to Write a Medical-Necessity Narrative for ABA Authorization
• How to Maintain a Payer-Specific ABA Prior Authorization Requirements Matrix
• Preparing for an ABA Prior Authorization Peer-to-Peer Review

Sources

Sources were checked August 13, 2026. Recheck code sets, payer materials, forms, and plan rules for the applicable product and dates before use.

1. Behavior Analyst Certification Board, Ethics Codes
2. Council of Autism Service Providers, ABA Practice Guidelines Version 3.0
3. Centers for Medicare & Medicaid Services, Prior Authorization API FAQ
4. ABA Coding Coalition, coding resources
5. U.S. Department of Health and Human Services Office of Inspector General, Compliance
6. Behavior Analyst Certification Board, Ethics Code for Behavior Analysts
7. Centers for Medicare & Medicaid Services, Overview of Coding and Classification Systems
8. Centers for Medicare & Medicaid Services, Prior Authorization API Workflow
9. Centers for Medicare & Medicaid Services, Code Sets Overview
10. Centers for Medicare & Medicaid Services, Place of Service Codes
11. Centers for Medicare & Medicaid Services, NCCI for Medicaid
12. American Medical Association, CPT Licensing Frequently Asked Questions
13. Indiana Medicaid, Universal Prior Authorization Request Form Instructions
14. Indiana Medicaid, Behavioral Health Services Provider Reference Module
15. Nevada Medicaid and Nevada Check Up, FA-11E ABA Authorization Request
16. Nevada Medicaid and Nevada Check Up, FA-11E Instructions
17. Tennessee Multi-MCO, Request for Applied Behavior Analysis, January 2026
18. Texas Medicaid Provider Procedures Manual, Claims Filing