To reconcile corrected ABA claim versions to payer status, preserve every transmitted and held version with its purpose, route, identifiers, and source evidence. Link acknowledgments, payer control numbers, status responses, remittances, and payment to the exact version they describe. Distinguish a pre-adjudication correction, resubmitted rejection, replacement, void, appeal, and records response before changing claims or balances.
Define Eli's corrected claim version reconciliation control
Eli's tree keeps one claim episode with immutable version nodes. Each node records what changed, why, who approved it, and whether the payer treated it as new, corrected, replacement, void, or informational. Responses attach by verified identifiers and timing rather than latest-version assumption.
Build the claim-version status tree
Record episode; person; service date; original source; claim version; created and transmitted time; change reason; clinical and coding authority; frequency or route; interchange and transaction controls; clearinghouse result; payer control; status; adjudication; ERA; payment; appeal; records request; deadline; patient balance; superseded state; owner; and close. Structured fields preserve identity, source, level, version, clock, comparison, access, action, hold, calculation, correction, retest, and closure. Narrative captures clinical meaning, uncertainty, disagreement, family communication, privacy, legal deferral, and the responsible owner's rationale.
Run Eli's workflow
Eli inventories all versions, locates their receiver artifacts, and reconstructs their relationships. He confirms the payer route before sending another transaction. When a response lacks sufficient identifiers, it remains unassigned until payer or trading-partner evidence resolves the match.
Assign decisions to qualified owners
A corrected record and corrected claim are separate acts. A replacement usually relates to an adjudicated claim, while a rejected claim may require a new corrected submission under the payer route. Version lineage cannot be inferred from similar amounts or dates alone.
Work through Eli's fictional example
Eli locks 19 fictional episodes containing 37 claim versions. Thirteen episodes have complete version lineage and payer states. Two attach remittance to the wrong version, one resubmits a pending claim, one uses an internal number as payer control, one lacks change authority, and one hides the original. Four episodes repair and two remain held. Across the full version cohort, 34 have verified states and links; three versions within the held episodes remain open. This synthetic cohort tests control logic and arithmetic only. It creates no coding, coverage, clean-claim, authorization, payment, patient-balance, disclosure, appeal, privacy, or legal conclusion for a real person, provider, plan, claim, or remittance.
Calculate Eli's measures
Initial episode readiness is 13 of 19, or 68.4%. Thirty-four of 37 versions reach verified state and linkage, or 91.9%. Episodes, versions, controls, remittances, payments, and changes remain separate units.
Address the main corrected claim version reconciliation risk
Keeping only the latest claim version can make a reversal or denial appear unrelated. Resending a pending version can create duplicates and complicate later appeal or payment evidence.
Test the claim-version status tree against exceptions
Eli tests 999 reject, 277CA reject, pending payer claim, replacement, void, corrected record, appeal, records response, changed control, remittance reversal, and duplicate submission. Each fixture retains source version, expected state, actual state, affected unit, safeguard, owner, repair, retest, and disposition. Failed, unknown, and held items remain inside the predeclared cohort.
Document the stop condition
Hold the next transaction when the prior version's receiver state, payer control, adjudication, correction authority, or required route is unresolved. Preserve all versions and clocks.
Hand off open work with evidence
Eli's handoff includes the complete version tree, change facts, approvals, identifiers, payer states, remittances, payments, deadlines, and open edge. The receiver traces each response to its node before action.
Maintain Eli's control
Eli audits version lineage after payer, clearinghouse, record, or billing-system changes. Every orphan response and duplicate version enters a root-cause review and regression test.
Verify Eli's release evidence
Eli's release checklist compares the next transaction with the latest verified payer state and the episode's original source. It confirms that superseded versions remain read-only, required reference numbers point to the correct adjudication, and no pending version will create duplicate exposure.
Run Eli's independent review
Eli assigns a reviewer who did not build the claim-version status tree. The reviewer reconstructs the corrected claim version reconciliation source, state, calculation, action, and close from retained evidence. Earlier versions, failed tests, unknowns, and holds remain available. Hidden exceptions, unexplained values, overwritten history, missing population, or unauthorized decisions fail review.
Start with the adopted claim and status standards
Current 45 CFR 162.1102 identifies the adopted professional-claim standard. The CMS claims-status page identifies the 276 request and 277 response. Eli still records the actual payer, product, route, transaction version, receiver, and artifact before applying either source to the claim-version status tree.
Keep the Medicare stage example inside Medicare
The March 2026 CMS Medicare claim-status guide distinguishes 999 front-end processing, 277CA claim-level acknowledgment, payer control assignment, clean-claim payment-status timing, and duplicate risk during editing. Eli uses those facts only for the applicable Medicare route; other payers and contracts require their own evidence for corrected claim version reconciliation.
Read remittance codes with their level and context
CMS's Medicare remittance page separates claim, service-line, and provider-level adjustments and explains group codes, CARCs, RARCs, and PLB in Medicare scope. Eli links the code combination to the raw remittance, original claim, payer source, and qualified decision rather than treating one code as a complete outcome.
Use current X12 code-list status
The X12 external-code-list index defines the scopes of CARCs, RARCs, claim status, and related lists. The current CARC list explains why a claim or line was paid differently than billed. The current RARC list separates supplemental remarks from informational alerts. Eli stores these meanings in the claim-version status tree.
Version updates instead of overwriting history
The X12 code-update listing shows a July 1, 2026 update and notes a corrected RARC N922 effective date on August 3, 2026. Eli retains start, modification, and stop dates, source-check time, and historical mappings so an older remittance is evaluated against the relevant code-set state.
Distinguish receipt and correction identifiers
X12 RFI 2099 says 999 acceptance does not necessarily establish carrier receipt date. X12 RFI 2060 explains the payer-control-number requirement for the standard replacement or void path after adjudication and notes that pending routes can differ. Eli preserves transaction, claim, payer, and version identities separately.
Protect payer order and payment data
The CMS coordination-of-benefits page describes the covered-entity COB transaction. HHS payment guidance and minimum-necessary guidance apply only when their HIPAA conditions are met. Eli verifies payer order, entity status, purpose, recipient, role-based access, and the narrow data needed for the corrected claim version reconciliation work.
Keep clinical and compliance authority scoped
The CASP public summary and BACB Ethics Code supply limited clinical and professional context. The OIG GCPG is voluntary and nonbinding. Eli keeps clinical authorship, coding decisions, payer actions, disclosure authority, financial entries, and legal conclusions with their qualified owners throughout the claim-version status tree.
Related resources
- Prevent Duplicate ABA Claims During Ambiguous Payer Responses.
- Investigate a Missing ABA Remittance After Adjudication.
- Link Payer Document Requests to the Exact ABA Claim and Deadline.
- Separate ABA First-Pass Transmission, Adjudication, and Payment Yield.
Sources
- Council of Autism Service Providers, ABA Practice Guidelines Version 3.0 public summary.
- Behavior Analyst Certification Board, Ethics Code for Behavior Analysts.
- Electronic Code of Federal Regulations, 45 CFR 162.1102, standard for health care claims.
- Centers for Medicare and Medicaid Services, Health Care Claims Status.
- Centers for Medicare and Medicaid Services, Checking Medicare Claim Status, March 2026.
- Centers for Medicare and Medicaid Services, Health Care Payment and Remittance Advice.
- X12, External Code Lists.
- X12, Claim Adjustment Reason Codes.
- X12, Remittance Advice Remark Codes.
- X12, Code Updates Listing.
- X12, RFI 2099, 999 Confirming Claim Receipt.
- X12, RFI 2060, Withdrawal or Void Claim and Response.
- Centers for Medicare and Medicaid Services, Coordination of Benefits transaction.
- U.S. Department of Health and Human Services, Uses and Disclosures for Treatment, Payment, and Health Care Operations.
- U.S. Department of Health and Human Services, Minimum Necessary Requirement.
- U.S. Department of Health and Human Services Office of Inspector General, General Compliance Program Guidance.
