Some time ago I overheard a conversation at the water cooler about a spreadsheet issue. One person casually advised his colleague to consult treasury since team members typically are the savviest spreadsheet users around.
Somehow treasurers have a love-hate relationship with spreadsheets. The popularity of Bart Parren’s recent article, Corporate treasury: do spreadsheets still have a role? is a case in point; it’s by no means the first – and won’t be the last – validation of this general statement.
Because most treasurers will subscribe to the dangers of using spreadsheets in their processes, as regularly highlighted by various authors, one might wonder why it’s apparently is so hard to eliminate them. Let’s explore the reasons why spreadsheets are so deeply embedded in treasury operations – understanding these can be beneficial when scoping or executing your next project.
Under-utilisation of available functionality
When auditing or scanning treasury operations, we commonly encounter spreadsheets for operations that otherwise can be supported by the applications clients already are paying for. This may appear odd as it not only adds to the operational cost, but also creates control and compliance issues. However, the reliance on spreadsheets is often explained by one or any combination of the following internal root causes:
1. Incomplete initial systems implementation
Resulting from improper scoping, budget constraints, lack of focus, superficial acceptance testing, timeline overruns and/or career moves, projects can get wrapped up before completion. Naturally, end users will try to make their day-to-day activities easier by implementing spreadsheet routines to compensate for the shortfalls in their workflow.
The same result can be derived when the initial implementation is time-squeezed and lesser scope is moved to a “next phase (TBD)”. More often than not that next phase is either squeezed to free up staff time or abandoned entirely, and must compete with and ultimately get buried beneath other, more urgent priorities.
2. Deficiencies in applications selected
Despite the fact that treasury applications have matured over recent years, we have yet to come across an application that perfectly matches all initial requirements. Often applications accommodate an alternative way of working – or even an equal alternative best practice – to the requirement that isn’t acceptable to the prospective buyer. Although we urge prospective buyers to consider changing their way of working, clients accept work arounds. The nature of each work around is that one has to accept custom developments, or highly human-dependent and off-line routines. Where most buyers initially will aim for custom development, more often than not they settle for the “cheaper” spreadsheet supported work around.
3. No application management
Treasurers who contracted traditional licenses often suffer from the lack of application management. Even when the initial implementation catapults the treasury towards leading edge, keeping the solution in shape requires constant maintenance. It is still common to come across cases where, since the initial implementation more than five years earlier, the treasury application has still not been upgraded and may be several versions behind the current release. This implies that the software version is unsupported, annual maintenance fees paid for nothing, and that treasury is unaware of specific functionality in newer releases, for which it believes it needs to create a spreadsheet based work around.
4. Modular approach and shift in treasury strategy
Sometimes company or treasury strategy changes after the initial implementation of a solution. As a result, treasury may require additional functionality that is not covered in the contract. Especially in cases where treasury pilots a new approach, it is tempting to start off with a spreadsheet-based process. Before long such spreadsheets become embedded as the process, and replacement with a more robust module of the existing treasury application may seem painful and costly.
5. Treasury reporting
A variant of the fourth type of root cause is also found in treasury reporting processes. Spreadsheets and other desktop applications are hugely popular for periodic reporting. Spreadsheets are typically used as a “mini business intelligence” tool for data warehousing and graphing. Often these spreadsheets feed standard report packages set up in other desktop applications. Business users tend to find business intelligence (BI) tooling cumbersome and rigid and, more often than not, use it for retrieving company specific data for their treasury reporting.
6. Migration instead of upgrade
Vendors enhance and develop their solutions and releases often contain new functionality that remediates past deficiencies or existing work arounds. However, upgrades are frequently managed as like-for-like migrations to a higher version keeping the use of work arounds. Typically, this occurs in situations where so called “upgrades” have been forced on clients that needed a bug fix or otherwise are done under considerable time pressure, where new functionality cannot be explored or no time is available for decent testing over and above standard regression.
We also get the impression that with the automatic updates in a software-as-a-service (SaaS) solution there is less tendency to explore new functionality. This proliferates the old adage “if it ain’t broke, don’t fix it”.
7. Cost/Benefit
A last type of root cause for the use of spreadsheet is a deliberate cost benefit analysis. Some treasurers balance the cost of managing a “simple” and flexible spreadsheet solution against the pain and rigidness of a more integrated technical alternative. Investing in an additional full-time equivalent (FTE) can make a small treasury department more resilient than an equal investment in tooling.
Applications don’t keep up with (market) requirements
A second category of root cause is related to vendor policy and business development strategy.
1. Vendor development agenda
A development agenda is typically driven by (if not necessarily in the order of priority given): technological evolution, sales and marketing strategy, client demand and market compliance. Often the development capacity is limited and cannot accommodate the total demand. Consequently, management must prioritise and manage release content carefully. Furthermore it takes some time to develop new or enhance existing functionality. The result is that it is hard, if not impossible, for vendors to keep up with all requirements and deliver them on time. A good example of this is the difficulty that vendors and their clients have with keeping their systems up to date with the ever- changing regulatory requirements. Given the uncertainties, treasurers would rather start with a work around solution for compliance based on spreadsheets than risking non-compliance.
2. Beta version and bug fixing
Some corporates have a policy to not undergo upgrades at the time of release. Such a policy tries to leverage the effort of other clients debugging a new release. The consequence of such a policy is that the treasurer may not have access to all the functionality required for compliance of new processes. This may proliferate a more extensive use of work arounds and spreadsheets because they will never have access to the latest functionality.
DIY
A third category of root causes relates to the mindset of a treasurer. Some believe they should not become complacent with automation and workflow support. In their mind, automation nurtures an unhealthy reliance on configured rules resulting in an incomplete understanding of the processes and a carelessness towards monitoring and exception handling processes.
These treasurers often have an inclination to maintain cumbersome spreadsheet solutions as they may believe it keeps their people in touch with the business. One treasurer agreed with this writer’s suggestion that his system could perfectly calculate fair values of complex derivatives, but still preferred his people to do it in Excel.
He believed that by doing so, team members would be kept on their toes and have a much better understanding of all the permutations and flaws compared to retrieving “a number” from the system. He also was convinced that his team would never be able to be configure the system such that it would handle all permutations correctly under all circumstances and that they would not be able to detect all flaws resulting from it.
Conclusion
In this electronic age, the decision around the use of spreadsheet is still not (and arguably will never be) digital. We should discourage the use of spreadsheets in regular processes and eliminate them from automated processes altogether as they are error prone, human dependent and typically do not leave a clean auditable trail.
For all the reasons outlined above – and more – it is an illusion that spreadsheets will be phased out any time soon. The validity of the root causes discussed here is dependent on the circumstances. To the extent they are valid treasurers could better focus on reducing the process dependency and putting the necessary (manual) controls in place to compensate for the deficiencies of spreadsheet based solutions.