837P Batch Management

The Insurance Transmission Queue and related pages exist to help you track and manage your batches of claims that are headed to the clearinghouse. When those batches are accepted or rejected, AngelTrack can automatically make the appropriate postprocess workflow moves for you.

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.

Managing your claim batches


Creating a Batch

There are several places in AngelTrack where you can select dispatches and create an 837P batch of claims:

Select all dispatches that you wish to include by ticking the checkboxes along the left-hand side of the grid. Then select the X12.837P Batch option and click the export button.

After creation, your new batch is marked "Pending", and it appears in the Insurance Transmission Queue. You will be immediately transferred to that queue, and your new batch's row will be highlighted in light blue.

Dispatches must be coded first

Obviously your dispatches must be coded first, before it is useful to export them as 837P documents. If you select an uncoded dispatch for your batch, AngelTrack will ignore it without issuing an error message.


The Insurance Transmission Queue

This queue keeps track of all batches that are in the wings... meaning: all batches that have not been cancelled, accepted, or rejected.

Until a batch meets one of those three fates, it is in the wings and must be tracked.

Downloading a batch from AngelTrack

The 837P batches you create are stored indefinitely in batch records, which are listed in the queue. You can download each 837P document by clicking the 837 suitcase icon. AngelTrack will send the file down to your computer. Downloading the file makes no changes to AngelTrack's databases, so feel free to download it as often as needed.

When you download the file from AngelTrack, you are saving it to your local computer. You can save it to any folder you wish; it doesn't matter which folder, as long as you remember where you put it, because you're going to be retrieving it in order to upload it to your clearinghouse.

Incidentally, the or 1500 suitcase icon will download to you a .PDF containing the claims as paper CMS-1500 forms, ready for printing.

Insurance Transmission Queue

Uploading to your clearinghouse

Your clearinghouse will provide a facility for uploading your 837P claim batches.

If you use Office Ally, then you will upload your claim batches using an ordinary SFTP client, which will transmit the files to Office Ally's SFTP server. (It will also be used later to download the 999, 277CA, and 835 replies.) AngelTrack Support can help you configure your SFTP client if you've never done it before.

If your clearinghouse has allocated you a pair of 'Upload' and 'Download' FTP shares, your IT person can configure a pair of folders on your desktop that automatically connect to those FTP shares. Once that's done, you can drag-and-drop right into those folders.

Other clearinghouses may also use SFTP, or perhaps they expose a web page where you will login and upload using your browser.

Record your uploads

As soon as you upload a batch to your clearinghouse, return to the transmission queue and click the "✔ Mark as transmitted" button to indicate that you've done so.

When you do that, AngelTrack will create all the necessary payment event records, and advance all the included dispatches forward to  Awaiting payment . The dispatches will then leave the Insurance Filing Queue, Insurance Exception Queue, or Insurance Appeal Queue, wherever they were while they awaited batching.

Cancelling a batch

If you cannot complete a transfer due to some external cause, or if you change your mind about it altogether, you can cancel the batch instead of marking it transmitted. Click the batch ID number to open the Edit Batch page, change the status to "Cancelled", and save.

You can even cancel a batch retroactively, after it was marked "transmitted". Doing so will delete all the "Claim" payment event records that it previously created, and will push all of its dispatches back to the queue for filing.


999 Replies from the Clearinghouse

X12.997 and X12.999 replies from your clearinghouse should be uploaded back into AngelTrack, using the Insurance Transmission Queue. AngelTrack processes the 999 documents to learn which batches were accepted versus which were rejected by the clearinghouse.

Uploading a 999 is easy. To get started, visit the Insurance Transmission Queue and click any + button.

It doesn't matter which one you click because AngelTrack will automatically figure out which batch the 999 belongs to. Just select the 999 document when prompted, and then AngelTrack will digest it and show you what's inside it. You'll see a list of one or more batches (usually just one), and for each batch, an indication of whether it was accepted by the clearinghouse. If a batch is rejected, AngelTrack will decode the explanatory error codes and show them to you.

If the 999 contains something that AngelTrack doesn't recognize, or is corrupted, that will be displayed in a "Parse Exceptions" column. If you see a parse exception and don't already know why it happened, please contact AngelTrack support so that the parser can be improved.

If everything is in order, press the "✔ Import" button. AngelTrack will then do all of the following:

999 documents with multiple transaction sets are supported. AngelTrack matches them up to its batch records using their transaction set control numbers carried forward from the original 837P batches. When generated in batches (as opposed to singles), AngelTrack transaction set control numbers always begin with "AU", and are in the format AUnnnnnnn, where nnnnnnn is the decimal ID of the associated batch record.

*Specifically, AngelTrack accomplishes this by marking the "Claim" payment event record as "Failed", and then pushing the dispatch back to  Billing office . These two steps will satisfy the search criteria for the Insurance Filing Queue, causing the dispatches to appear, unless they are parked.

Manually marking a batch as successful

If you are certain that a batch is accepted by your clearinghouse, then instead of uploading a 999, you can just click the + button in the 999 column for the batch. AngelTrack will mark the batch "Successful", and perform all the same bookkeeping as though you'd uploaded a clean 999.

Postprocess workflow movements caused by batch status

When a batch changes status, its dispatches will sometimes move forward or backward in the postprocess workflow. Here are the possibilities:

"Claim filed" payment event records will not be automatically created for the dispatches in the batch.
If any "Claim filed" payment event records already exist, then they will be updated to show "Pending transmission".
All dispatches in the batch will be moved back to  Billing office , if still Payor=Insurance and no newer insurance payment events are on file.
The dispatches will therefore remain in the Insurance Filing Queue until the batch is marked "Transmitted".
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already.
All "Claim filed" payment events associated with the batch will be updated to show "Transmitted".
All dispatches in the batch will be moved forward to  Awaiting payment , if still Payor=Insurance and no newer insurance payment events are on file.
The dispatches will therefore exit the Insurance Filing Queue.
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already.
All "Claim filed" payment events associated with the batch will be updated to show "Successful".
All dispatches in the batch will be moved forward to  Awaiting payment , if still Payor=Insurance and no newer insurance payment events are on file.
The dispatches will remain out of the Insurance Filing Queue.
"Claim filed" payment event records will be automatically created for the dispatches in the batch, if not already.
All "Claim filed" payment events associated with the batch will be updated to show "Failed".
All dispatches in the batch will be moved back to  Billing office , if still Payor=Insurance and no newer insurance payment events are on file.
The dispatches will then reappear in the Insurance Filing Queue.
"Claim filed" payment event records will not be automatically created for the dispatches in the batch.
If any "Claim filed" payment event records already exist, then they will be updated to show "Cancelled".
All dispatches in the batch will be moved back to  Billing office , if still Payor=Insurance and no newer insurance payment events are on file.
The dispatches will then reappear in the Insurance Filing Queue.

999 rejections

When a 999 returns a rejection, it can reject specific claims, or the entire batch.

999 rejections usually originate from your clearinghouse's claim scrubber. However, if you use a service that uploads your claims directly to a MAC or other carrier, then the 999 could come from the upload service (if it performs validations) or from the MAC or carrier itself.

When these rejections occur, AngelTrack will send the rejected dispatches back to the Insurance Filing Queue and mark them as "Failed", like this:

Failed claim

The "Failed" link leads to the EDI Batch Edit page for the rejected batch, in case you wish to review the 837P or the 999 or the 277CA (if any), in order to understand the reason for the rejection.

You can also return to the Coding page, where the decoded rejection will likewise be displayed:

Failed claim

Remember that a 999 can reject an entire batch, even for just one erroneous claim. When that happens, AngelTrack must therefore fail all claims back to the Insurance Filing Queue, even though only one of them is defective, because all of them must be re-batched. This is so because the clearinghouse/carrier did not accept any of the claims; they must all be submitted again, after the error is corrected.

If the rejected batch contained 100 claims, it may be difficult to find the one with the error, because all 100 will be sent back to the filing queue as failed. In this situation, you may open the Coding page for one of the rejected dispatches, and you'll see the rejection warning on the "Last 999" tab as shown in the screenshot above, but there will be no messages from the 999 for the dispatch you clicked.

If that happens, then return to the Insurance Filing Queue, and instead of opening up a Coding page, click on the "Failed" link. This will open the EDI Batch Edit page, where you can check the 999 to see which dispatch IDs contain errors:

Failed claim


Manually Cancelling a Batch, or Changing Its Status

At any time, you can simply tell AngelTrack whether the batch was accepted, rejected, or cancelled. AngelTrack will then make all the necessary adjustments to the underlying payment event records, and push dispatches forward or back in the workflow as outlined above.

To do so, visit the Insurance Transmission Queue and click the desired batch ID to open the Edit Batch page. Tick the desired status value -- "Successful", "Failed", or "Cancelled" -- and then save. AngelTrack will then perform all the necessary bookkeeping, just as if you'd uploaded a 999.

You can do that as often as you like, setting or changing the batch's status as you see fit. Whenever you do so, AngelTrack will re-adjust all the associated payment event records, and (if applicable) move dispatches forward or back in the postprocess workflow.

Likewise you can cancel a batch at any time, or uncancel it.

Be aware that changing a batch's status can impact the postprocess workflow locations of its dispatches, according to the table shown above.


277CA Replies from the Clearinghouse

X12.277CA replies from your clearinghouse should be uploaded back into AngelTrack using the very same process as you used with your X12.999 documents. It is just as quick and easy.

Unlike the 999 document, the 277CA document gives a claim-by-claim account of what was accepted versus what was rejected, and why. AngelTrack will parse it for you and save the contents alongside each dispatch that was in the batch. Common reason for rejection include:

As with the 999 imports, if the 277CA contains something that AngelTrack doesn't recognize, or is corrupted, that will be displayed in a "Parse Exceptions" column. If you see a parse exception and don't already know why it happened, please contact AngelTrack support so that the parser can be improved.

If everything is in order, press the "✔ Import" button. AngelTrack will then do all of the following:

277CA documents with multiple transaction sets are supported. AngelTrack matches them up to its batch records using their transaction set control numbers carried forward from the original 837P batches. When generated in batches (as opposed to singles), AngelTrack transaction set control numbers always begin with "AU", and are in the format AUnnnnnnn, where nnnnnnn is the decimal ID of the associated batch record.

Split 277CA replies

Normally your clearinghouse will return a single 277CA document, originated by the carrier, telling AngelTrack which claims were accepted for adjudication versus which claims were rejected. The 277CA document contains the AngelTrack batch number (in the format AUnnnnnn), and covers all claims in the batch.

However, some carriers return two 277CA documents:

  1. A primary 277CA, reporting claims that were accepted and rejected by the carrier's primary screening. The primary screening looks for simple errors such as missing datafields, invalid policy ID numbers, math errors, and invalid ZIP codes. The primary 277CA document appropriately contains the AngelTrack batch number (AUnnnnnn) so that AngelTrack can match it up. So far so good.
  2. A secondary 277CA, reporting additional rejections produced by the carrier's secondary screening. The secondary screening is more intensive, looking for data mismatches like inconsistent diagnosis codes and invalid modifiers. The resulting secondary 277CA document does not contain the AngelTrack batch number like it should; instead, it contains only claim control numbers and payor control numbers. It may also contain rejections of claims which were in different batches.

Because the secondary 277CA does not match up 1:1 with any batch in AngelTrack, AngelTrack does not store it with any batch, the way a primary 277CA is stored. Instead, its contents are divided up by dispatch, and stored in the matching claim payment event records.

The primary and secondary 277CAs are blended seamlessly by AngelTrack when you view the claim payment event record or when you are using the Coding page. In both cases, the "277CA" tab will show the secondary 277CA content if the claim has one, else it will show the primary 277CA content for the claim's batch. Therefore the biller is not required to sort or choose from multiple 277CAs: AngelTrack always shows you whichever one is relevant.

277CA rejections

Carriers will return a 277CA in order to reject specific claims from a batch. AngelTrack processes 277CA documents just like it does for 999 documents, so the "999 rejections" instructions just above apply likewise to 277CA rejections.

There is one additional wrinkle for 277CA documents. Some carriers will return an initial 277CA indicating that the batch has passed the first validation... but then, a day or so later, will return additional 277CA documents to reject specific claims.

This probably happens in situations where a carrier's own computer systems perform the first validation, and then devolve the claims to a subcontractor who uses an entirely different computer system. The subcontractor's computer system will perform its own validation, and issue its own 277CA documents for rejections. The subcontractor will return the 277CAs to the carrier, and then the carrier will return them to your clearinghouse, who will then return them to you.

AngelTrack handles this situation automatically. Simply upload all 277CA documents that you receive, regardless of their source. If a secondary 277CA later rejects a claim, AngelTrack will decode and display that rejection in the usual way (on the "277CA Decoded" tab of the rejected dispatch's Coding page).

After the first rejection, "duplicate claim" rejections

If your claim is rejected for whatever reason, and you correct the problem and re-file the claim, but then receive a "duplicate claim" rejection, it means your carrier is breaking the rules, and a minor workaround is needed.

Rejected claims are supposed to be exactly that: rejected. Unfortunately, some carriers are bad citizens: they store the rejected claims in their systems, causing subsequent rejection of any re-filed (corrected) claims bearing the same claim control number as the first (incorrect) claims.

If this happens to you, work around it by directing AngelTrack to use a fresh claim control number in the re-filed claims:

File an original claim

When re-filing, AngelTrack will normally tick ☑ Refile. Simply change it to ☑ Original, forcing AngelTrack to use a new claim control number. For example, the claim control number for dispatch 12345 was originally AD12345N1, but it will become AD12345N2 when you force a new claim control while re-filing.

Deciding not to upload a 277CA

Once a 999 document indicates that a batch of claims is accepted, a 277CA document can later reject individual claims from the batch while keeping the rest. If you are certain that all claims are accepted and thus no 277CA is needed, you can tell AngelTrack to stop waiting for one by clicking the + button in the 277CA column for the batch. The batch will then exit the Insurance Transmission Queue, on the assumption that all is well for the batch.


Reviewing Old Batches

At any time you can return to the Insurance Transmission Queue and view old batch records; just untick the ☑ Hide finished batches and ☑ Hide cancelled batches checkboxes to see them.

For each batch, you can view the raw 837P and 999 EDI data using the respective tabs in the Edit Batch page. You can even copy and paste that raw data into a third-party EDI viewer.


Manual Download of Batches from AngelTrack

At any time, you can re-download the 837P from a batch no matter how old. Simply visit the Insurance Transmission Queue, unhide completed batches if necessary, and then click the relevant suitcase icon.

You can also bypass all of AngelTrack's workflow UI, and manually download the 837P directly by a simple URL:

https://your_server_name.angeltracksoftware.com/batch/12345

That will download the 837P from batch 12345 right into your browser.

Likewise, to download a combined .PDF containing filled-out CMS-1500 forms for all claims in batch 23456, enter this URL:

https://your_server_name.angeltracksoftware.com/batch/pdf/23456

These URLs are accessible to anyone in the "Biller" role.

You can also download individual CMS-1500 forms using URLs; to learn more, read the Data Export guide.



Help Index - AngelTrack EMS Billing Software