837 claim checker

Because a rejection and a denial are different things. A denial means the payer adjudicated the claim and decided not to pay it. A rejection means the file never got that far — it failed a structural check at the clearinghouse or the payer’s front door and was handed straight back.

Rejections are almost always mechanical, and that makes them checkable without knowing anything about the patient or the policy: a claim total that does not match its service lines, an NPI with a bad check digit, a diagnosis pointer aimed at a diagnosis that is not on the claim. All three are checked here.

Typing errors, and specifically transpositions. An NPI is nine digits plus a check digit calculated with the Luhn formula, and the calculation is done on 80840 prepended to the first nine digits rather than on the NPI alone.

The useful property is that Luhn catches every single-digit error and every transposition of adjacent digits except 09 for 90. So a fat-fingered NPI is caught here rather than three weeks later. A valid check digit does not mean the NPI belongs to that provider — only that it is a well-formed number.

The diagnoses live once, on the claim, in the HI segment — up to twelve of them, each in a numbered position. Each service line then points at the positions that justify it, using numbers rather than repeating the codes.

That indirection is what breaks. Renumber or reorder the diagnoses without updating the pointers and every line now points at the wrong condition. Delete one and a pointer aims at an empty position, which is a rejection. This tool shows each pointer next to the code it actually resolves to, so a wrong one is visible rather than inferred.

The professional, institutional and dental variants. They are the same envelope with a different service-line segment: 837P uses SV1, 837I uses SV2 with a revenue code first, 837D uses SV3.

The tool reads which one it has from the implementation convention in GS08 or ST03 and reads the right segment accordingly. Getting that wrong means reading the wrong element for every charge on the file, which is why it is detected rather than assumed.

No, and nothing that runs in a browser could. Medical necessity, coverage, prior authorisation, bundling rules and fee schedules are all payer-specific and change constantly.

What this checks is whether the file is mechanically well formed: does it add up, do the identifiers pass their own arithmetic, do the internal references resolve. Those are the failures that cost you a billing cycle for no clinical reason, and they are the ones you can eliminate entirely.

No. It is read with the browser File API into memory on your own machine, parsed there, and any download is generated locally. There is no server to send it to; this site is static files.

An 837 carries patient names, member identifiers, diagnoses and dates of service, so this is not a small point. Checking a claim file should not require handing it to a stranger.

They are two ends of the same transaction. The 837 is the claim you send; the 835 is the payer’s answer. They join on the control number — CLM01 here becomes CLP01 on the remittance, which is how you match a payment back to what you billed.

Use this one before submitting and that one after being paid. Both read the file in the browser and neither uploads anything.

Most likely delimiters. An X12 file declares its own in the ISA header, and payers and clearinghouses do vary them. This parser reads them from the file rather than assuming the usual * and ~, which is the most common reason a hand-written EDI parser works on documentation samples and fails on a real file.

If you pasted a fragment with no ISA header, standard delimiters are assumed and the tool says so.