Several posts earlier, I had described some of our Multi-GL Integration capabilities including the ability for the end user to define accounting treatment specific to their GL System(s), the ability to input data for accounting treatments upfront - while creating a payment or a forecast. I had briefly mentioned rules based application of a/c treatment to transactions as well.
Now consider typical usage of a treasury workstation.
Not every transaction is a payment originated by you and more importantly not every transaction is forecasted (even though you would like it to be). Adding a/c treatments to each transaction becomes cumbersome. Thus automated ways of application of accounting treatment to transactions become necessary, even critical to ensure STP for majority of banking transactions into the backend GL Systems.
Typically this is achieved by definition of rules in the backend, we take it a step further and let end users define these rules themselves.
In this post, we will discuss how we handle rule-based automatic application of accounting treatment to bank transactions so that these are ready to exported to backend GL System(s).
The picture above pretty much describes our approach. i.e we allow end user administrators in TS CMO to define rules per field (more than one rule per field is possible as well) in the input data. The system then applies these rules automatically to the transactions that it has imported. Note that you still have the ability to manually apply a/c treatment to transactions and any manually applied a/c treatment would take precedence over an automated rule that is setup - you will get your warning of course.
Now, let us look at couple of examples of possible rules.
A simple rule could be if Account # = XYZ, then apply the following a/c treatment - GL Number = 1000, assuming that your GL system uses one field called GL Number to book transactions.
A second example of a rule could be if Comments in the BAI file contains 'Vendor 5637829' and if transaction type is an wire, then apply the following a/c treatment Ledger=3425, Sub Ledger = 4527, assuming that your GL system uses 2 fields to define accounting treatment.
Putting it all together, what you have is flexible a/c treatments to ensure support for any GL system/ any number of GL systems and the ability to automatically apply a/c treatments that ensure that a very high percentage of your banking transactions have a/c treatment ready, to ensure accurate and fast integration to the GL system(s).
I hope this was informative and would like to hear your thoughts. Thank you for reading.