An Overview Of Accounting Information And Straight Through Processing.

Rajiv Popat — Wed, 01 Dec 2010 12:18:05 GMT

There are multiple ways to assign accounting information to your transactions using Treasury Sciences. This is the information that typically flows through to your accounting system when you use our Cash Management Operations product for straight through processing. Each one of these methods is potentially a blog post in themselves but we thought we'd take some time and give you a quick overview of options that exist.

I. Accounting Information using Forecasts.

This by far is the most round about way to apply accounting information to your transactions. Having said that this is also the most convenient way if you are used to the idea of entering accounting information when you are creating EFTs or when you are forecasting the transactions that will show up first in your current day file and eventually in your prior day files.

The implementation is fairly straight forward. You go into the Treasury Sciences Administrator and define the fields that you want to pass on to your accounting system. While creating the fields you define the basic meta data associated with the fields. For example, the data type of the field, the validations associated with the field etc. Creation of these fields is also an interesting topic that we will cover in a separate post but for now, lets just say that the creation of these fields is a one time task that you can undertake using the user interface the product provides you with.

Once these fields are created for a subsidiary, every time that subsidiary makes a wire (or you make a wire on behalf of that subsidiary) you are presented with a form which allows you to enter values for these fields. The same form also shows up when you are making a forecast which you plan on reconciling with the BAI line items when the actual transactions are reported by the bank using the BAI file.

Now, assuming that you have entered the right accounting information for the forecasts and the forecasts get reconciled with the BAI line items (this could be either auto reconciliation or manual reconciliation done by a cash analyst) we have a means to getting to the accounting information you entered while creating the forecast, finding out which actual transaction it belongs to and exporting it out with your GL export which you can then feed into your GL system.

In cases where GL export is being created using prior day files we also provide reconciliation facilities (both automatic and manual) between current day and prior day BAI files. This allows us to get to the accounting information in the forecast which is reconciled with a current day transaction which is in turn reconciled with a prior day transaction.

All of this sounds complicated, but the bottom line is if you are creating the wires using EFT or entering the accounting information while doing forecast, the system pretty much does the auto reconciliation logic and figures out the accounting information that should move to your GL export automatically in most of the cases.

II. Accounting Information using Prior Day Files.

Approach I. works perfectly and accurately if you are into the habit of using our EFT product for wires or entering accounting information while forecasting. However, if you do not forecast extensively or are not in the habit of entering accounting information with each forecast we allow you to directly enter accounting information for each transaction that you see in your prior day file.

When the GL export runs on prior day file, all the accounting information that you entered here flows through to your GL export as soon as you run it or every time you schedule it.

This is fairly simple, but the downside of this approach is that you end up entering this information manually.

III. Automated Accounting Information Using Rules On Prior Day Files

This is the best of both the worlds where you do not rely on extensive forecasting by your subsidiaries and you also do not end up entering accounting information for each transaction which shows up in the prior day file. Here is how it works:

You start out by creating basic rules for automatically creating the accounting information. E.g. In the below rule I am stating that for any transaction where the amount is 36,000$ and the transaction belongs to an account which in turn belongs to Campus 2, I want two accounting information rows created. One will have the value "Portfolio1" and the other will have value "Portfolio2" in the accounting information field called PortfolioID which I had created using the administration console.

Note that here complex rules containing multiple other Transaction fields are also possible. The rules can be created using the following fields: [TransID], [ABA_Number], [AsOfDate], [ValueDate], [AcctNo], [TransCode], [Amount], [FundsType], [Description], [SameDayAvail], [OneDayAvail], [OverOneDayAvail], [CustomerReferenceNumber] [currency] [CompanyID] and even company name. Of course you can also club them up using and / or conditions.

Once the rules are defined and when the BAI files start coming in, the system automatically starts applying accounting information to your BAI files. Here is a sample BAI file which has an amount field containing 36,000$.

As soon as you import the BAI file (either manually or through an automatic feed that you have configured with the Bank) the accounting information rules engine kicks in and evaluates every single transaction in the previous day file with the rules that you have configured. If the transactions match the rules, the relevant accounting treatment is applied. You are of course free to modify the automatically applied accounting treatment or add new rows to it if you wish.

Once this accounting information is applied, is starts showing up in your GL export. The diagram below depicts an XML feed of the GL Export for the example mentioned in the points above.

The point: when we started off the product we started off with finite number of fields and one single way to getting your straight through processing to work. The first major step that we took towards making our accounting information piece stronger was to allow end users to define the fields that they wanted to flow through to their accounting system, themselves using a simple user interface. Then we allowed manual entry of values for accounting information fields (that the users had defined) while creating forecasts, EFTs and then manually as the previous day BAI files were imported.

Adding a full blown rules based component which allows you to define rules which in turn allow automatic application of the accounting information was the next natural step.

It is worth mentioning that besides supporting all these three methods we also allow you to mix and match these options. For example if you are doing a few forecasts we can continue to pick accounting information for those transactions from the forecast, for a few others that match the rules that you might have created accounting information gets automatically applied (which you can manually override) and for some transactions where none of the approaches are applicable you can continue entering the accounting information for transaction which show up in the prior day file.

We are continuously building cleaner, smarter and faster ways to get you straight through processing and a full blown rules based component which you can configure yourself to get the accounting information automatically entered, is our latest addition on this front.

Of course, we aren't stopping here. We plan on adding significant enhancements to all the three methods we discussed in this blog post and are continuously looking at newer and better ways to give you and accurate, hassle free and fast straight through processing that is not just powerful but fun to use.