Every admission produces reimbursement data in pieces. A benefits check returns the deductible and coinsurance. An authorization comes back with a number and approved days. The claim goes out, and weeks later the payer’s electronic remittance explains what it paid and why.
Each piece lands in a different system. The benefits check sits in the verification tool or a PDF, the inquiry in the CRM, the authorization in the EMR, and the claim and remittance in the billing system. The admissions team, the people deciding which inquiries to pursue, usually sees only the first piece.
Our pieces on the VOB-to-admit reimbursement gap and VOB vs expected reimbursement explain why a verification can’t tell you what a plan will pay. This piece covers the plumbing: where the data drops between systems, which fields to carry end to end, and how to route what payers actually paid back to admissions.
It connects to the work inside our admission ops and billing practice. This isn’t legal or billing advice; confirm workflows with your billing team and counsel.
Key Takeaways
- Reimbursement data for one admission is spread across four systems: the verification tool, the CRM, the EMR, and the billing system. Most of it never reaches admissions.
- The eligibility response (271) is built to report patient financial responsibility, like remaining deductible and coinsurance, not what the facility will be paid.
- The electronic remittance advice (835) explains how a payer adjusted the claim, using standard Claim Adjustment Reason Codes. It’s the most useful reimbursement data a facility gets, and it usually stays in billing.
- Data drops at handoffs: free-text payer names, benefits trapped in PDFs, authorization numbers entered only in the EMR, and level-of-care changes the CRM never sees.
- Tie every record to one admission ID, carry a short list of fields through every system, and send a monthly payer-level summary of remittance results back to admissions.
The four systems and what each one holds
Four systems, four sets of records:
| System | What it captures | Standard transaction | What usually gets lost |
|---|---|---|---|
| Verification tool or clearinghouse | Benefits: deductible, coinsurance, copay, coverage | 270/271 eligibility | Structured fields, when results are saved as PDFs or notes |
| CRM | Inquiry, source, payer as typed by admissions | None | Exact payer ID, plan product, member and group IDs |
| EMR | Clinical record, level of care, authorizations, utilization review | 278 authorization (where used) | Link back to the original inquiry |
| Billing or practice management | Claims, payments, adjustments | 837 claim, 835 remittance | Feedback to admissions |
CMS lists these as the HIPAA standard transactions, all on X12 version 5010. Any provider that conducts them electronically has to use the standards.
DEFINITION
Reimbursement data chain. The sequence of records that connects one inquiry to the payment for that admission: the benefits check, the authorization, the claim, and the remittance. The chain is only useful when each link carries a shared identifier and the fields needed to compare what was expected with what was paid.
What the eligibility response does and doesn’t tell you
The CAQH CORE eligibility data content rule requires health plans in its program to return base and remaining deductibles, copay and coinsurance amounts, and related benefit details. It frames the remaining deductible as the patient’s financial responsibility.
That’s useful for a family conversation about cost. It isn’t the facility’s expected payment. The same CORE document notes that HIPAA’s mandated eligibility data doesn’t include all the financial and benefit information providers need. Our guide to reading a 271 eligibility response covers the fields in detail.
Where the data drops
Five places it usually drops.
Payer identity
Admissions types “Blue Cross” into the CRM. The verification tool returns a payer ID and plan details. The claim goes to a specific payer and product. When those don’t match, nobody can line up the inquiry with the eventual payment. Blue plans add a layer, since the member ID prefix determines the home plan. Our BCBS alpha prefix decoder covers that.
Benefits trapped in documents
A verification saved as a PDF or a note can be read by a person but not reported on. If remaining deductible, coinsurance, and network status aren’t stored as fields, they can’t be compared with the remittance later.
Authorizations entered only in the EMR
The authorization number, approved level of care, and approved days often live in the clinical record. When they’re missing from the claim, the payer can deny it: X12’s Claim Adjustment Reason Code 197 covers precertification or authorization that’s absent.
Level of care changes the CRM never sees
A patient steps down from residential to partial hospitalization. The EMR and billing system know. The CRM still shows the original admission, so admissions can’t see which inquiries turned into which billed stays.
The remittance never comes back
CMS says the electronic remittance advice explains how a plan adjusted claim charges based on contract agreements, secondary payers, benefit coverage, and expected copays and coinsurance. Payers have to use standard codes, not proprietary ones.
Reason code 45, for example, means the charge exceeded the fee schedule or contracted amount. Group codes show who’s responsible: CO for a contractual adjustment, PR for patient responsibility. That’s the closest thing a facility gets to a record of what each plan actually pays, and it rarely leaves the billing system.
The fields to carry end to end
Pick one admission ID and attach it to the inquiry, the verification, the authorization, the claim, and the remittance. Then carry these fields:
| Stage | Fields |
|---|---|
| Inquiry | Admission ID, source, payer as shown on the card, member ID, group ID |
| Verification | Payer ID, plan product and network status, verification date and reference, remaining deductible, coinsurance, out-of-pocket remaining |
| Authorization | Authorization number, approved level of care, approved days or units, dates |
| Admission | Admit date, level of care, level-of-care changes and dates |
| Claim | Claim ID, billed amount, dates of service |
| Remittance | Allowed amount, paid amount, patient responsibility, adjustment reason codes |
The admission ID is what ties each row to the next.
COMMON MISTAKE
Fixing it with one big integration. Teams sometimes try to connect every system at once and stall. A shared admission ID and a short field list entered consistently gets most of the value.
Start with the fields, then automate the handoffs that carry the most volume. EMR and CRM integration guides, like our Kipu integration guide, cover the technical side.
Closing the loop to admissions
Enroll in electronic remittance with every plan. CMS encourages providers to enroll for both electronic funds transfer and remittance advice with each health plan they work with. Under 45 CFR 162.925, a plan must conduct a standard transaction when asked.
Send admissions a monthly payer summary. By payer, plan product, and level of care: claims billed, allowed, paid, patient responsibility, and the most common adjustment reason codes. Put it next to what verification predicted for the same admissions.
Keep it inside covered systems. These are patient records, and for SUD programs, 42 CFR Part 2 records. Keep the data in systems covered by business associate agreements, share only what admissions needs, and keep it out of marketing and ad platforms. Our CRM reconciliation guide covers reporting admits without moving patient detail.
OPERATOR INSIGHT
The first payer summary usually raises more questions than it answers, because the identifiers don’t match yet. That’s the point. Each mismatch shows which handoff to fix next.
After two or three months, admissions can see which plans and products pay close to what verification suggested, and which don’t.
What’s changing
CMS’s Interoperability and Prior Authorization Final Rule (CMS-0057-F) applies to Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and Qualified Health Plan issuers on the federal exchanges.
Starting in 2026, those payers must give a specific reason for denied prior authorizations, and most must decide within 72 hours for urgent requests and 7 calendar days for standard ones.
They must offer a prior authorization API by January 1, 2027. Commercial employer plans aren’t on the rule’s list, so most commercial authorization workflows won’t change because of it.
X12 version 5010 remains the mandated standard for claims and remittances.
Where this fits
The handoffs are where reimbursement intelligence breaks down in practice. For the category, see our reimbursement intelligence guide, and for verification itself, the verification of benefits guide.
For the billing side, see the revenue cycle management guide and our guide to reducing claim denials. For how admissions fits the rest of your marketing, see the complete guide to behavioral health marketing. If you want a second look at how your systems hand off data, book an intro meeting.
Frequently Asked Questions
Why doesn’t our verification tell us what a plan will pay?
The eligibility response is built around patient financial responsibility: deductibles, copays, coinsurance, and coverage.
CAQH CORE notes that HIPAA’s mandated eligibility data doesn’t include all the financial information providers need.
What a plan actually pays shows up later, in the electronic remittance advice.
What is an 835, and why should admissions care?
The 835 is the electronic remittance advice. It explains how the payer adjusted the claim, with standard reason codes for contractual adjustments, patient responsibility, and denials.
It’s the most direct record of what each plan pays for each level of care.
A monthly summary by payer and plan gives admissions a reality check on verification.
What’s the single most important field to carry across systems?
A shared admission ID on every record, from inquiry to remittance.
Without it, matching an inquiry to its payment takes manual work every time.
After that, an exact payer ID and plan product matter most, since free-text payer names break the match.
Can we send remittance data to our marketing team?
Only in aggregate, and only what they need. Remittance and claim data are patient records, and SUD records may be covered by 42 CFR Part 2.
Keep detailed data in systems covered by business associate agreements.
Share payer-level summaries, not patient-level records, and keep them out of ad platforms.
Does the CMS prior authorization rule apply to commercial plans?
The rule applies to Medicare Advantage, Medicaid and CHIP programs and managed care plans, and Qualified Health Plan issuers on the federal exchanges.
Commercial employer plans aren’t on that list.
For covered payers, specific denial reasons apply from 2026 and a prior authorization API is due by January 1, 2027.
Kyle McHenry is the founder of Revenue Logic, a behavioral health revenue cycle management firm. He has spent 15 years working with treatment center operators on verification, utilization review, and claims management. Webserv partners with Revenue Logic to surface RCM-side guidance for treatment center marketing teams.
