Good morning. Let's continue our discussion of big, hairy, sweaty, ugly, dirty monsters. This topic today of the backdating is a little different than the others. It's not necessarily directly related but it is a big hairy monster. backdating doesn't have to do with reclass processing. It only has to do with balanced based systems.

You remember balances are made for a particular point in time they accumulate transactions for a particular point in time they answer a specific question as of that point in time. One of the problems with balances is that updating them becomes cumbersome. If I have if I have particularly when I have a back data transaction, back data transactions can happen for a lot of different reason. And perhaps things are just discovered late that there was something that happened perhaps the effective date of a transaction was agreed upon between the two parties to have happened earlier that it was recorded. There are mistakes made there system failures where things arrive late. All of those kinds of communication errors, all those kinds of things can create a situation where some business event was not recorded in the past and it should have been problem is if we go to what I've suggested daily adjusted trial balance, daily buckets, daily periods, to capture what the position is, as of the end of the day.

Then for every day, the transaction is backdated, I have incorrect balances. And so to really get my repository, my instrument ledger correct, I have to apply that transaction against those balances and update them. balances. So that problem means that I, if I have had 30 days that have passed, since the transaction should have been recorded, then I have at least 30 balances to update. That's if I have a single repository at a low enough level of detail for all my reporting, I would only have 30 balances to update. So now within the course of the financial daily cycle, I'm not just updating one balance, I'm updating 30 balances, that becomes challenging to do.

Now, if you add to that problem of backdating a problem of reclassification if there's been a reclass process that happened within that 30 days, so then what does that mean? So in other words, I have a rule change that happened somewhere like my department, my customers that roll up to a different department. So let's say I'm at the beginning of the next month, I recognize that I should have had the transaction should have been posted, let's say 45 days earlier, in the middle of the prior month, 15 days prior to my reclass happening where I changed the customer posting to a different to a different department. Then what do I do? Do I go back and I really technically should post it into the old department code, which was effective as of that point in time. I can do that by using my reference table to say what was the department code in effect on the time that this transaction was received?

Based upon my rules, I'm going to do a posting process, or I could do it based upon the reporting process. It was based upon the rules though I then have to update 15 days of balances in the old department code. I then need to determine That, oh, wait a minute, this department was reclassed to a new department and I need to follow that reclass process forward to for the next 30 days of posting into the new department for this back data transaction. You can see how doing this kind of process here, elongates the cycle and complicates the processing involved. Why is it necessary, it's necessary because we're using balances. balances tell us where things were as of a moment in time and having to walk them forward.

To keep them accurate. Data transaction is what creates that complexity the intersection backdating plus reclass processing makes it additionally complex.