Okay, so big, hairy, sweaty problems continue. Let's talk a little bit more about this reclassification problem and they act upon data modeling. When you look at a full General Ledger reclass process, a general ledger doesn't have any sort of an anchor to it, a general ledger has just as a big denormalized record and effect, all of the attributes that are the chart of account elements are appended to the balance that are of interest. Now that is, that's one way of managing the problem when a reclass process happens in the general ledger, when somebody looks at all of those values that classify a particular balance and decide that some portion of that needs to change in order to post it into a new position. And so they might change the rules in order to make those posts to a different balance. So The traffic count assignment, the accounting rules, engine rules get changed.

And now perhaps instead of posting to a contra asset account, it posts directly to a liability. And so that would be one way of handling it, any new transactions that come in are going to start accumulating in the liability section. Problems going to be that in the assets section, the outstanding contra balance in the assets section, it's going to stay there and it's not going to move it would be a stranded balance. That would mean that someone is probably going to have to do a manual reclassification process typically, where they go in and make a journal entry. They take the full balance as of the time that they change the accounting rules. They reverse it out of the Contra account and the asset and they post it to the liability account so they move the balance in some way.

You could do that in an automated way. But that's what a reclassification process looks like in the general ledger. What you have though, the anchor The descriptor for the balance is the full set of chart of account elements that describe that balance. And that's what the anchor is and the general ledger. Now, if we want to do something a little bit different if we want to be able to produce a recast view, and a switch of view at the same time, we've talked about being able to use a join a date effective join in order to accomplish that objective. What that requires is that for one piece, we have to have a date as a key to do our join.

Our transactions should include a date, maybe that's another topic for another time, value, date, transaction, date, posting date, those kinds of dates are all things that could be used in this process. But we have to have some sort of a date, then we have to have another attribute of some kind that describes our key, our joining processing, in many instances, the most of the attributes we've been talking about. In the chart of account, things that like legal entity, and cost center, those things or branch, maybe those sort of things typically don't change on each balance that are maintained for a particular customer. Those, those balances are classified by the account, the general ledger account and gives you the kind of balance, whether it's fees, whether it's principal, whether it's sales, whether it's receivable, all of those kinds of things. Our accounts are our ledger accounts that describe balances.

But many of the other attributes associated with a customer contract don't change on each one of the balances. So in effect, I could have in my instrument ledger, I could have repeating values on multiple rows of the instrument ledger that I don't have to repeat. I could normalize In a sense, I could put them on a different record, store them once and join to that value to find what those are. That would allow me then if I use the date effective join, if those values change, I have the ability to produce a reclass view, pardon me a recast view or a switch view. Depending on which date processing I use to do the join. So in a certain sense, a normalization process and the instrument ledger can help us to reduce data redundancy, can help us model the data more effectively for processing purposes and can allow us to see the values as they change over time, in either a recast or a switch view processing.