AngelTrack tracks each check and EFT separately from the many payment events that it creates for the affected dispatches, and likewise separately from any ledger entries that it creates.
The data is available in the Check Register, available under Billing Home. It is intended to be used to compare your bank records against AngelTrack's records in order to identify missed deposits.
AngelTrack will add a record to its check register under all of the following circumstances:
It is not possible to manually add a record directly to the check register. Instead, check register records are automatically created and linked whenever you create non-zero payment event records during the situations listed above.
If a transaction record in the check-register was created by an X12.835 EOB, then AngelTrack will also store the entire EDI so that you can review it later, and even re-import it if necessary.
To view the EDI associated with a transaction record in the check-register, open the transaction, find the "Source EDI" section, and click the "View" or "Reimport" links.
Check-register transactions, payment events, and ledger entries are the three pillars of AngelTrack's billing system. Here is how they relate:
For example, suppose a nursing home sends check #1234 for $1500 against an invoice containing five trips, but only $1400 is currently owed for those trips. AngelTrack will create the following records:
From the transaction record in the check-register, a biller can then browse to the payment events and ledger entries that it created. Likewise, from any of the associated payment events and ledger entries, a biller can browse to the initiating transaction record in the check-register.
To learn more about ledger entries, read the Ledger Entries Guide.
EOBs from insurance carriers will often include "provider-level adjustments" to the check amount. The adjustments represent carry-forwards, claw-backs, pended payments, and IRS withholding. They are called "PLBs" because PLB is their loop name when they appear in an X12.835.
Because PLBs are adjustments to the issued check amount, and not adjudications, PLBs do not become payment events in AngelTrack. Instead, PLBs are recorded separately, as part of the transaction record in the check-register, where their function is to explain why the check's monetary amount is different from the payment events (i.e. the adjudications) which it created.
For example, suppose Medicare issues EFT #2345 for $1400 against a claim for five BLS pickups, adjudicating a $300 benefit for each pickup but holding back $100 for a prior overpayment. AngelTrack will create the following records:
Thus the $1400 check is fully documented as five $300 benefit payments minus a $100 clawback.
You can review any transaction record's list of PLBs the same way you would review its payment events: Open the transaction record and then switch to the "Provider Adjust" tab.
Each transaction record in the check-register has a "Needs Review" flag that you can raise or lower as you see fit, indicating that somebody needs to back later and take a closer look at the transaction.
Flagged transactions will be reported in the "Check Register" dashboard on the Billing Home page, so that all billers can see when there are transactions needing review.
AngelTrack will automatically flag a newly-created transaction for review if it includes any PLBs.
At any time, billers can visit the Check Register, available under Billing Home, to view and edit the records.
For each transaction record in the register, you can also review all payment events and ledger entries that are associated with it.
Likewise, from any payment event or ledger entry which is associated with a record in the check-register, AngelTrack will offer a link to view the associated transaction in the check-register:
Records in the check-register are deleted and undeleted under the following circumstances:
AngelTrack will automatically mark as "deleted" any record in the check-register for which all associated payment events are marked as "deleted" and all associated ledger entries are zero'd out.
When this occurs as you are deleting a payment event, you will see an acknowledgement on your screen that the linked transaction record was also deleted.
Automatic deletion also occurs during mass-deletion events, such as changing an invoice from "paid" to "cancelled". When all of the invoice's associated payment events are marked as "deleted," and if the check is not associated with any other uncancelled invoices, then AngelTrack will automatically mark the transaction record as "deleted".
AngelTrack will automatically un-delete any deleted record in the check register whenever a biller un-deletes any payment event associated with it.
When this occurs as you are un-deleting a payment event, you will see an acknowledgement on your screen that the linked transaction record was also un-deleted.
If you edit a record in the check-register and delete or undelete it, AngelTrack will not automatically delete or undelete its linked payment events and ledger entries. You must review and delete/undelete them yourself.
Sometimes insurance carriers will ignore the "pay to EMS" directive in your claims, and will cut a check directly to the patient. If these checks are reported in the X12.835 EOB, then AngelTrack will add them to the check-register, even though they were deposited into somebody else's bank account.
To identify these, review the Check Register's "Payee" column for any entry that is not your company's name or bank account number. For each record you find, after you verify that it is correct and expected, edit the transaction record and mark it "deleted". It will then vanish from the check register... though you can retrieve it later by de-selecting the ☑ Hide deleted items tickybox.
Because the check-register, payment events, invoices, and ledger entries are all linked, you can use one check to pay multiple invoices, or multiple checks to pay one invoice, and AngelTrack will sort it all out.
To pay multiple invoices with a single check, simply follow these steps:
To pay a single invoice with multiple checks, simply follow these steps:
If you are recording a payment event or closing an invoice, and if you input a negative monetary amount to indicate a refund you payed, be sure to enter the check number that you printed, or the trace number of the EFT you sent, so that AngelTrack can record the transaction in the check-register.
You can refund multiple payment events and/or mulitple invoices with a single check or EFT; simply follow the instructions above, so that AngelTrack can link all the refunds together as a single record in the check-register. That way, it will be easy to compare AngelTrack's records with your bank statement.
If you process credit-card transactions in the billing office, these can be input in lieu of paper check numbers.
When recording the transaction as a payment event, or as a payment against an invoice, AngelTrack will ask for the check number. Simply change the transaction type to "Credit Card", and input the trace number.
Just as you can do with paper checks, you can apply multiple credit-card transactions to a single invoice, or a single credit-card transaction against multiple invoices, and AngelTrack will link all the records together.
While performing the chore of typing in a paper EOB, it is easy to include the check/EFT information. Here is where the Payment Event Add page asks for the data:
The EOB will probably contain multiple adjudications but only a single check or EFT that covers all of them. For each adjudication (i.e. for each claim), follow these steps to input it:
If you are using AngelTrack's Stripe integration to allow customers to self-pay their invoices, all such transactions will appear in your check-register as records of type "Stripe".
Each Stripe transaction has a unique ID, called a "payment intent", which acts like a trace number. These unique IDs look like this: pi_3KrQpjKU467ZQ1cF1Tq4fOPg
When you click a Stripe transaction in the check-register to open the Transaction Edit page, it will offer you a link to view the matching data in your Stripe dashboard.
In Stripe, a "payment intent" is a unique trace number that represents a customers attempt to pay you -- even if that attempt subsequently fails. Only if the payment is successful does Stripe then issue a charge ID, which looks like this: ch_2ZbTjrDZ557YL2eU3Po2bLMq
AngelTrack indexes your Stripe transactions by payment intent ID, not charge ID, even though AngelTrack is only recording transactions that are successful. This is because the payment intent ID is what is needed to link to the record in your Stripe dashboard.