How to automatically or manually import your 835 SOB/EOB files into AngelTrack's billing system
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.
Retrieving EOBs from Your Clearinghouse or Outside Biller
If you communicate directly with your clearinghouse, i.e. if you do not use an outside biller, call your clearinghouse and request X12.835 EOBs (aka ERAs, aka SOBs, aka "electronic payment advice") from them. All clearinghouses can provide this if you ask and submit the necessary forms.
Once they arrange to provide you with electronic EOBs, AngelTrack can automatically retrieve them if the clearinghouse provides an SFTP server where the files will be posted. To learn more, read the Clearinghouse Uploader/Downloader Guide.
Whether you use the automatic downloader or you manually upload them, AngelTrack will store your EOBs for future reference.
Manually Uploading EOBs into AngelTrack
If you use a detached biller (one who does not access your AngelTrack cloud server), or if you do not use AngelTrack's clearinghouse uploader/downloader, you must collect the EOBs yourself and upload them into AngelTrack 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 biller will be able to furnish them -- probably straight from the clearinghouse.
For each EOB document, go to Billing home and select Import an EDI Document from the sidebar 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. See below for detailed help with the import process.
Auto+Manual Import by the Clearinghouse Downloader
If you use AngelTrack's clearinghouse uploader/downloader to retrieve your EOBs from your clearinghouse, the downloaded files will appear in the "Incoming Replies" tab of the Insurance Transmission Queue.
From that tab, AngelTrack will automatically import whichever files it can, moving them to the "Finished Replies" tab. AngelTrack will not automatically import any EOB that it thinks should be reviewed by a biller; it leaves these downloads marked "Pending manual import".
From there, a biller can click the "Import manually" link to open the downloaded EOB on the Import and EDI Document page.
A biller can also use the Import an EDI Document page (available on the Billing sidebar) to upload and import an EDI document from his or her computer, as will be necessary when not using AngelTrack's clearinghouse uploader/downloader, or when posting EOBs provided by a detached biller.
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.
After the manual import, the EOB will appear in the "Finished Replies" tab of the Insurance Transmission Queue. From there, the biller can review it and re-import it whenever they wish.
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 change 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:
- Date of service
- Patient first and last name
- Patient corrected first and last name (if any)
- Procedure modifier (in order to tell the difference between outbound and return trips)
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 post process 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 the Billing office and 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.
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 post-process 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.
Manual Override of Insurance Cardinal / Errors in EOBs
AngelTrack sometimes turns the Pri/Sec/Other overrides red, indicating that it needs the biller to double-check whether the EOB is truly from the primary carrier, or the secondary, or a tertiary.
This happens for all of the following reasons:
- EOBs routinely contain errors -- claiming to be primary adjudications when actually secondary. See Dealing With Medicaid-Integrated or "Dual Complete" Type Policies.
- AngelTrack's patient records may contain errors, and so an EOB may arrive from an unexpected secondary.
- AngelTrack's patient records may no longer match what was used to file the claim.
- EOBs often fail to specify the payor ID, leaving AngelTrack to guess who it's from.
- EOBs from a secondary sometimes wrongly claim the subscriber ID that is on file at the primary.
These problems mean that AngelTrack cannot always be certain who the EOB is actually from and therefore could accidentally misfile it as primary/secondary/other.
When there is any mismatch between the EOB's carrier type, cardinal (primary/secondary/other), payor ID, and subscriber ID versus those on file in the patient's record in AngelTrack, the EDI importer will show the Pri/Sec/Other override radio buttons and show a warning icon, so as to get the biller's attention.
Hover your mouse-over the blue 
, yellow 
, or red 
exclamation point, or click it, to see an explanation. Take care in resolving it; you may need to fix the patient record rather than override the EDI importer. In any case, it is important that EOBs are filed correctly, as the post-process workflow depends on it and so will make bad decisions if payment event records are incorrect.
Provider Adjustments [PLBs]
The X12.835 format allows for a carrier to issue a "provider adjustment", aka a PLB, which is an adjustment to the total amount of the check or EFT.
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:
Sometimes a PLB will include a link to a specific claim; other times they are general and so are not pinned to a specific claim. For example, a PLB for IRS withholding is a general deduction that does not connect to any specific claim.
AngelTrack imports all PLBs alongside the check/EFT data and stores it in your Check Register. For each transaction record in the check register, you can view the associated PLBs which explain any adjustments to the amount. AngelTrack will automatically set the "needs review" flag 
on any check-register transaction record that includes debit PLBs.
Interest payments
Interest payments -- PLB reason code "J6" -- are one of the many kinds of PLB adjustments that you might see. AngelTrack stores them alongside all other PLBs -- in the check-register transaction record for whichever check or EFT included the interest payment. If the interest payment is associated with a specific claim, then AngelTrack will offer you a link to the associated dispatch so that you can review the associated payment events.
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
After an import, a link will appear to review all dispatches affected by the EOB. Click the link to view them as a grid, including balances and any workflow suggestions from AngelTrack.
You can also review, edit, and/or delete the individual payment events created by the EDI importer. Use Payment Event Finder to identify all payment events that were created on a certain day; this is called the "Date of bookkeeping," and the Payment Event Finder 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.