Let’s say you have a post date for payments in May. Whatever you posted in May should be closed and should never change because you’re capturing the time at which a function was performed, and you can’t time travel back to do that. However, some systems allow this, and the problem is that it makes reporting and reconciliation a nightmare.
For instance, if you’re a revenue cycle company charging a client based on what you posted in a particular period, you would post everything in May, and at the beginning of June, send an invoice showing what was collected. If you then post something in September that is retroactively dated back to May, those collections never get reported to the customer. You’re not collecting that data when you report on the September collections, and you’re not retroactively going back and evaluating what has changed in those postings. Reconciling this is a nightmare, and you’re losing payment and revenue as a result.
The Need for Proper System Functionality
This issue could arise in all kinds of areas where locked periods are crucial. It’s challenging to track, and from a data perspective, it’s a giant nightmare. So, why do these systems allow this? It seems like very poor accounting practice. You shouldn’t be able to retroactively time travel. The check date could be May, and there’s no reason you shouldn’t capture all of these variable dates and have that information so you can slice and dice the data as needed.
Takeaways
You should be able to post in September with a post date for September, a check date for May, and the ability to analyze cash flow and payment posting accordingly. This way, you can answer all relevant questions without mixing data or overwriting one date with another, complicating your workflow. Make sure the system you’re using doesn’t do weird things like this, or ensure you have a data warehousing or analytics solution that can account for these kinds of problems and handle metadata issues effectively.
