835 / ERA Remittance Explainer
Paste a raw 835 fragment and read it segment by segment in plain language — the claim, its adjustments, its service lines, and the provider-level adjustments that explain why the deposit doesn't match. Nothing you paste leaves your browser.
This runs entirely in your browser.
A remittance can contain patient identifiers. Nothing you paste here is uploaded, stored, saved to this page’s address, or logged — the parsing happens in this tab and the text is gone when you close it. Even so, paste only the claims you need to read.
Segments separated by ~ or by line breaks. A few claims is plenty — you do not need the whole file, and you should not paste more of a patient’s data than you need to read.
Paste a fragment above, or load the sample, to see it explained segment by segment.
What this reads, and what it does not
An 835 is the electronic version of a remittance advice — the file a payer sends to explain a payment. It is a sequence of segments, each one a code followed by elements separated by *, and the whole thing is usually one unbroken line of text.
This tool reads eight segments: CLP (the claim), CAS (adjustments), SVC (service lines), PLB (provider-level adjustments), TRN (the trace number), AMT, DTM and NM1. Anything else is listed and skipped, and the tool names what it skipped. That is deliberate: a parser that half-understands a segment is worse than one that admits it did not read it, because you cannot tell which you are looking at.
Why PLB is drawn outside the claims
A provider-level adjustment belongs to the payment, not to a claim. It never appears in any claim’s balance — and it is the single most common reason a deposit does not match the claims posted against it. Someone reconciling a short deposit will check every claim, find each one correct, and conclude a payment is missing. It is not: it was withheld at the provider level, on a segment sitting outside the claim loop entirely. The layout here teaches that by putting it where it actually belongs.
About the codes
A CARC number and its group code are facts and are shown exactly as they appear in your file. The official descriptions of those codes — and of RARCs — are licensed by X12, so they are not reproduced here. Where we have written our own plain-language explanation of a code, the adjustment links to it in the denial code decoder, which also gives the next action rather than only the meaning.
Next steps
If a claim here does not balance, the remit balancing checker lets you work the figures directly and check the patient responsibility summary against its detail. How payment posting works covers the process this reading belongs to, and payment reconciliation covers proving the deposit once the claims are posted — the step PLB most often complicates.
Ready to improve your revenue cycle?
Explore our services and knowledge base to see how we can help.