Reading 835 Remittance Files With AI: Turning EDI Into Actionable Denial Data

By Clayton Severson, Principal Consultant · Published August 25, 2026

Do not point a language model at raw EDI. The 835 is a rigidly structured X12 transaction with a published implementation guide, so parsing it is a deterministic problem with an exactly correct answer. Parse it with a real parser, land it in tables, and save the AI for the analysis that comes after.

This is the least fashionable opinion in healthcare AI and the one that saves the most money. There is real enthusiasm right now for pointing a large language model at messy healthcare files and asking it to extract the data. For clinical notes and payer policy PDFs, that instinct is correct — those are genuinely unstructured. For an 835, it is a category error that costs more, runs slower, and produces numbers you cannot audit.

What follows is what is actually inside the file, the data model to land it in, the three things that break reconciliation, and the places where AI earns its cost — all of which sit downstream of parsing.

What is an 835 file?

It is the payer's explanation of a payment, in machine-readable form.

Structurally it is a nested hierarchy: a payment header, then payer and payee identification, then claims, and inside each claim, service lines. Adjustments attach at both the claim and the line level. The nesting is where most home-grown parsers go wrong — they flatten too early and lose the relationship between an adjustment and the line it belongs to.

What is actually inside one?

A short list of segments carries nearly all the analytical value. Everything else is envelope and identification.

Segment	What it carries	Why it matters
BPR	Payment amount, method, and effective date	The control total every other number must reconcile to
TRN	Reassociation trace number	How you match this file to the actual deposit in the bank
CLP	Claim-level payment: patient control number, claim status, total charge, total paid, patient responsibility	The claim grain, and CLP02 is where reversals hide
SVC	Service line: procedure code, line charge, line payment, units	The grain everything useful is analyzed at
CAS	Adjustments: group code, reason code, and amount	Every dollar that was not paid, and the reason for it
AMT / PLB	Supplemental amounts (B6 = allowed) / provider-level adjustments	The allowed amount, and the adjustments that break your totals

The CAS segment is the analytical heart of the file. Each one carries a group code and a reason code for money that was not paid: CO for contractual obligation, PR for patient responsibility, OA for other adjustment, and PI for payer-initiated reduction. The reason codes attached are the CARC values, with RARC values adding qualification — both covered in the most common medical billing denial codes.

One consequence worth stating plainly: a single service line can carry several CAS segments, each with multiple adjustment triplets. A parser that assumes one adjustment per line will silently drop money, and it will do so on exactly the complicated claims you most need to understand.

Why not use a language model to parse it?

Five reasons, in descending order of how much they will cost you.

• There is a correct answer, and it is specified. The 835 has a published X12 implementation guide. When a specification defines exactly what every element means, a parser implements it and is right every time. A model approximates it and is right most of the time. In financial data, "most of the time" is the whole problem.
• Silent fabrication. A parser that hits something unexpected throws an error. A language model produces a plausible number. You will not notice the difference until an auditor does.
• Cost and speed. A large practice's monthly remittance volume runs to hundreds of thousands of service lines. Deterministic parsing is effectively free; token-based extraction at that volume is not, and it is orders of magnitude slower.
• Auditability. "The parser read SVC03 at position 4" is an explanation. "The model extracted it" is not, and healthcare finance eventually requires an explanation.
• Determinism. Reprocess the same file next quarter and a parser gives byte-identical output. A model may not.

Use an established X12 library or a purpose-built parser. If a vendor's pitch for 835 processing centers on the language model, ask them what happens when it misreads an amount, and how you would know.

Where does AI genuinely help?

Downstream, on structured rows, where the problems really are ambiguous. Four places pay for themselves.

1. Clustering denials to root cause. The reason code says what the payer called it; it does not say what went wrong in your operation. Clustering across payer, code pairing, modifier, location, and provider is what turns thousands of CO-16 lines into three fixable process failures. This is the highest-value use, and it is covered in depth in how to use AI to manage and prevent claim denials.
2. Normalizing payer quirks. Every payer implements the standard slightly differently — which segments they populate, how they describe things in free text, which adjustments they route through OA rather than CO. Mapping those local dialects onto one canonical model is fuzzy matching work, and models are good at it.
3. Anomaly detection on expected versus actual. Once you can compute what a claim line should have been allowed, a model watching the variance stream will surface a payer's fee schedule loading error faster than a monthly report will. That analysis is the subject of using your claims data to win payer contract negotiations.
4. Drafting appeals. Genuinely unstructured work — reading a payer policy, mapping documentation to coverage criteria, writing the argument. This is what language models are for.

Notice the pattern: every one of these operates on a table, not on a file. Parsing is the prerequisite, not the product.

What data model should you land it in?

Three tables, at three grains, preserving the hierarchy the file already has.

Table	Grain	Key fields
Payment	One row per 835 file	Payer, payment amount, method, trace number, file received date
Claim	One row per claim	Patient control number, payer claim number, status code, charge, paid, patient responsibility
Service line	One row per line	Procedure, modifiers, units, charge, paid, allowed, date of service
Adjustment	One row per adjustment triplet	Group code, reason code, amount, and the line or claim it attaches to

Keep adjustments as their own long table rather than pivoting them into columns. You do not know in advance how many adjustments a line will carry, and the moment you flatten to adjustment_1 through adjustment_3 you have built a ceiling into your data model that will silently truncate the complex claims.

Then join it to the 837 you submitted. Remittance data on its own tells you what came back; only the join tells you what you asked for, and every useful denial or underpayment analysis needs both sides.

The three things that break reconciliation

These account for most of the "our numbers don't tie out" reports I have seen, and none of them are exotic.

Provider-level adjustments (PLB). The PLB segment carries adjustments that belong to the payment rather than to any claim — recoupments of prior overpayments, interest on late payments, capitation, and balances carried forward to or from another remittance. Because they sit entirely outside claim detail, the sum of your claim payments will not equal the payment amount in BPR until you account for them. A parser that ignores PLB produces a file that looks internally consistent and disagrees with the bank. Forwarding balances are especially awkward: a balance moved to a future advice appears in one file and resolves in another, so a single file never tells the whole story.

Reversals and corrections. The claim status code in CLP02 tells you what kind of transaction a claim row is. A value of 4 means denied; a value of 22 means reversal of a previous payment — the payer taking money back. Reversals frequently arrive paired with a corrected claim in the same file, so the same encounter appears twice with opposite signs. A parser that treats every CLP as a payment double counts and overstates collections, which is a very uncomfortable discovery to make during a month-end close.

Adjustments that are not write-offs. Not every CAS line is a contractual write-off. PR is money the patient owes, not money you lost. OA and PI are the categories where genuinely odd payer behavior hides. Treating all adjustments as one bucket destroys exactly the signal you were parsing the file to find.

What about compliance?

835 files contain patient names, member identifiers, dates of service, and procedure codes. That is protected health information, which means every vendor and every AI service in the path is a business associate and needs a signed BAA before a file moves. The general case is covered in can you use ChatGPT with PHI.

The practical mitigation is that most remittance analytics does not need identity at all. Denial root-cause analysis, rate variance, and payer performance all work on codes, amounts, dates, and payer identifiers. Strip patient identifiers at ingest, keep a linkage key in a controlled table for the cases that genuinely need it, and the surface area of everything downstream shrinks dramatically.

Frequently asked questions