Treasury Technology
The Context for Treasury Technology
In times of rapid technological development – and also in times of massive technology hype – treasury best practice dictates putting technology subservient to solutions. Treasurers have many challenges, and technology can assist in many of these, but it is not an end in itself. Working tools can address treasury challenges, regardless of the underlying technology.
Because of this, it is important to start any discussion of treasury technology with a clear view of the domain of treasury itself. Treasuries vary, but generally they exist to reduce financial risk and cost. Therefore, treasury technology must help treasurers to measure and manage both risks and costs.
The risks that treasury generally addresses are
- Liquidity risk i.e., the risk of running out of money
- Price risk i.e., potential losses from price movements such as foreign exchange, interest rates, etc
- Credit risk i.e., the risk of loss from counterparty reduced credit worthiness
Treasury is also subject to common operational risks such as error and fraud as well as reputational and compliance risks; because treasury often handles monetary and large transactions, these risks are amplified in treasury.
The costs that treasury generally addresses include all the financial items in the profit and loss statement such as foreign exchange losses, hedging costs, interest, fees for financial services, and so forth.
Many of these risks and costs are not necessarily measured in dedicated treasury systems. Treasury often needs access to enterprise wide systems, such as ERPs, to gather the necessary data. Treasury technology does not sit in isolation from the enterprise’s wider technology stack.
Because the enterprise’s wider technology stack serves multiple users, treasury may not get the specific kind of data they need from it. For example, manufacturing and logistics require unit volumes, and procurement wants procurement costs, whereas treasury needs cash flows by currency and date.
As a result, treasury technology most often needs to integrate with the enterprise’s wider technology stack.
Treasury also deals in financial transactions which are not used by the rest of the enterprise, such as loans and foreign exchange transactions. Most ERPs do not intrinsically support such financial transactions – they focus on invoices and other common commercial transaction types. Treasury needs a system of record for financial transactions.
Typical Treasury Technology Topography
Typical core systems for treasury are a treasury management system (which is the system of record for financial transactions and an integrator of enterprise wide cash flows for risk and cost management) and an ERP from which treasury extracts cash flows and other relevant enterprise wide data and to which the TMS uploads accounting entries for financial transactions.
Of course, the picture rapidly gets more complicated, depending on business needs and treasury sophistication. As a generalisation, the diagram below is representative of a typical treasury system topology.
The orange items above are external interfaces, while the blue ones are internal interfaces.
Generally speaking, most treasuries need most of this functionality. But there are many variations in how to achieve this. The TMS is sometimes an integrated module of the ERP, and other times a separate software from an independent vendor. Hedge accounting, dashboard and VaR functionality is included in many TMS, but treasurers may prefer dedicated solutions.
Rates
The TMS will require market foreign exchange, interest, and other relevant rates to perform revaluations and simulations. Many treasurers get market rates from the major suppliers such as Bloomberg and Reuters . The major dealing platforms also serve as free rate feeds.
Some TMS – especially the SaaS offerings – integrate market rates from in their platform, often performing data validation and smoothing (because raw market rates sometimes contain anomalies from error and market excesses).
Treasury often provides foreign exchange rates for the ERP accounting rates.
Dealing
Most treasuries deal most financial transactions online – especially spot and forward foreign exchange and cash investment. Best practice is to use multi bank dealing platforms. These reduce errors, improve price discovery so that treasurers get optimal prices, and increase transparency by providing a clear audit trail that can be queried at any time.
Dealing platforms also handle trade confirmations which obviates the need for other confirmation services. This saves treasurers the cost and trouble of connecting with banks for automated confirmations. Manual confirmation by email or fax is sub-optimal.
The dealing platforms usually have APIs that allow TMS or other systems to upload deals to be executed (for example after determining net exposures), executed deals, bidding data, confirmation status, and market rates.
The larger dealing platforms such as FXAll, 360T, Currenex and BB FXGO, have sufficient data to be a valid source of market rates. This can save treasuries the cost of a market data feed.
Dealing via telephone (for foreign exchange spot and forward and other standard transactions) can also be sub-optimal as it can increase the risk of errors, produce poorer prices, reduce transparency and compromise audit trails.
Confirmation
Trade confirmation is mostly handled by the dealing platforms. Independent confirmation platforms have little purpose in these circumstances. Automated trade confirmation vastly reduces trading risk, and manual trade confirmation via email or fax is generally considered as poor practice.
Payments and Statements
Corporate to bank connectivity has passed through several phases in recent decades, from paper “TT instructions” and bank statements, through proprietary bank protocols (which forced treasuries to build dedicated connectivity for each bank), to standardisation mostly driven by SWIFT with its FIN standards (MT103, MT940, etc) and ISO20022 XML standards (pain, camt, etc). The advent of APIs for near real time banking is again fragmenting corporate to bank connectivity as banks innovate with API functionality.
Standards like SWIFT’s FIN and ISO20022 can be used independently of the transport layer. In other words, these standards are not restricted to SWIFT members. They can be used on bank proprietary connections as well as on the connectivity from third party multi bank connectivity providers.
ISO20022 has great flexibility and can handle practically all forms of payment, even cheques and physical notes and coins if required. But, of course, best practice avoids physical media as far as possible. FIN on the other hand is designed only for “TT” style large value cross border payments.
It is a common misconception to think SWIFT is only for large value cross border payments. With ISO20022 xml the SWIFT standard suite can handle local low and high value payments as well. The CAG has standardised how to encode local payments into ISO20022 for most countries around the world.
As mentioned above, SWIFT standards can be used on third party connectivity. In addition to SWIFT for Corporates, treasurers are using third party multi bank connectivity providers, SaaS TMS providers, concentrator banks, and some ERP providers to connect with their banks.
Multibank connectivity makes sense for all but the simplest treasuries, such as those with only one bank. Legacy ‘host-to-host’ connectivity is still used by some multi bank connectivity providers.
Most TMS and other treasury technology is normally capable of handling commercial payments and collections. They can act as a payment gateway, which processes commercial payments from the ERP and also financial payments from the TMS. For various reasons, some corporates process commercial payments from their ERP and financial payments from their TMS. In this case, they may have two bank connectivity solutions. A potentially more efficient arrangement is to use middleware to connect both the ERP and the TMS to some kind of payment gateway.
eBAM: electronic Bank Account Management
In addition to ongoing challenges with KYC, many treasurers spend considerable time on paper based bank account management – the opening and closing of accounts and the changing signatories.
Many solutions have been presented and some standards exist, but take-up has been very limited. Some TMS have added BAM modules so that at least treasurers have a clear view of where they stand even if they have to interface with banks with paper, and they risk their data becoming out of date with banks.
It seems that part of the problem is that only a few banks have internal systems for BAM and APIs to connect to corporate eBAM platforms.
Beyond that, compliance concerns can also make progress challening.
Trade
In some businesses, letters of credit are used extensively for commercial trade. L/C processing has traditionally been paper based, but in recognising the risks and costs of handling paper, the industry is rapidly digitising.
This is happening in a number of ways. Some trade is moving to newer technologies, often based on DLTs, to digitise processes and settlement. SWIFT’s MT798 suite of messages digitises most of the key steps in the traditional L/C process. Third parties also provide platform solutions. Furthermore, some banks have their own proprietary platforms for digital trade.
On the corporate side, trade systems of record may be in the ERP, or in the TMS, or in another separate system. Interfacing trade systems with banks remains highly specific depending on the systems used, on bank capabilities, and on the corporate ecosystem.
Central Bank Reporting
In most countries, central bank reporting is handled by banks for their corporate clients. In some cases, such as purpose of payment codes in China, corporates need to put central bank coding on payments.
In countries where corporates are expected to report flows directly to the central bank, most TMS systems will be able to generate the required reports. One issue may be that commercial flows do not pass though the TMS (because they are processed directly from the ERP); and in this case, central bank reporting may require aggregating commercial flows from the ERP and financial flows for the TMS to report enterprise wide flows to the central bank. This is another reason why a single multibank payment gateway is likely to be more efficient.
Netting
Multilateral payment netting is very popular with multinational corporations (MNCs) because this process can result in material savings in fees and float and can be simple and cheap to implement. About half of S&P500 companies currently use netting.
Many TMS have built-in netting capabilities but there are also several very popular stand-alone solutions that offer more flexibility to deal with regulatory constraints and corporate preferences. These may include receivables instead of payables driven netting, netting pools, gross in / gross out and other variants, currency offered and asked, and so forth.
Netting systems can be run at the level of payments and at the level of invoices. The latter has the merit of facilitating intercompany reconciliation. They typically interface directly with ERP A/R and A/P data and post accounting entries back to the ERP. Other interfaces will be with TMS for financial transaction and with FX dealing platforms for execution.
IHB (In House Bank)
IHB (In House Bank) is a process to improve intercompany efficiency and transaction processing whereby subsidiaries have multi-currency intercompany accounts with the IHB (typically a head office or treasury legal entity) through which all their flows and balances pass. In this way, subsidiaries and operating units do not need any bank account, which reduces complexity, costs and risks.
However, IHB cannot be managed without appropriate software. Sometimes this functionality is included in the ERP, and sometimes it is included in the TMS. Third party IHB functionality is rare.
IHB requires deep integration with ERP for A/R, A/P, and G/L, as well as with TMS for risk management, balance management, and dealing.
Forecasting
Treasury is intrinsically forward looking, so forecasting is a critical foundation for all treasury actions. Without a forecast, any treasury action will probably be inefficient and may increase risk.
Cash flow forecasting in its various forms can come from different sources depending on corporate culture and processes. Here are some common forecasts needed by treasury, and where they might come from.
| Name | Tenor | Purpose | Source |
|---|---|---|---|
| Cash positioning | 3-21 days | Manage bank accounts | Treasury, A/P, A/R |
| Funding forecast | Rolling 12 months | Manage subsidiary funding | Controller, Financial Planning |
| Long range plan | 3-7 years | Manage group funding | Controller, Strategy |
| FX forecast Rolling | 12-18 months | Manage FX risk | Operations, Treasury |
Forecasting is notoriously difficult, and as a result different businesses use very different organisational and technological approaches. This means that treasuries needs for forecasting vary widely. In the best cases, treasury is simply a consumer of forecasts generated by the business to manage its activity. Sometimes treasury consolidates forecasts generated within businesses and/or geographies. In perhaps the worst case, treasury generates forecasts itself.
Clearly, such different needs imply different technologies.
As a consumer, treasury simply needs interfaces or APIs to pull forecasts into the treasury technology stack.
As a consolidator, treasury needs a tool that can integrate forecasts from different sources which may be in different formats. Many TMS have forecast modules that can play this role. In some cases, middleware may be required to convert different formats. Many treasuries use consolidation tools used by accounting colleagues, but these may have multi-currency limitations that render them ineffective for treasury purposes.
As a generator, treasury has considerably more needs. Most TMS have basic consolidation capabilities but do not address forecast generation beyond basic heuristics. Treasurers are starting to use dedicated and generic AI and ML solutions to generate more reliable forecasts with less work.
ERP: A/R
Treasury uses A/R data primarily to forecast incoming cash. Some treasuries are also responsible for commercial credit and collection processes. For both of these purposes, treasury need only read A/R data – it is a one-way transfer of data.
Some treasuries use their bank connectivity to provide bank reconciliation for commercial collections. In this case, and where the reconciliation is performed outside of ERP, treasury needs to interface to A/R to post appropriate accounting entries when incoming cash has been applied to specific invoices.
Data transfer between treasury and ERP is best performed through APIs, and most ERPs have APIs for such standard processes, and most TMS can interface with those APIs. File transfer is also often a workable alternative.
ERP: A/P
Treasury will often access A/P data to perform commercial payments for the wider enterprise. This will normally be a two-way data exchange – treasury downloads invoices payable and vendor payment instructions from A/P and after executing payment, uploads cash application to update bank account and A/P ledgers in the accounting system.
Data transfer between treasury and ERP is best performed through APIs, and most ERPs have APIs for such standard processes, and most TMS can interface with those APIs. File transfer is often a workable alternative.
ERP: G/L
Since financial transactions are not natively processed in ERPs, TMS, in addition to acting as the system of record for financial transactions, the GL also generates the requisite accounting entries at inception and maturity, as well as month end accruals and revaluations.
Sometimes this is done at the level of G/L account balances updated monthly, but more normally it is done at the individual debit and credit entry level.
ERPs generally have APIs to import G/L entries. This can also be completed by file transfer, where APIs are not feasible.
Hedge Accounting
Hedge accounting is required so that accounts do not suffer volatility from the mismatch between orders (which do not appear in accounts at all) and hedges (which are revalued monthly with gains and losses reported in profit and loss). Both FAS and IAS specify strict (but different) criteria which allow unrealised gains and losses on hedges specifically matched with allowable commercial transactions to be recorded in retained earnings rather than in profit and loss. This is critical to avoid unrealistic profit and loss volatility.
Hedge accounting is not normally covered by ERPs (which do not handle hedge transactions in any case). Most TMS have hedge accounting functionality. Because hedge accounting can be a contentious issue, and because auditors can be very demanding about compliance with FAS / IAS hedge accounting requirements, some treasuries use dedicated hedge accounting software separate from both ERP and TMS. Such specialist software clearly needs to be interfaced with TMS and often also with ERP.
Some TMS vendors have acquired specialist hedge accounting (and risk) software to enhance their offerings.
Dashboarding
Treasury needs to communicate with peers and management on an increasingly real-time basis. As such daily, weekly, monthly, and quarterly printed reports – whether paper or pdf – are no longer fit for purpose.
Dashboards are the more appropriate way to share necessary information internally. This is sometimes called ‘business intelligence’ software, and often associated with data cubes, data warehouses / lakes / oceans. These typically show dynamic and real-time information, and allow drilldown to the account or transaction level as well as ‘slice and dice’ to allow users to analyse data flexibly to meet their own needs.
Most TMS provide some kind of reasonably flexible dynamic reporting capabilities. But because non-treasury peers will most likely prefer not to learn to use a system that is new to them, and because the objective is to communicate outside of treasury, most treasuries interface to the enterprise standard dashboard or business intelligence software to ensure maximum accessibility and also enterprise level access control.
This clearly requires interfacing in some form or other. Most commonly, treasury data is uploaded to a data cube or data warehouse / lake / ocean from which the dashboard or business intelligence software provides user customised views and drilldown and analysis.
Reporting
Most TMS include a report generator, which can typically generate paper, pdf, excel, email, etc. Normally these report generators can be programmed to run at specific times, and sometimes dependent on specific conditions.
The quality, flexibility and usability of these report generators varies considerably. Reporting is one of the biggest sources of dissatisfaction with TMS. Treasurers often find report generators too hard to use and too limited. Using consultants to create and maintain reports is also expensive.
The result is often a dangerous reliance on copy paste and Excel work arounds. Reliance on Excel for operational processes and key controls can be dangerous and considered poor practice. Excel should really only be used for exploratory analysis, and not for operational processes. A safer alternative is to download data into dashboards or business intelligence software.
Report generators are often pushed into service as makeshift interface tools – for example, designing reports to mimic the format required for upload to other systems. Relative to proper FTP and API data transfer, this can present serious security and data integrity issues.
ERM (Enterprise-wide Risk Management)
Treasury may or may not have responsibility for ERM (Enterprise-wide Risk Management). In any case, like other teams within the enterprise, treasury will have to provide treasury and financial risk data for ERM reporting purposes.
This is often achieved through the report generator, and increasingly commonly through dashboarding or business intelligence software. In some cases, there may be API connectivity between treasury and ERM.
Sarbanes-Oxley et al
Treasury, like other teams within the enterprise, must comply with internal control requirements to which the enterprise is subject. Since compliance is driven from the most senior levels, it must be handled professionally.
Compliance is generally based on exception reporting and key controls, both of which are central to treasury operations.
VaR et al
Value at Risk (VaR), Cash flow at Risk (CFaR), and other risk weighted statistical methodologies are a critical market risk management tool for treasury. The same math is often used for hedge optimisation.
Value at risk (VaR) is a measure of the risk of loss for exposures. It estimates how much a set of exposures might lose (with a given probability, typically 99% or 95%), given normal market conditions calculated from 1-3 years market price variance and covariance, in a set time period such as a day (or some longer period allowing time for the orderly closing of positions).
ERPs do not generally include such tools. Most TMS do include some such functionality. Many treasuries use dedicated risk management software separate from their TMS to do this analysis, in order to better meet their specific objectives. In this respect, it is analogous to specialist hedge accounting software.
KYC (Know Your Customer)
KYC (Know Your Customer) is an important compliance process for banks with their customers. Banks who fail to do adequate KYC can be fined by regulators. Commercial enterprises are increasingly required to know their commercial counterparts as well, but so far regulation is lighter than it is for banks. KYC is an important part of global AML (Anti Money Laundering) designed to inhibit the flow of criminal and terrorist funds.
Bank KYC processes aim to meet these regulatory requirements. Regulations can sometimes be vague in this area, so banks are forced to make their own interpretations in an effort to avoid fines and other sanctions. Because of this, KYC requirements – even within a country – will sometimes vary between banks, and in the worst cases between different departments within the same bank.
This can be time consuming and frustrating for both treasurers and bankers. The inefficiency is compounded in some jurisdictions where electronic signatures (and digitisation in general), is not supported.
Efforts to digitise KYC remains relatively patchy. Some progressive banks have have digitised their internal processes and work directly with KYC platforms to interface with their clients. Increasingly, treasurers are putting their KYC data – corporate documents, accounts, identity information, etc – online with these KYC platforms.
The advent of SWIFT KYC for Corporates in 2019 promises progress, as most banks are SWIFT members and use the platform for their interbank relationships, and because SWIFT has good access to regulators.
However, KYC digitisation is still relatively new for integration to have become common. Integration with eBAM is likely to become popular in due course.
SCF (Supply Chain Financing)
SCF (Supply Chain Financing) comes in various forms to manage working capital more efficiently for enterprises.
| Supply Chain Finance Trigger Events | Bank Processing Opportunity | Bank Financing Opportunity |
|---|---|---|
| Purchase Order Argreed | Purchase Order Advice | Pre-Shipment Finance |
| Goods Warehoused | Document Checking / Data Matching | Warehouse Finance |
| Documents Issued | Documents / Purchase Order Reconcilitation | Receivables Purchase |
| Document Presented | Document Checking / Data Matching | Post-Shipment Finance |
| Document Approved | Management of Approved Documents | Approved Payables Finance |
| Due Date | Document Payment | Repay any outstanding financing |
(Source: European Banking Authority, EBA)
SCF Is available across multiple dimensions, such as
- Paper vs Electronic
- Open Account vs L/C
- AR vs AP
- Mono vs Multi Bank
- Self vs Bank Funding
- Tenor Extension
SCF at scale requires digitisation. Some TMS have limited SCF capabilities for example dynamic discounting funded by the buyer. Most treasurers use either bank provided SCF services or third party SCF solutions.
Most SCF solutions have interfaces to common ERPs to download invoices to be financed and post settlement details.
Best of breed
In summary, the ‘best of breed’ debated revolves around whether it is better to use specialised software rather than generic solutions. Historically for treasurers, this has applied especially to the question of whether to use ERP treasury modules or special purpose TMS software.
Generally, The CFO and the IT community prefers that everyone use all the relevant ERP modules, since the ERP normally becomes an enterprise wide standard; on the other hand, treasurers typically prefer special purpose TMS software which is generally more agile in adapting to ever changing treasury needs. The advent of cloud and SaaS has made choosing a TMS less difficult than it was in the past, because SaaS is much less intensive in IT resources.
Recently the ‘best of breed’ debate has started to coalesce around the TMS itself. In other words, should treasury rely on a monolithic TMS or knit together different more specialised software dedicated to risk, investment, netting, hedge accounting, etc.
The ideal solution in both dimensions of course depends on the specific circumstances of each business.
Data warehouses
Because of the issues raised above, and because of treasury’s need to work with diverse data from all over the enterprise, more and more treasurers are turning to business intelligence software and the hypercubes and data warehouses / lakes / oceans that underpin them.
For many treasurers, such data warehouses are the glue that hold their wider data picture together. They become the essential tool to see the holistic view of treasury related data and metrics.
In the best case, treasury can simply avail itself of the business intelligence already in use at the enterprise level. Less fortunate treasurers may have to build their own business intelligence solutions – risking duplication of data and effort.
Interfacing (Excel, FTP, API)
Because treasury needs to work with diverse data from all over the enterprise, interfacing is a key capability for treasury technology. Many of these interfaces and the data they typically carry have been discussed above.
Typically treasury uses three main interface technologies
- Manual – primarily copy paste sometimes with some data ‘massaging’ in Excel. Using Excel for operational processes is considered poor practice because Excel has no clear controls over data integrity and no viable access control. Excel is good for exploratory analysis but unsuitable for ongoing operational processes. RPA is a big improvement for interfaces that cannot easily be formally automated.
- FTP (File Transfer Protocol) – file transfer in various guises is the primary interfacing technology used by most treasuries. FTP is long-practiced and well established, processes are easy to audit and security issues are well managed. FTP typically involves the exporting system placing an encrypted data file in a secure directory; the importing system checks the secure directory periodically and when a file is found it decrypts and imports the file, often placing an import status report in the secure directory for the exporting system to check.
- API (Application Programming Interface) – APIs have become more popular because they support more real-time processes. APIs have benefits for single transactions – each transaction is imported and its status reported immediately.
So long as the interface is automated and reliable, treasurers can generally take the easiest and cheapest alternative.
RPA (Robotic Process Automation)
RPA (robotic process automation) is an important evolving technology for those situations where APIs and file transfers are not feasible – typically because of legacy systems and/or lack of budget.
RPA is at its core a way to automate manual operations on computer systems, based on screen scraping. An RPA can broadly repeat any sequence that a human would do. For example, click the “Add” button, key in transaction data, then click the “Save” button.
Anyone who has faced inscrutable error messages and other computer glitches will guess that the above quickly gets more complicated in the real world. So RPA vendors build in various degrees of flexibility and even intelligence to keep the robots running smoothly.
Advanced RPAs can be programmed to make simple decisions that humans would otherwise make, and are being rolled out for insurance and mortgage application processing, for example.
In this context of connecting systems, a typical use case for RPA would be to scrape transaction data from the screen(s) of source system and key that data into target system. In practice, commercial RPA software can also process the data that it handles, for instance to validate or translate data (eg change source system counterparty code to target system counterparty code).
RPA is also used for repetitive non interfacing tasks such as reconciliation and internal controls, for example comparing two data sources to ensure they are in sync.
Reconciliation
Reconciliation is a problem for many parts of many enterprises. In treasury, the most recurrent reconciliation challenges are around bank account reconciliation. If it falls within treasury’s responsibility, A/R reconciliation is often problematic because it can be hard to identify incoming funds provenance, banks may deduct fees which makes matching by amounts hard, and payers may aggregate multiple invoices and net off credit notes and sometimes other items like cash discounts not agreed with the beneficiary. A/P reconciliation is generally less problematic because hopefully the payer knows what they have paid.
Technology has helped considerably with the reconciliation challenge in many ways.
- ERP systems typically handle back to back commercial transactions between subsidiaries such intercompany sales from one subsidiary to another.
- SWIFT GPI ensures that data included in cross border payments is kept intact, which aides transaction identification and A/R application.
- ISO20022 XML allows practically unlimited data to be attached to payments, and clearing systems increasingly carry more data, which aids transaction identification and A/R application.
- ERPs increasingly include reconciliation engines that use heuristics and machine learning to match transactions.
- Third party reconciliation services use heuristics and machine learning to produce high auto reconciliation rates.
- Banks increasingly offer self-developed or white-labelled reconciliation services to aid customers with bank account reconciliation and A/R application.
- Manual reconciliation is required increasingly only for exceptions that these kinds of technologies fail to auto reconcile.
DLT (Distributed Ledger Technology)
DLT is becoming increasingly prevalent in many previously paper based and unreliable treasury related processes. It is being trialed in such areas as trade and supply chain, securities, and payments.
In trade and supply chain, DLT based solutions ensure that transactions are not double financed, and provide a common agreed data source on which the various parties – seller, buyer, forwarding, customs, banks, etc – can rely.
In securities, DLT based solutions are helping with settlement and transfer of title.
In payments, DLT-based cryptocurrencies such as Bitcoin were the first live solutions. Of interest to some treasuries are the new stable coins introduced by banks and others. And in the near future, CBDC (Central Bank Digital Currency) may offer prospects for faster and cheaper payments with added data payloads and security.
As with all new technologies, treasurers should assess how the solution addresses treasury challenges, rather than jumping on the new technology bandwagon. Most of the use cases mentioned above have helpful non DLT versions that are often more mature that may offer safer and quicker routes to treasury efficiency.
Excel
Excel is a wonderful and very flexible tool, much used by treasurers. It is a wonderful tool for exploratory analysis. But its flexibility can be a weakness for operational processes and controls.
Problems in managing Excel sheets are numerous, but these are some of the most common ones:
- Broken links
- Inconsistent formulas
- Broken group summaries
- Broken running totals.
- Incorrect cell references
- Mismatched monthly, quarterly and yearly numbers
- Coordination between fiscal years and calendar years
- Mistakes in common formulas
Excel can sometimes be so problematic for treasuries that the audit costs incurred can easily offset the initial savings from ‘quick fixes’. Overuse of Excel can sometimes lead to financial statement errors that damage reputations. This has given rise to a small industry of Excel forensics that charge large fees to identify and fix Excel errors.
