Payments Overview

OVERVIEW:

As the designers of DELPHI32, we believe that the most important feature of our software is the ability to specifically apply payments against individual sessions.  This feature/concept is described in detail in the section called Open-Item Accounting.  Do not proceed with the instructions on payments before reading and understanding the concept of Open-Item Accounting.  

Once you understand Open-Item Accounting, there are a few basic rules that you should follow when applying payments:

Rule #1) Payments are applied against the specific individual sessions for which they are paying. (Open-Item Accounting)

Rule #2) Only apply a payment against a session if you are 100% sure it should be applied against that session.

Rule #3) Never overpay a session.  

On the surface, these rules make sense.  In a perfect world, clients would always know how much their co-pays are and would always pay them at the time of the session.  Likewise, insurance payments and their associated adjustments (discounts/write-off's) would always pay the remaining balance for each session.

Unfortunately, we don't live in a perfect world.  The reality is that clients might pay too little, too much, not at all, or a larger amount for several past and/or future sessions.  Likewise, insurance payments may vary over time as the coverage changes.  This usually results from deductibles, benefit limits, or just plain errors.

A brief example will help demonstrate:  suppose you have session with a $100 charge and the client makes a $20 co-payment that you apply against the session.  This leaves a balance of $80 for the session.  After billing insurance, you receive an explanation of benefits with a payment of $70 dollars and a write-off/discount of $20.  If you pay the $70 against the session, and take the $20 write-off, the resulting balance will end up being negative $10 for the session.  Obviously, this is a violation of Rule #3 (Never overpay a session).

In addition, you applied the $20 client co-payment against the session when it turns out that the client really only owed $10.  This is a violation of Rule #2 which says to only apply money against a session when you actually know it should be applied against that session.  The fact is that you didn't really know how much the client owed for the session.  

At this point, we obviously have a bit of a problem:  DELPHI32 wants you to follow the above rules, yet in the real world there will be times when you receive payments and not know exactly where to apply them or how much to apply against any individual session(s).  The good news is that DELPHI32 handles this with an entry called an 'Advance'.  

An 'Advance' is simply a temporary holding area for any money you receive that you don't yet know where or how much should be applied against an individual session(s).  In the above example of the $100 charge, instead of making the $20 co-payment against the charge, you could apply the $20 against an advance.  Later, when you receive the insurance payment for $70 (and a $20 write-off), and you apply it against the session, the resulting balance for that session is $10.  At this point, you actually know what the client co-payment for the session should be, namely, $10.  Since we have a $20 credit sitting in the advance, we can borrow $10 from the advance and pay it against the session.  The end result is a session with a zero balance and an extra $10 sitting in the advance for use on another session or possibly a refund.  

Now that we have covered some of the situations surrounding payments, click on the link below for specific instructions on the specific topic. 

• Client Payments
• Insurance Payments
• Correcting Payment Errors
• Advances
• Applying Advances
•  

Other types of adjustments

• Discounts / Write Off's / Hold Harmless
• Applying Advances
• Co-payments Overview