GL Integration

Configuring Centralized & Decentralized Cash Management in TS CMO - Part 2

Sujith Nair — Wed, 27 Jul 2011 21:40:44 GMT

Todays post continues that series of posts that describes the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. Today we will look at a case of decentralized cash management. (Please read the first post the describes a centralized scenario as well)

Decentralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the US and the Canadian subsidiary managing their cash.

A decentralized cash management scenario is described below - the organization receives BAI files from banks and proprietary investment updates in the US and Bank proprietary files for cash and investments in canada. Cash management and Investments are decentralized and taken care of by treasury users in respective locations. Also note that two backend GL systems that TS CMO synchronizes with are part of this setup as well. You can read more about the GL integration capabilities of TS CMO here and here.

To accommodate this need 2 Treasury Operations Entities are configured - Canada and US and respective users or roles and accounts or account groups are assigned. Now users in the respective organizations can perform their day to day forecasting, reconciliation, positioning, reporting and other functions w.r.t the specific set of accounts. As noted previously, not all accounts need to be used position and they can be classified as such.

A third Treasury Operational Entity called North America is created with access to all accounts and is assigned to a specific set of senior management users who would need access to data across the enterprise- Note that users using this entity will use it for view only access as the cash management functions are performed within the US or Canada entities created earlier. This configuration is described below.

It is important to note here that we went from centralized positioning (described in the previous post) to decentralized positioning purely via end user configuration. It is also important to note that in the event that a new user or set of users need to perform a cash management function, all an administrator has to do is to assign that user or the role of the user to the appropriate tag using a web browser.
We will look at the same feature set in even more complex scenarios in the next couple posts. Thank you for reading.

Configuring Centralized & Decentralized Cash Management in TS CMO - Part I

Sujith Nair — Mon, 18 Jul 2011 19:47:56 GMT

Over the next 4 posts, I will describe the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. To start, we will look at less complex scenarios and move towards the more complex models.

Centralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the entire enterprise.

The centralized cash management scenario is described below - the organization receives BAI files from banks in US and Bank proprietary files for cash and investments in canada and investments in the US, it has one backend GL system that TS CMO synchronizes with. You can read more about the GL integration capabilities of TS CMO here and here.

TS CMO allows for the configuration of this model via the creation of cash operations entities or tags. In this case, since all cash management is done by the central US organization one cash operations entity (tag) called North America is created by the end user. All bank and investment accounts across the enterprise (US and Canada) that are used for cash management purposes (note that accounts can be marked as not used for cash management as well, useful when concentration accounts are used for positioning) assigned this tag. Appropriate users or roles (groups of users) from US treasury organization are assigned this tag as well ensuring that they can position for US and Canada.

Once a US treasury user logs, he or she will be able to position both in USD and CAD for the enterprise without any custom development effort. Exports to the backend GL system can be automated . In the above example the only transformations needed are to transform the proprietary bank and investment formats into TS XML format and transformation of the TS XML GL export to Oracle GL Specific format. Note that these transformations are fairly quick and either the TS managed services team or your internal IT team could do that.

In the next post, we will look at a decentralized cash management scenario.

Payments, Positioning & Integration for Hedge Funds - Overview

Sujith Nair — Thu, 07 Oct 2010 06:07:41 GMT

The last 2 posts detailed out various aspects of our implementation for a large hedge fund. Todays post or picture provides an overview of the complete implementation - this picture is an early version of the picture that will appear in a case study of our payments and cash management system implementation for hedge funds. Will post a link to it when available. Meanwhile, here is the overview.

Automated Accounting Treatment, Cash Position, GL Integration, Hedge Fund Treasury, Hedge Fund Treasury Worstation, Multi bank payments, Netted Payments, Payment workflow implementation, Reporting, Straight Through Processing, Treasury Management , Treasury Reporting, Treasury Workstation, Treasury Workstation Reporting

STP - Automatic Application of Accounting Treatment

Sujith Nair — Tue, 03 Aug 2010 00:33:39 GMT

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.

Automated Accounting Treatment, GL Integration, Straight Through Processing, Treasury Workstation

Enterprise Straight Through Processing

Sujith Nair — Sat, 31 Oct 2009 00:11:45 GMT

If you have met with us, or watched either Ravi or I speak about our product suite or if you have spend even a few minutes on our website; you would know that our primary focus is to make sure our customers adopt a solution that meets their unique needs in the lowest possible timeframe.

We understand that most Treasury Management Systems out there provide most features and functionality that a typical organization needs. The challenge is and always has been in meeting those specific needs of a customer in the shortest timeframe possible.

In order to help faster adoption we provide fully functional trials of our product vs. an extended RFP process. We have also discussed extensively about the benefits of Prioritization. To reduce upfront training effort we provide web based videos of each feature within the product suite. From a technology standpoint, the solution was to create a product that is based on standards and one that was configurable.

Typical TMS's support a certain format of accounting treatment per transactions, the more configurable ones let you choose from multiple options they provide. This won't necessarily meet your specific needs. Secondly, if your organization has multiple subsidiaries chances are that you have to do extensive customization (read software development, consultants and time) to get automated connectivity to the multiple backend GL Systems. Finally, synchronization between backend GL Systems and the TMS could take considerable amount of time and resources to implement.

We believe that our solution addresses these issues in the best possible way. The rest of the post discusses these features.

Configurable Accounting Treatment per Backend GL System or Subsidiary

We let you configure the specific accounting treatment fields per subsidiary upfront using a web based interface. So, you can create 2 fields or 10 fields based on how you have setup your accounting system to capture data- essentially meeting the requirements for any backend system. The ability to configure accounting treatments per GL system or subsidiary eliminates customization that is typically required.

Capturing Accounting Treatment Upfront

We believe that the best place to capture accounting treatment is upfront- when you create a payment in EFT or when you create a forecast either using a web based interface or via a bulk upload of transactions or via an automated transmission (details on forecast can be found here). Accounting treatment entered by end users is used in the GL Export after these transactions are processed by the banks (received by our system via automated CD/PD files) - thereby ensuring STP to your GL System.

Rules based application of Accounting Treatment

This is another approach to capturing accounting treatment, via rules that you can create within our system. These rules will dictate what accounting treatment will apply to what transactions.

Standard XML Output to GL Systems

We use XML extensively throughout the product and we use if for our GL Export capability as well. Use of XML provides us the ability to create a standard output that can be easily transformed via adapters into any format- that any backend GL System may need. Note that we could write these adapters for you or you could write it yourself.

GL Synchronization

If you need GL synchronization services - eg: ability to replicate accounts created in your backend GL system automatically into the TMS, the integration is standardized and simple. You can push an XML files via secure web services exposed by our system. Additionally, if there is a need to accommodate true synchronization (changes made in either the TMS or GL, reflected in both systems), that is possible as well.

We believe that the ability to capture configurable accounting treatment, the use of standard formats and transformation capabilities reduce the time to integrate to one or more GL systems considerably. If you would like to hear more about these capabilities of have some questions or comments on our approach, please do let me know.