What is an 837 file?

Key takeaways

An 837 file is the electronic healthcare claim providers send to payers, written in the X12 EDI format HIPAA adopted.

Three variants exist: 837P for professional claims, 837I for institutional claims, and 837D for dental claims.

Nobody types an 837 by hand. Billing software generates the file from the invoice and sends it.

Three files come back in order: a 999 confirms the batch parsed, a 277CA accepts each claim, and an 835 reports payment.

A rejected 837 never reached adjudication, so there is nothing to appeal. Fix the data and resubmit.

An 837 file is the electronic version of a healthcare claim. It is the standard file your practice sends to a payer instead of mailing a paper form. The file is plain text, built to the X12 EDI standard, and it is the format HIPAA requires for electronic claims.

Open one and it looks like machine noise. Rows of capital letters, asterisks and tildes, no labels, no line breaks in the places you expect. But the content is familiar. It carries exactly what a CMS-1500 carries: the patient, the provider, the insurance, the diagnoses, the services, and the charges.

Most people never need to read one. You need to when a claim “failed at the clearinghouse” and the message names a segment you have never heard of. This guide translates the file into plain English, walks a real fragment line by line, and shows what to do when one comes back rejected.

837P, 837I and 837D: The three claim types

The three 837 variants each replace a different paper claim form. Which one you send depends on the kind of provider you are, not on the treatment or the payer.

Federal regulation names each one separately. The professional version is ASC X12N 005010X222, the institutional version 005010X223, and the dental version 005010X224. You will see the professional one written as 5010A1, which is the same guide with its errata applied.

Everything below uses the 837P, because that is what almost every non-facility practice sends. If you bill office visits, treatments, injections or therapy sessions, your claims are 837P claims.

The implementation guide is not quite the last word, though. Payers publish companion guides that pin down the elements the standard leaves situational. Two plans can want the same field filled in differently, which is one reason a claim accepted by one payer bounces at another.

What’s inside an 837: Loops and segments in plain English

An 837 is organized into segments and loops. A segment is one line carrying one kind of record, and it always starts with a short code naming what it holds. A loop is a group of segments describing one entity, such as the billing provider or a single claim.

Inside a segment, data elements are separated by a delimiter, usually an asterisk. Sub-elements inside one element are separated by a colon. Every segment ends with a terminator, usually a tilde. Those three characters are all the punctuation the format has.

Loops are numbered, and the numbers matter because rejection messages quote them. These four carry the claim itself:

• Loop 2000A, the billing provider. Your practice: name, address, NPI, tax ID and taxonomy code.
• Loop 2000B, the subscriber and payer. Whose policy is paying: member name, date of birth, member ID, and the payer’s ID. A dependent gets loop 2000C.
• Loop 2300, the claim. One claim: your invoice number, total charge, place of service, and diagnosis codes.
• Loop 2400, the service lines. One loop per line item: procedure code, modifiers, charge, units, and service date.

The HL segment is what builds that nesting. Each one carries its own number and its parent’s number. That is how the file says which claim belongs to which subscriber, under which provider. It is also why one 837 can hold hundreds of claims for dozens of patients.

Two-character qualifier codes do much of the remaining work. A qualifier tells the reader how to interpret the value sitting next to it. XX means the number that follows is an NPI, MI means a member ID, and PI means a payer ID. Same segment shape, different meaning, decided by two letters.

Around all of that sits the envelope. The ISA segment opens the interchange, the GS segment opens a functional group, and the ST segment opens the transaction set itself. They are the addressing on the outside of the parcel.

A worked example: Reading an 837 line by line

Below is a single-claim 837P for an imaginary wellness practice billing two therapy lines. Every name, ID and figure is illustrative, and a production file would carry more segments. The structure and the codes are real.

One thing to know before you read it. The delimiters are not fixed by the standard, they are declared in the file itself, and the sender chooses them. Almost everyone uses an asterisk, a colon and a tilde, which is why most 837s look like this one.

ISA*00*          *00*          *ZZ*BRIGHTPATH     *ZZ*CLAIMMD        *260817*1042*^*00501*000000317*0*P*:~
GS*HC*BRIGHTPATH*CLAIMMD*20260817*1042*317*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*PB0000317*20260817*1042*CH~
NM1*41*2*BRIGHT PATH WELLNESS*****46*BRIGHTPATH~
PER*IC*BILLING TEAM*TE*5125550142~
NM1*40*2*EXAMPLE HEALTH PLAN*****46*EHP001~
HL*1**20*1~
NM1*85*2*BRIGHT PATH WELLNESS*****XX*1999999984~
N3*140 CEDAR STREET~
N4*AUSTIN*TX*78701~
REF*EI*742555000~
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*RIVERA*MAYA****MI*EHP900123456~
DMG*D8*19880204*F~
NM1*PR*2*EXAMPLE HEALTH PLAN*****PI*EHP001~
CLM*INV-10427*135***11:B:1*Y*A*Y*Y~
HI*ABK:M5451~
LX*1~
SV1*HC:97110*90*UN*2***1~
DTP*472*D8*20260814~
LX*2~
SV1*HC:97140*45*UN*1***1~
DTP*472*D8*20260814~
SE*24*0001~
GE*1*317~
IEA*1*000000317~

Now the same file with every line translated.

Read it that way and the file stops being cryptic. Every segment is a box on the paper form: NM1*85 is box 33, HI is box 21, SV1 is a row in box 24. Want the full map? The National Uniform Claim Committee publishes a crosswalk between the 1500 form and the 837P, item number by item number.

If you ever have to open a file yourself, use a plain text editor. A spreadsheet will split it on the delimiters and scramble the result, and there is no header row to rescue you. Some clearinghouses also render the file as a readable claim summary, which is easier again.

The lifecycle: What happens after the 837 is sent

Sending the 837 starts a conversation of four transactions. Three files come back, and each one answers a different question about the same claim.

Editing happens in three passes, and CMS describes them plainly. First the receiver checks whether the file meets the basic requirements of the HIPAA standard. Fail there and the whole batch comes back. Next, each claim is checked against the implementation guide, and only the individual claims with errors are rejected. Only then is a claim tested against coverage and payment policy.

Those passes map onto the files you receive:

• TA1, the interchange acknowledgment. Reports a problem with the envelope itself. It rejects the whole ISA-to-IEA interchange, and you resubmit all of it.
• 999, the implementation acknowledgment. Says whether the file is valid X12. In 5010 it replaced the old 997, and it can accept, accept with errors, or reject.
• 277CA, the claim acknowledgment. Reports on each claim individually. Accepted claims come back with a claim number you can use to check status later.
• 835, the remittance advice. The electronic remittance advice arrives after adjudication, carrying the allowed amount, the payment, patient responsibility, and any denials.

A 999 is readable once you know three segment names. AK2 names the transaction set that had trouble. IK3 names the failing segment and its position in the file. IK4 names the element inside it. That is usually enough to tell your software vendor where to look.

Timing is quicker than most people assume. CMS says a 277CA usually comes back within an hour for a file submitted before 5PM, and within several hours after that. The 835 takes as long as adjudication takes, which for a clean Medicare claim means a couple of weeks.

One 277CA covers one file. Submit 100 claims and you get a single acknowledgment listing all of them, not 100 separate responses.

When an 837 gets rejected: What billers actually do

A rejection is not a denial. A rejected claim never entered adjudication, so no payer decided anything about it, which means there is nothing to appeal. You read the reason, correct the data, and send the claim again.

A denial is the opposite. The claim was accepted, processed, and refused, and it comes back with reason codes on the 835. That one you appeal or correct, depending on why it was refused.

Most 837 rejections come from a handful of fields, and they are dull ones:

• Member ID doesn’t match the plan. A digit dropped, a prefix missing, or an old card on file.
• Wrong payer ID. The right insurer, the wrong claims-routing ID, so the file reaches the wrong destination.
• Missing or invalid NPI or tax ID. The billing provider loop has to identify a provider the payer recognizes.
• Codes the payer can’t read. A retired CPT code, a diagnosis missing a character, or a service line pointing at a diagnosis that isn’t there.
• Subscriber details that disagree. Name, date of birth or sex not matching what the plan holds.

Two of those errors, the payer ID and the member ID, are worth catching before you submit. An eligibility check on the day of the appointment confirms both, and it costs seconds.

The rejection reaches you in one of three places: a clearinghouse portal, a report your software pulls down, or the claim record itself. Wherever it lands, the method is the same. Find the loop and segment named in the message, then look at that field on the claim.

Then there is the trap. A rejected claim was never filed, as far as the payer is concerned, so the filing deadline keeps running while it sits in your queue. Medicare’s window is 12 months from the date of service, and a claim returned as unprocessable does not pause the clock. Work rejections the week they arrive, not the month.

How Pabau builds and submits the 837 for you

Nobody should be typing segments. Practice management software like Pabau generates the 837P from the invoice you have already raised. The claim becomes a by-product of billing the appointment, not a separate job.

The pieces the file needs are already in the record. CPT and ICD-10 catalogs are built in, so codes come from a searchable list instead of memory. Diagnoses auto-populate from the client’s active Problems, which is the HI segment filled in without anyone retyping it.

From there the claim is validated and submitted through our Claim.MD integration, which reaches thousands of US payers. Acknowledgments and rejections land on the claim record with the reason attached, and every claim keeps its own activity history. When the 835 arrives, the ERA settles the claim automatically.

Send claims without touching a single segment

Pabau builds the 837P from your invoice using built-in CPT and ICD-10 catalogs, with diagnoses pulled from the client’s active Problems. Claims are validated and submitted through Claim.MD to thousands of US payers, and ERAs settle them automatically when payment arrives.

Book a demo

Conclusion

You will never write an 837, and you don’t need to. What changes is what happens the next time a claim bounces. “Rejected at the clearinghouse” becomes a specific field in a specific loop, and a fix you can make in a few minutes.

The habit worth building is speed. Rejections carry no appeal rights and no pause on the filing clock. The practices that get paid fastest read the 277CA the day it lands. That is a workflow question, not an EDI question.

Get the software to do the typing and the tracking, and keep your team on the part that needs judgment. Book a demo to see how Pabau builds, submits and tracks 837P claims from the invoice.

Continue your research

Wondering what the payer sends back? What is electronic remittance advice (ERA)? reads an 835 line by line, including how to spot a denial in the file.

Want to know what comes back the other way? What is a medical claims clearinghouse? follows the route your 837 takes out and the remittance takes back.

Tired of fixing the same rejections? What is a clean claim? covers the checks that stop a claim bouncing in the first place.

Got a denial rather than a rejection? Denial management in healthcare sets out the five-step process and the corrected claim versus appeal decision.

Patients claiming reimbursement themselves? What is a superbill? covers the document out-of-network patients send to their own insurer.

Frequently asked questions