Converting Paper Claims to 837 Files, Step by Step

Converting paper claims to 837 files means reading each field from a CMS-1500 or UB-04, checking it, mapping it to the matching X12 loop and segment, and building an electronic claim a clearinghouse will accept. A CMS-1500 becomes an 837P and a UB-04 becomes an 837I. The work succeeds or fails on the quality of the extracted data.

Which paper claim becomes an 837P and which becomes an 837I?

A paper CMS-1500 becomes an 837P, the professional claim, and a paper UB-04 becomes an 837I, the institutional claim. The CMS-1500 is filed by physicians, practitioners and suppliers. The UB-04, also called the CMS-1450, is filed by hospitals and other institutional providers. The form tells you which file to build.

The link between each form and its file is documented on both sides. The NUCC 1500 Reference Instruction Manual says its instructions align with the X12 Health Care Claim: Professional (837) technical report, version 005010X222A1. Chapter 25 of the Medicare Claims Processing Manual covers the codes needed to complete "the Form CMS-1450 and compliant Accredited Standards Committee (ASC) X12 837 institutional claims." Chapter 24 of the Medicare Claims Processing Manual lists the current versions: 005010X222A1 for the 837 professional claim and 005010X223A2 for the 837 institutional claim.

The 837P vs 837I choice changes the data you need. An 837P is built around service lines with procedure codes, place of service and a rendering provider. An 837I is built around a type of bill, revenue codes and facility data. Chapter 25 describes form locator 4 on the UB-04 as a four-digit type of bill code that identifies the type of facility, the type of care and a frequency code. Nothing on a CMS-1500 supplies that value.

A third version exists for dental claims, the 837 dental claim, listed in the same Medicare chapter. Dental paper claims are outside this post. The post on who files a CMS-1500 claim and who files a UB-04 claim covers how to tell the two forms and their filers apart.

Paper claim data an 837 file cannot do without

An 837 file cannot be built without the billing provider's identity and NPI, the subscriber and patient, the payer, the claim total, at least one diagnosis code and at least one service line with its date, code and charge. A missing value or one in the wrong format makes the file fail before any person reads it.

The table below maps 14 CMS-1500 boxes to their 837P loop and segment at a high level. Rows marked CMS come from the CMS MLN job aid on CMS-1500 and 837P code sources. Rows marked Noridian come from the Noridian JE Part B crosswalk of CMS-1500 items to 837 loops and segments, a Medicare contractor's guide that notes it is not all-inclusive.

Format rules come with the data. The CMS-1500 instructions in chapter 26 say not to insert a period in an ICD-10-CM code and allow up to 12 diagnosis codes. The NUCC manual says a claim with more than 12 diagnoses or more than 50 service lines must be split. The NPI must be 10 digits, and the CMS paper on NPI check digit requirements explains the Luhn check that its last digit must pass. The full structure of an 837 file, with its envelopes and hierarchy, belongs to the developer integration category.

Paper claim to 837 conversion steps

Paper claim to 837 conversion runs in six steps: extract the fields from the scanned form, validate them, map them to loops and segments, generate the file, send it to a clearinghouse, and read the acknowledgments that come back. Skipping validation is the usual reason a converted batch fails.

1. Extract

Extraction turns the scanned page into named values: member ID, patient name, each diagnosis code, each service line. The values need to stay tied to their place on the page, so a reviewer can check any one of them against the image. Schema Care's part of this work is the reading: it pulls CMS-1500 and UB-04 fields, scores its confidence in each, and puts the doubtful ones in front of a reviewer, which the human review section of the homepage walks through. Building the 837 file is a separate tool's job.

Multi-page paper claims need one extra rule at this step. The NUCC manual says only the diagnosis codes on the first page may be used, and they must be repeated on later pages. An extractor should therefore read item 21 once, from page one, and treat the copies on later pages as a check. If the later pages show different codes, the claim goes to a person before mapping. The service lines from every page are joined into one claim, so the page count must be confirmed before the claim moves on.

2. Validate

Validation runs format and cross-field checks before mapping. Dates must be real dates. Codes must match their code set's pattern. Each pointer in 24E must point at a filled line in item 21. Line charges must add up to item 28. The fields that fail most often on paper claims are covered in the guide to common claim form errors that cause rejections.

3. Map

Mapping assigns each validated value to its loop and segment, as in the table above. It also fills values the paper form does not show directly, such as the qualifier that says an identifier is an NPI, or the payer's electronic ID from the clearinghouse's payer list.

4. Generate

Generation writes the file: interchange and group envelopes, one transaction per batch, and one claim per 2300 loop with its 2400 service lines. Chapter 24 describes an accepted claim as "a unit of work, 2300 loop followed by a 2400 loop."

5. Send

The file goes to a clearinghouse or directly to the payer, through whatever connection that trading partner supports.

6. Read the acknowledgments

Acknowledgments come back in layers, and each needs a person or a rule to act on it. The next section covers what each one means.

Why do converted paper claims bounce back as 999 or 277CA rejections?

Converted paper claims bounce back as 999 rejections when the file breaks X12 syntax or a required element is missing, and as 277CA rejections when a single claim fails the payer's business edits. A 999 can reject a whole transaction. A 277CA rejects individual claims inside an accepted file. Both mean the claim was never adjudicated.

Medicare describes the layers in chapter 24, section 50.3.3. Its contractors' front end decides whether an edit failure "necessitates the rejection of the entire transaction set via the ASC X12 TA1 interchange acknowledgment or ASC X12 999 implementation acknowledgment," or whether the errors pass on for claim-level rejection through the 277CA claim acknowledgment. Errors passed on that way are called "Accepted, but Errors Noted," the 999E.

The 999 tells you about structure. A converted file can fail here if a segment is out of order, a required element is blank, or a value has the wrong length. When a mapping tool writes an empty NM109 because the paper NPI was unreadable, the whole transaction can come back. That is why validation belongs before generation.

The 277CA tells you about each claim. Chapter 24 says the Medicare front end performs code set editing, Medicare-specific editing and duplicate submission checking, and returns a claim control number on the 277CA for each accepted claim. A converted claim with a diagnosis code that does not exist, a place of service the payer does not accept, or the same data as a claim already received will be rejected here.

As an example, a fictional batch of 40 converted claims comes back with a 999 marked accepted with errors and a 277CA listing two rejected claims. One, for example claim number PCN-20260311-07, has an invalid diagnosis code where a 0 in the paper form was read as the letter O. The other repeats a claim the office already sent electronically last week. The fix for the first is a corrected field. The fix for the second is to drop it.

Rejected claims go back to the start: correct, revalidate and resend. Chapter 24 counts resubmitted previously rejected claims as initial claims, so for Medicare they must also go electronically.

Paper claims that should not be converted to 837 files

Some paper claims should not be converted to 837 files: claims for payers that only accept paper or have no electronic connection, claims whose required attachments the payer cannot receive electronically, claims already sent another way, and claims too damaged or ambiguous to read with confidence. Converting these creates rejections or duplicates.

Payers that require paper come first. A small plan without a clearinghouse connection, or a program that asks for paper for a specific claim type, will not accept the file. Keep a list by payer and check it before conversion.

Attachments are the next test. Chapter 24 describes the PWK segment as the "electronic staple" that connects paper documentation to an electronic claim, sent alongside the claim with a cover sheet from the Medicare contractor. Where a payer supports this, the claim can still go electronically. Where it does not, and the attachment is required, the claim may need to go on paper with the attachment behind it.

Duplicates are the quiet risk. A paper claim that arrives after the same claim was keyed and sent will create a duplicate if it is converted again. Match each paper claim against recent submissions by patient, date of service and charge before you convert it.

Unreadable claims belong with a person. A handwritten form with crossed-out codes, a fax with a missing corner, or a claim with conflicting totals should go to review, not to the converter. The guide to claims intake automation shows how to route those at the door, and the plan in claims processing automation shows where conversion fits among the other claim tasks a billing team can automate.

Medicare paper filers also have a rule to check. Chapter 24 says the electronic filing requirement covers initial claims, including claims with paper attachments, except from small providers and in listed exceptions. A provider that qualifies for an exception may file paper, while one that does not has to send the claim electronically.