Home User Manual Discussion Forum Search

FIFO Accounting  

This page is intended to act as a roadmap for where our patient accounting system is headed and how it should be organized. There have been extensive discussions over the years on how we should handle it, and this page attempts to incorporate all of those discussions. This page is only for very advanced users who are very familiar with our accounting method and are interested in improving it.

The Main Goals
Different users have expressed various goals that they have for the accounting system. Broadly, the main goals are:

FIFO so that provider income may be tracked.
Track paysplits by provider, patient, and procedure.
Line item accounting, where procedures get "closed" as they get paid off.
Aging option to handle pending insurance payments as either aged or not.

Some of these goals seem to conflict slightly with other goals. But we can all agree that FIFO is by far the most important.

Recent Changes
There was a major push in Version 5.2 to improve the income tracking by provider. These changes were made very carefully, and with a much bigger picture in mind.

Missing Features
1. Automatic splitting of patient payments by provider on a FIFO basis. When a patient makes a payment, the system should create the initial payment splits as accurately as possible. This means calculating which providers are owed the money based on FIFO. For now, splits should not be by procedure, but only by patient and provider.

2. Force users to split insurance payments.

Difficult Requests
One software should be able to handle any reasonable preference on accounting method. But some requests are more challenging than others. Here are some issues that we are still struggling to work into our planned framework:

1. Insurance payments are currently split by patient/provider/procedure as they come in. This automatically and very cleanly allocates the income to specific providers who actually did the work. We think this is a very accurate and elegant solution which does not need to be changed. But there is a request for the incoming payments not to be applied as indicated by the splits, but instead to be applied to the "bucket" and split on a FIFO basis according to all the other patient and insurance payments that have been made. The reasoning is that the provider should not be rewarded for doing treatment when the patient has not paid for previous treatment. The insurance payment should go to the provider who did the previous unrelated treatment. We could handle this by an automated income adjustment that is made at the time of entry of the insurance payment.

2. Delayed payments. We have had a request for payments that are made ahead of time to not show up in the income report until the treatment is completed. The reasoning here is that the provider shouldn't be paid for their work if they haven't yet done it. Our counter argument is that if the patient doesn''t do the work and gets a refund, then the resulting negative income entry would reduce the provider's income by the appropriate amount, and no harm would have been done. But this does not seem to satisfy the user, since they don't want the provider to have been paid in the first place.

3. Unallocated payments. One request is for some income to be applied to no provider at all. The reasoning seems to be that sometimes, you simply won't know whom to apply the payment to, so the system shouldn't force you to pick a provider. This does not seem like too difficult of a request, although it would very likely mess up most of the current income reports that we have. We don't see a clear enough reason for this request yet.

4. True line item accounting. This has been the most difficult request. One potential user in particular has been very persistent about this one feature for a number of years. DenTech, an older Unix dental software, is acting as the model for this request. Apparently, DenTech has a very good and accurate way of applying income to individual procedures as it comes in. Once a procedure is paid off, it is "closed". So the next payment gets applied to the next open procedure. When I asked how incorrect allocations were handled, the response was that they "simply make an adjustment". That seems like it might be messy, but in the end it is also the most accurate. This is what patients seem to always want to know, "what is this payment being applied towards?" This has been our model for the last few years.



Open Dental Software 1-503-363-5432