Importing X12.835 EOBs

AngelTrack will automatically process your X12.835 format EOBs into payment events.

You also always have the option of recording payment events by hand, piecemeal. While piecemeal recording is normally only done for cash payments, you can process your EOBs that way too if you wish -- one claim at a time.

To learn about X12.999 and X12.277CA documents, which are related to EOBs and to claim batches, read the Batch Management Guide.

If you are not yet familiar with the numbers 837P, 999, 277CA, and 835, or if you do not yet know how your billing software, your clearinghouse, and the insurance carriers all work together, then read the EDI Primer first.

Loading a dump truck


Retrieving EOBs from Your Clearinghouse or Outside Biller

If you communicate directly with your clearinghouse, request X12.835 EOBs (aka ERAs, aka SOBs) from them. All clearinghouses can provide them, if you ask.

Likewise if you use a detached biller (one who does not access your AngelTrack cloud server to process your EOBs). You must collect the EOBs yourself for processing. Your detached biller may not be in the habit of providing EOBs in electronic format, but it is a reasonable request and any competent biller will be able to furnish them -- probably straight from the clearinghouse.

Keep your EOB files in a safe place for future reference.


Uploading EOBs to AngelTrack

From Billing home select Import an EDI Document to open the importer. You will be prompted to select a file from your computer, in the usual way. Feed in each EOB document, one at a time.

The importer will digest each document, showing a summary of its transaction sets and a grid of its claims. The grid of all claims is "flattened", meaning it lists all claims in all transaction sets in the 835 document.

The importer will attempt to filter out claims for NPIs other than your own, in case you received the wrong 835 document. If you don't see any claims for your NPI, verify that the document was intended for you. If you are certain the document is meant for you, then uncheck ☑ Hide claims from NPIs other than ours. Unchecking the box will forcibly show all claims in the document regardless of the supposed provider NPI.

Matching up EOB rows to AngelTrack dispatch records

Every claim record in the 835 document must be matched with a dispatch record in AngelTrack. If AngelTrack was the one that coded your claims (i.e. was the one that generated the 837P documents), then the match-up process is automatic and foolproof... provided your clearinghouse and the underwriters did not mangle AngelTrack's control numbers during processing.

If your billing office or outside biller used a different software application to file the claims, then the 835 document will not contain AngelTrack control numbers: instead it will contain the other software application's control numbers instead. In that case, the importer will attempt to match up claims to dispatch records by looking at:

If the match attempt fails, then the claims grid will say so. You must then record the payment event manually, using the Record a Payment Event page.

Round-trip claims not supported

If your biller or billing software filed a round-trip as a single claim (with four service lines instead of two), AngelTrack's EOB importer will refuse to import it. You must import the claim manually, into two payment events (one per trip). No matter what biller or billing software you use, AngelTrack strongly recommends you file each round-trip as two separate claims.

Processing rules

An integral part of the process of importing an EOB is advancing each dispatch along the postprocess workflow. How a dispatch moves along the workflow depends on what came back from the clearinghouse, as we know. For example, when a denial comes back, the dispatch should move back to  Billing office  and should appear in the Insurance Appeal Queue for re-processing.

The importer decides how to adjust each dispatch's progress through workflow according to automatic rules. The aforementioned example -- an appealable denial sends a dispatch back to the Insurance Appeal Queue -- is an example of a rule... and there are many. Each row in the importer's claims grid displays the decision made by the rule set. You must double-check that each rule-driven decision is correct under the circumstances.

Manual override

If you disagree with one of the rule-driven decisions, then uncheck the row (i.e. do not process the row) and record the payment event manually.

If the processing rules are consistently making the wrong decision for your claims, please contact AngelTrack support. We frequently improve and expand the processing rules based on customer feedback. The end goal is to build a set of processing rules that can correctly process 99% of claims in an 835; the goal is not 100% because there will always be odd situations requiring manual intervention.

When you contact AngelTrack support, have your EOB ready to send in. We will need it in order to determine why the software made the wrong decision.

Click "Import Claims" when ready

When you've unchecked -- and manually recorded -- all rows not eligible for automatic import, click the "Import" button to import the rest. AngelTrack will digest each selected claim, creating a payment event record for it and storing the relevant section of the 835 document with it (in case you wish to review the raw 835 later). The proposed changes to postprocess workflow will also be made.

When the importer finishes, the page will refresh, and you should see that all selected rows now report that they have been recorded as payment events. AngelTrack will refuse to import an event more than once, so there is no harm in processing an EOB twice, or in processing duplicate or overlapping EOBs. AngelTrack will make sure that no erroneous duplicates are created.

"Falsely reported as primary" / Bad 835s returned by TMHP

Texas Medicaid & Healthcare Partnership issues bad 835s, containing the following errors:

When importing one of these EOBs, the "Claim Status" column will contain the message "Processed as secondary (falsely reported as primary)", indicating that AngelTrack has detected a TMHP file and has automatically corrected it.


Provider Adjustments / PLB Segments

The X12.835 format allows for a carrier to issue a "provider adjustment" which is independent of any claim or service.

Inside the X12.835 document, this adjustment is recorded in the PLB segment, which follows after all claim loops.

If your EOB contains any such provider adjustments, AngelTrack will decode them and then display them in a special chart just below the chart of the EOB's transaction sets:

EOB provider adjustment

Unfortunately, because provider adjustments are unconnected to any claim (i.e. unconnected to any dispatch), AngelTrack cannot import them into payment event records as would otherwise be appropriate. You must decide how to book the monetary amounts. It may be necessary to call the provider, read them the "Payor Control" number shown by AngelTrack, and ask them where the charge or refund originated.


Parking

If you notice something amiss during the import of an EOB, you can immediately park the affected dispatches as you see fit. Simply click the parking icons that appear in the right-hand column of the claims grid.

You can still import EDIs into parked dispatches; parking has no effect on EDIs, payment events, and balances. To learn more, read the Parking guide.


Reviewing the Payment Events Afterward

At any time, you can review, edit, and/or delete the payment events created by the importer. Use Payment Event Finder to identify all payment events that occurred on a certain day: every 835 document specifies a "Date Processed", and this date is recorded in AngelTrack's payment event records as the date the event occurred. (The importer displays this date at the top of its page.) So you can use that date to view all payment events created by the importer.

As usual, all payment events are editable, deletable, and undeletable. If there is a mistake, edit the record and fix it, or delete the record and re-import the EOB.


Understanding EDI Control Numbers

If you look inside an EDI document, you will see EDI control numbers. These are used in the exchange between AngelTrack, your clearinghouse, and the underwriters, in order to match up records returning from adjudication.

For example, the following 999 document is a reply to an AngelTrack 837P batch; notice the AUxxxxxxx number indicating the originating 837 batch's control number:

ISA*00* *00* *ZZ*310496583 *ZZ*1932587909 *151116*0912*^*00501*000000010*0*P*:
TA1*000000010*151116*0912*A*000
GS*FA*330897513*1972989929*20151116*0912*292298064*X*005010X231A1
ST*999*0001*005010X231A1
AK1*HC*10*005010X222A1
AK2*837*AU0000010*005010X222A1
IK5*A
AK9*A*1*1*1
SE*6*0001
GE*1*292298064
IEA*1*000000010

AngelTrack's EDI control numbers follow a certain format and are easily recognizable. Read the EDI Control Numbers guide to learn more.


Using the Workbench to Diagnose Problems

The X12.835 Workbench is a handy tool for inspecting 835 documents and identifying problems. You can paste the contents of any 835 into the workbench to be digested. The workbench will display any exceptions during the digestion process, and also display a chart of all claims (for all transaction sets) in the document.

If you encounter an 835 document that you are certain is correct, yet the workbench chokes on it, please contact AngelTrack support. Every clearinghouse is different; every clearinghouse has its own idiosyncrasies in how it writes its 835s. We will be glad to analyze your 835 document and make the necessary improvements to AngelTrack in order to support your clearinghouse.



AngelTrack Help Index - AngelTrack Support