A walkthrough of every part of payment events, their creation, editing, deletion, and workflow effects
Payment events are one of the three pillars of AngelTrack's billing system.
Transactions, Payment Events, and Ledger Entries
AngelTrack's billing system is built upon three pillars:
- A transaction in the check register represents a financial event that occurred outside of AngelTrack. For example, it might be a check or a wire transfer, or a credit-card payment.
- A payment event represents the application of that financial event to a particular receivable inside of AngelTrack.
- A ledger entry represents the carry-forward of that financial event into the future until there is a receivable to which it can be applied (and thus become a payment event).
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:
- One transaction record in the check register for check #1234 in the amount of $1500.
- Five payment events, one for each of the five trips, allocating $1400 among them.
- One ledger entry for the nursing home, in the amount of a $100 credit, as the carry-forward of the overpayment.
All Financial Activities are Recorded
The following financial activities are to be recorded as payment events:
- Insurance claims
- Insurance denials
- Insurance appeals
- Insurance approvals (payouts)
- Reversals (clawbacks)
- Service charges, such as fees for oxygen or bariatric
- Finance charges, such as late-payment fees and early-payment discounts
- Cash payments
- Credit card and ACH payments arriving in your Customer Self-Pay Portal
- Refunds
- Invoice payments
- Insurance pre-denials
- Insurance preapprovals
In each payment event record, all relevant details of the event are captured, including the counterparty (primary or secondary insurance, or the facility, or the patient, etc.), the date, dollar amounts, and so forth.
For each receivable dispatch, its payment event records will completely illustrate its journey... from date of service to final payoff. As a result, every receivable will have an audit trail showing exactly who paid what and when.
Payment Event Records are Flexible
Payment event records can be created, edited, deleted, and undeleted at will by anyone with biller permissions.
Whenever a payment record is created, edited, deleted, or undeleted, AngelTrack recalculates all balances and -- if necessary -- moves the dispatch to its appropriate place in the post-process workflow. For example, if a dispatch's only payment event is an "insurance claim filed", then deleting that record will move the dispatch back to the Insurance Filing Queue to be filed again.
Each Payment Event Has Three Critical Dates
For every payment event, there are three critical dates that have distinct meanings:
- The Activation Date comes from the underlying receivables. It stores the date and time that a crew actually ran the call and cared for the patient.
- The Date Received stores the date that a financial event legally occurred. This will usually be the same as that of any linked check/EFT in the check register.
- The Bookkeeping Date stores the date and time that a biller using AngelTrack recorded the payment event.
You must understand -- and always be aware of -- the difference between these three dates. To learn more, read the Critical Dates for Accounting explainer.
Payment Events Drive the Postprocess Workflow
The post-process workflow is driven by the billing fields (bill-to, payor, execution status, post-process status) and by the payment events on file.
For example, suppose a dispatch's billing fields are set like this:
- ☑ Billable is checked
- ☑ Bill insurance is checked
- Execution status is Complete, as ordered
- Postprocess status is Billing office -- meaning it has graduated from QA
- The payor is set to Insurance
It will therefore appear in the Insurance Review Queue for review. Once reviewed, where it goes next depends on whether or not it has a "Claim filed" payment event: if it doesn't, then it goes to the Insurance Filing Queue to be filed.
Most Payment Events are Created Automatically
Most payment event records are created by AngelTrack automatically:
- Paying an invoice creates an "Invoice paid" payment event for each affected dispatch and moves them along the post-process workflow in the appropriate direction (forward to "Finished" if paid in full, else back to the Billing office ). Read the Invoicing guide to learn more.
- Exporting run reports to an outside biller using the Insurance Filing Queue includes a button to record a "Claim" payment event for each selected dispatch.
- 837P batches being marked "transmitted" by the clearinghouse uploader/downloader creates a "Claim filed" event for each affected dispatch.
- Likewise, manually marking an 837P batch as "transmitted" using the Insurance Transmission Queue creates a "Claim filed" event for each affected dispatch.
- Likewise manually marking an 837P batch as "failed".
- Importing an X12.999 or X12.277CA reply using the Insurance Transmission Queue updates the "Claim filed" events for the affected dispatches to say "success" or "failed". Failures will push the claim back for re-coding.
- Likewise when the clearinghouse uploader/downloader automatically imports X12.999 and X12.277CA replies.
- Importing an EOB X12.835 creates the relevant "Insurance approval" and "Insurance denial" payment events for each claim in the EOB, as well as the appropriate movements along the post-process workflow. Read the Importing EOBs guide to learn more.
- Automatic service charges are "Service charge" payment events automatically created by the PCR whenever a crew member indicates that a billable medication or a billable lab test was administered.
- Customers paying their invoices using the Self-Pay Portal create the relevant "Invoice paid" payment events.
The above list represents about 95% of typical billing activity, so AngelTrack takes care of recording most of the payment events.
Recording Payment Events Manually
For all situations not handled automatically, you must create payment event records one by one. This is a critically important task, and you must take care to perform it for any financial transaction, including:
- Processing a cash payment collected by a crew.
- Processing a credit-card transaction swiped by a dispatcher, who then sent the receipt to the billing office to be recorded.
- Filing an insurance appeal (in the Insurance Appeal Queue).
- Importing a claim from a paper EOB (where no 835 is available for automatic import).
- Recording approvals and denials for round-trip claims, where an outbound trip and a return trip are filed together on a single claim. (We recommend against this practice.) AngelTrack's EOB importer will not process round-trip claims.
Locating the parent dispatch
When recording a payment event piecemeal, you usually need to locate the correct dispatch record first. For that, use the Record a Payment Event page (located in Billing Home) to locate the dispatch and then click the 
icon.
Or, if you've already got the relevant dispatch record open, then simply switch to the "Pmt Event" tab and click the 
icon next to the grid of payment events already on file.
Once you reach the Add Payment Event page, refer to the Piecemeal Payment Events guide to learn how to do it.
Editing or Deleting a Payment Event
If you make a mistake and wish to correct it, you can do so at any time. Payment events can be edited from any grid where they appear, including the following pages:
- Record a Payment Event's dispatch-finder grid
- Dispatch Edit's "Pmt Events" tab
- Payment Event Finder's results grid
- Payment Event Add's grid of existing payment events
Any place you see a payment event ID, you can click it to open the Payment Event Edit page.
You can edit any payment event and change any field, including the event type and date. Payment events can also be deleted and undeleted freely, using the grid in Dispatch Edit. When you delete or undelete a payment event, the dispatch's balance is recalculated, and it may consequently move to a different billing queue; you can find out where by checking the "Workflow location" field on the "Billing" tab. If it has been invoiced, the invoice may no longer be accurate and should perhaps be reissued.
Printing a Receipt
Any payment event record can become a printable receipt, suitable for printing or emailing to the customer. On any grid of payment events you will see two icons: 
opens a new browser tab and displays the payment event as a receipt suitable for printing on paper while 
exports the receipt to a .PDF file suitable for emailing.
You can also download a printable statement showing all active (non-deleted) payment events attached to a dispatch by clicking the aforementioned icons when they appear at the top-right corner of the payment events grid on the "Pmt Events" tab of Dispatch Edit.
Downloading receipts programmatically
Receipts can be programmatically retrieved from your AngelTrack cloud server using the following URLs:
| /payment/receipt/XXXX | Downloads payment event XXXX in receipt format, as an HTML document. |
| /payment/receipt/pdf/XXXX | Downloads a self-contained PDF of payment event XXXX in receipt format. |
For example, if your agency is named Acme EMS, and you wish to programmatically retrieve a PDF receipt for payment event number 42, you would use this URL:
https://Acme.angeltrack.com/payment/receipt/pdf/42