837P, 837I, and 835: Medicaid Billing Explained

Medicaid billing runs on standardized electronic transactions defined by the ASC X12 standard and mandated under HIPAA. Three of them carry most of the money in a fiscal agent operation: the 837P, the 837I, and the 835.

The formats themselves are not the hard part. What causes trouble is the lifecycle between them — where claims are built from, what happens when one is rejected versus denied, and whether remittances are ever genuinely reconciled against what was submitted.

The 837P: professional claims

The 837P (Professional) is the electronic equivalent of the CMS-1500 paper form. It is the transaction used for services billed by individual practitioners and by most home and community-based services — which makes it the primary claim type for self-directed care.

An 837P carries the subscriber and patient, the billing and rendering providers, service lines with procedure codes and modifiers, units, dates of service, diagnosis codes, and the authorization or referral reference.

In self-directed care, the rendering provider is the caregiver and the billing provider is typically the fiscal agent or the program. Modifiers frequently carry meaning specific to the waiver program, distinguishing service types, staffing ratios, or worker relationships that share a base procedure code.

The 837I: institutional claims

The 837I (Institutional) corresponds to the UB-04 form and is used by facilities — hospitals, nursing facilities, home health agencies billing under an institutional arrangement.

The structural difference is that institutional claims are organized around a statement period with revenue codes, rather than around discrete service lines. Institutional billing also carries type-of-bill codes, condition and occurrence codes, and value codes that have no professional-claim equivalent.

Most fiscal agents bill predominantly 837P, but programs spanning both service categories need both. If your billing system only supports professional claims, the institutional portion becomes a manual process.

The 835: electronic remittance advice

The 835 is the payer’s response — the transaction explaining what was paid, what was adjusted, and what was denied.

For each claim and service line, an 835 reports the billed amount, the paid amount, adjustments with Claim Adjustment Reason Codes (CARCs), Remittance Advice Remark Codes (RARCs) giving supplementary explanation, and patient responsibility where applicable. It also carries payment-level information tying the remittance to an actual deposit.

The 835 is where the revenue cycle actually closes, and it is the transaction most often underused. Organizations that import 835s only to record a total payment amount are discarding the line-level detail that explains why the payment differs from what was billed — which is the information needed to stop it happening again.

The claim lifecycle

1. Service delivery. A caregiver provides an authorized service. Under EVV, the visit is captured electronically with all six required data elements.

2. Validation. The service is checked against the governing authorization: covered service, valid date range, sufficient remaining units and dollars, authorized provider.

3. Claim assembly. Validated services become claim lines with the correct codes, modifiers, units, and authorization reference.

4. Scrubbing. Before submission, the claim is checked against structural X12 requirements and payer-specific edits — eligibility for the date of service, accepted code and modifier combinations, units-per-day limits, duplicate detection.

5. Submission. The 837 file goes to the payer, directly or through a clearinghouse.

6. Acknowledgement. The payer returns a 999 confirming syntactic acceptance or reporting structural errors, and often a 277CA reporting claim-level acceptance or rejection.

7. Adjudication. The payer processes the claim.

8. Remittance. An 835 returns with the payment decision.

9. Posting. Payments, adjustments, and denials post against the originating claims.

10. Follow-up. Denials are worked; corrected claims are resubmitted.

Rejection is not denial

These get conflated constantly, and the distinction determines what you do next.

A rejection means the claim never entered adjudication. It failed a structural or front-end edit — a malformed segment, a missing required field, an invalid identifier. It appears on a 999 or 277CA, not on an 835. Because the claim was never accepted, it is corrected and submitted as a new claim, not as a corrected one.

A denial means the claim was adjudicated and the payer decided not to pay. It appears on an 835 with a CARC explaining why. Handling depends on the reason: some denials are appealed, some are corrected and resubmitted with the appropriate frequency code, and some are legitimately not payable.

Treating a rejection as a denial — or the reverse — produces resubmissions that fail for the same reason as the original.

Reconciling the 835

Reconciliation means matching remittance detail to submitted claims at the line level, not agreeing on a total.

Done properly, it answers: was every submitted claim adjudicated, does the paid amount match the expected rate, are adjustments consistent with contract terms, do the line-level amounts sum to the payment, and does the payment match the deposit.

Claims submitted but never adjudicated are the ones that quietly disappear. Nobody denied them, so nothing appears on a denial report — but nobody paid them either. Without reconciliation against submitted claims, they are invisible until timely filing has expired.

Working denials as patterns

Denials arrive with reason codes, and the codes are the useful part. Twenty denials sharing one CARC almost always mean one upstream problem, not twenty separate corrections.

Recurring causes in fiscal agent billing tend to be structural: eligibility lapses where the consumer’s coverage ended before the date of service; authorization mismatches where the service was not covered, the authorization had expired, or units were exhausted; duplicate claims from resubmitting without the correct frequency code; timely filing where the window closed while the claim sat in a work queue; and code or modifier errors where the combination is not one the payer accepts.

Every one of these is preventable upstream. Eligibility and authorization problems are caught by validating at the point of service. Duplicates are caught by scrubbing. Timely filing is caught by aging the pipeline and escalating before the deadline rather than after.

The structural point

Most billing problems are not billing problems. They are upstream problems that become visible at billing.

A claim built from unverified time, or referencing an authorization that had already been exhausted, will be denied — and the cost is not the claim value, it is the staff time to find it, understand it, correct it, and resubmit inside the filing window.

That is the argument for building claims from data that has already been validated. In ArborSoft, visits are verified against the authorization at check-in, payroll pays only verified authorized time, and billing assembles claims from records that have already passed those checks. Imported 835s post automatically against originating claims, with denials grouped by cause rather than worked one at a time.

For the wider picture, see how it fits into self-directed care and FMS operations, or request a demo.