In the Beginning
In the beginning, the bank account was created. As companies grew, they started using many accounts at many banks. To manage/ account for this valuable asset (i.e., cash), companies relied on general ledgers and a financial close process to provide the information that their cash was “safe” and being used for the appropriate corporate purpose.
All went well until companies realized that visibility into cash and a company’s ability to service its liabilities (its liquidity position) was only “right” once every 30 days, but markets change every day. Additionally, waiting days (or weeks) after a monthly close, to know if they had “enough” cash, subjected a company to opportunity / real costs (e.g., missed vendor discounts, over borrowing, under investing, bad debts, FX losses, etc.).
As a result, the treasury management system (TMS) was born in the late 1980s primarily to serve as a daily, up-to-date cash subledger that connected to banks and imported the latest data about cash transactions and balances.
This addressed:
- Integrating disparate bank systems
- Detail for incoming or outgoing bank transactions, providing a complete picture across all bank accounts.
- A process for companies to reconcile their book / bank cash faster, an important step in any financial close.
The TMS today
Over time a TMS added more features like executing payments, maintaining bank account lists / signatories, tracking debt and investment balances / transactions, managing FX exposure, creating interest expense accruals which allowed a TMS to become more functional.
Using “real” database features, they were structurally more organized and secure than the usual disparate set of bank systems, spreadsheets, emails or hard to maintain in-house designed systems (e.g., a TMS will maintain a log of who created, reviewed, released a payment to a bank or changed what and when, something no spreadsheet can do easily).
That said TMSs were and are still weak when it comes to
- Use – TMSs are primarily used in the treasury function among a historically small number of treasury users. Compare their use to the number of staff who use an ERP system. Arguably, a TMS is also more complicated to use further reducing its use outside of Treasury
- Cash forecasting – Any forecasting requires assumptions about the future in addition to knowledge about the past. Modeling the future was always easier in excel; however, excel cannot maintain data integrity (i.e., who changed what and when) nor generate dynamic performance dashboards. Lack of standards makes maintaining a forecasting model and comparing scenarios difficult across business units or legal entities over time.
ERP systems also share this weakness as they are historical processing engines; however, they are more “data complete” as they include both cash and non-cash (i.e. accrual) transactions, important for longer term forecasts. - Investments – Unlike payments which use a standard language (e.g., SWIFT) the many different asset classes available, (e.g., time deposits, money market funds) and their data, are not easily captured in a TMS. Example: Accurately tracking / reconciling short term investment balances among many investment institutions is not easily done.
- Debt compliance – CFOs must send debt compliance letters to their banks at least quarterly. No TMS can do this.
- Tax strategies – No TMS has the ability to monitor transactions from a tax compliance perspective nor supply other software with data about which payments could or did create a taxable event (e.g., repatriate “too much” cash?).
- Equity monitoring – No TMS tracks cash used / supplied by equity-oriented transactions (e.g., stock options, buybacks, etc.)
The TMS of the Future
It is not essential that a TMS itself possess the power to account for and report all of the activities above, but it should be capable of receiving and exporting the cash transactions that represent these activities to other systems seamlessly.
Building a strong integration between “the market” and an ERP and other financial systems is key to a TMS’s future relevance. Such a foundation will require a TMS to sync their organization structures and chart of accounts to remain identical to a company’s “book of record”, its ERP system as well as receive data in market-based formats (e.g., ISO 20022).
According to a recent article in a treasury magazine the days of the TMS maybe numbered because they do not employ the latest AI or machine learning features. Also, their ability to use and integrate more internal data is limited. Then, there is their “cost of ownership”.
I believe some form of a TMS will remain necessary due to the ability to integrate with external, market-driven data on a real time basis. However, if a TMS is to remain useful, it will need to transform into a “liquidity information engine”, not just as an aid to the financial close process, which is a historical not future oriented process.
TMS of the future needs to acknowledge that one size will not fit all. Afterall, some companies are simpler than others and do not need as many “bells and whistles”. Underutilized technology, and untrained users in or outside of treasury, is a wasted investment in the future.
Longer term, the transformation of the TMS will include producing both management and GAAP reports (e.g. a cash flow statement) to answer future oriented questions like:
- How much liquidity is “enough”?
- How much risk is “too much”?
- Do company policies contribute to or constrain answers to the above questions?
- What metrics define success?
- Who is really responsible when a company is over borrowed, under invested or over exposed?
Next step?
Meld a TMS with existing corporate performance management (CPM) software to allow a company to create both short-term (bottoms up method, popular in Treasury) and long-term cash forecasts (top-down method used by FP&A) from within a single system.
The time is now.
