|
Accrual Basis Accounting
Most small dental offices use cash basis accounting rather than accrual basis accounting. This page is an attempt to discuss how to use Open Dental in an accrual basis accounting scenario.
Current Guidelines
1. At the bottom of the Security window, use the lock date feature to 'close out' each month.
2.
After locking, run monthly reports. Never unlock to make historical changes.
3. PPO writeoffs: See Ins Plan Types, PPO section where it discusses reports. Use method 1 (insurance payment date) to avoid changing history.
Unearned Income
Unearned Income Type is a PaySplit field. This allows flagging some Payments as prepayments. The purpose of this flagging is because offices that use accrual accounting must not yet report that as income. So the prepayment total can be subtracted from income for accounting purposes. In Definitions, you can set up different types of prepayments for accounting purposes. Once a paysplit is flagged as unearned income, it will show in red at the top of the Account module. The patient account balance will be affected by unearned income split in the normal manner so that the patient can see that they have prepaid. To remove the unearned income from an account, a second entry should be made at a later date. The second entry is a zero entry with two balancing paysplits, one to reduce or remove the unearned income, and the other to increase income. Two Reports show unearned income liabilities (total amounts) and unearned income activity (date range).
Frequently, offices will use a dummy Provider to track unallocated income. If cash basis accounting is used, there's no point in going to the extra work of also tracking unearned income as described above. Tracking unallocated income is much simpler. The amounts are temporarily assigned to the dummy provider while the work is in progress. Once the work is complete, the amounts are reallocated to the proper providers. This is usually done as a second zero sum entry using two balancing paysplits.
Future Improvements
The improvements in this section are not set in stone and there is no possible way to estimate if or when
they might be added. The intent is for this to stimulate discussion to help guide future programming.
Interactive Aging 'Report'
The aging and A/R reports need to be merged into one interactive window. The columns should be selectable. The data should be exportable. The table would be generated on screen first and then printed if needed. Should be able to jump to patient accounts. The following additional changes have been requested for the aging report:
72: A/R Report.
396: PPO writeoffs by procedure date
27: PatNum, BillingType
331: Sort by amount owed
474: Exclude small amounts
720: Payment plans show
937: One page summary of totals
938: Show percentages of totals
1180: Back dated reports.
-Column for last statement date.
-Show only patient portions so that list can be much shorter.
Many of the above requests do not have any votes yet. But making the A/R report interactive would provide a good foundation for implementing these requests.
Request #1975
Aging calculated by patient rather than by guarantor. This would allow better filtering by provider. Taking it one step further, it could be calculated at the individual transaction level. This would allow ideal filtering or grouping by provider instead of by patient.
Request #712
Locking history. In other words, historical entries would have the appearance of being editable, but what would really be happening in the database would be the addition of
more rows. No row would ever be changed or deleted, no matter what permissions the user had. This is the same technique currently used to allow editing of procedure notes, while still keeping a perfect historical record.
Request #50
More automation of patient payment splits by provider or procedure.
This would allow allocation of every payment split to a specific procedure. Aka open item accounting. The trick is that when insurance comes back, the original patient payment splits might need to be reallocated. And of course, that wouldn't be good for accrual accounting unless absolute history locking were in place as described above.
Request #719
Change aging behavior. Would follow request #50 above. Because payments would be tied to specific procedures, aging calculations could take advantage of this rather than using FIFO as we do now.
|