Share with your friends

Upgrading and expanding treasury management systems in line with IFRS 9

Upgrading and expanding treasury management systems

Ideally, weaknesses in treasury IT systems should be detected and remedied while the system is being introduced. Yet new risks also lie hidden in legacy systems when upgrades and expansions take place.



Per Areskär

Partner, Financial Risk Management

KPMG i Sverige


Relaterat innehåll

Ideally, weaknesses in treasury IT systems should be detected and remedied while the system is being introduced.

Yet new risks also lie hidden in legacy systems when upgrades and expansions take place. Especially when developments such as IFRS 9 necessitate far-reaching intervention, these risks can be countered by continuous quality assurance within the framework of a system audit that accompanies the project.

Right now, we see IFRS 9 as a driver that is causing many companies to adjust or expand their existing treasury management systems. To fully model the functional and technical requirements and possibilities of the new financial instruments standard IFRS 9, most commonly used treasury management systems need an upgrade to the latest release version or, at the very least, significant modifications to the configuration.
To ensure that the process chain between Treasury and Accounting continues to run smoothly and properly, such interventions in the live system demand strict project discipline. The project plan to introduce the new standard should therefore reflect a corresponding combination of functional and IT technology aspects. Ongoing quality assurance within the framework of a system audit that accompanies the project should be an essential project ingredient, going beyond mere functional support and emphasizing proper implementation in the context of the IT project.


IFRS 9 is expected to lead in particular to changes in the rules for measuring derivatives, as well as to account assignments and the associated posting logic. The structure of accounts must also be adapted accordingly in the general ledger, and this can create risks relating to interface configuration. Where a treasury management system has already been up and running for some time, adequate analysis and testing of other (non-IFRS-9) functions affected or modified by the upgrade should also be completed in advance. If configuration errors occur and systems are not properly tested despite such measures, this can quickly led to significant errors in the balance sheet, income statement and notes. In practice, we see risks associated with the implementation of IFRS 9 in treasury management systems primarily in the following areas:

  • Use of unsuitable or incorrect market data and measurement models to calculate market values and valuations in accordance with IFRS 9. Examples include:
  • Determination of currency basis spreads (CBSs) for different derivative financial instruments for which new currency basis-adjusted discount factors may have to be incorporated
  • Calculation of the ineffective portion in the context of hedge accounting by separating forward items, currency basis spreads and fair values and when determining the aligned time value in the case of hedging with options
  • Calculation of expected credit losses on original financial instruments, including newly imported credit default swap spreads and default probabilities, for example

Incorrect or incomplete implementation of the account and posting logic of IFRS 9, for example with regard to:

  • Presentation of the cost of hedging and the effective portion in two separate OCI accounts and the creation of new reversal logic for OCI
  • Posting of expected credit losses for financial assets, following a graded approach in the case of a significant increase in credit risk
  • Incomplete or inconsistent adjustment of the structure of accounts between the TMS and the ERP system

If such weaknesses and risks of errors are not detected until new modules and functions are already being introduced or – worse still – during live operation, remedying them is normally extremely difficult: Project structures have already been dissolved, test systems are no longer available, and/or direct access to the system vendor's consultants is no longer given. Moreover, retroactive error correction is usually associated with additional, unplanned costs and inefficient manual workarounds.

Since system expansions and upgrades regularly focus on accounting-related functions and on security measures that are implemented using treasury IT, the statutory auditor must assess them at the latest in the context of the final audit. A system audit that accompanies the project and is normally conducted by the appointed auditor's treasury and IT experts allows the causes of potential errors to be eliminated specifically and at an early date – ahead of the end-of-year audit.

It is also possible to select additional focal areas for quality assurance. One example could be monitoring the system-side migration from IAS 39 to IFRS 9. Another could be integration in the functional IFRS 9 accounting project, where this is not already subsumed under the IT project audit and system acceptance.

Alongside the clarification of functional aspects, it is also important not to underestimate the need to align existing system functionality with the overall requirements of IFRS 9. Conducting a system audit while the project is in progress reduces the risk of inconsistencies and incorrect statements about financial instruments in the context of the year-end financial statements, thereby also curbing the risk of painstaking rework in the treasury management system.

Kontakta oss


Want to do business with KPMG?


loading image Offertförfrågan