Get rid of bespoke solutions: back to standard!

March 2023
3 min read

How should corporate treasury business stakeholders and project owners deal with the transitions of SAP Treasury as their treasury management system (TMS) and its surrounding treasury interfaces and solutions?

This article may help SAP system owners re-think or change their approach towards bespoke custom solutions in the system.

Over the past 14 years, my colleagues and I have dealt with five types of SAP Treasury transitions:

  1. From fully custom/in-house coded TMS to SAP TMS.
  2. From an outdated version of SAP to a newer version of SAP (for example: ECC to S/4HANA).
  3. From an outdated version of non-SAP TMS to SAP S/4HANA
  4. A split of the existing SAP TMS system into two SAP TMS, due to the business carve out.
  5. A merge of SAP TMS system with the main SAP ERP system.

Any type of transition has its own specific focus points during the project’s design phase. Almost every project’s primary goal is to enhance the TMS functionality; improve the user experience using a better level of business process automation and improve the security level of TMS.

Meeting business needs

Often Corporate Treasury requires support and expertise in designing the future business process and how the SAP Treasury system and architecture can meet business needs. One of the biggest challenges here is to find a trade-off between the different business requirements and the standard capabilities of SAP and its interfaces.

One of the main drivers of the custom requirements is hidden in the existing user experience. The end users/stakeholders got used to the old TMS functionality and behaviour, which is not the same in the new SAP system.

An experienced and independent consultant would first recommend leveraging the TMS standard functionality and proposing solutions to meet the business requirements with minimum custom functionality. In this case, the consultants often run TMS DEMO sessions in the new SAP Treasury; pre-configure the TMS and provide proof-of–concept solutions to provide evidence of certain complex functionality that can be aligned with standards.

Why is standard functionality important?

There are six reasons why we think the standard functionality is so important:

  1. It is supplied out–of–the–box and pre-designed by the system provider. Consequently, less time is needed to design the business process compared to design bespoke solutions.
  2. It is used by other clients and the system provider already analyzed the user experience of the solution. Hence, there is a higher level of quality assurance.
  3. SAP supports its own products and any enhancement of the TMS must be done by the system provider with minimum regression impact (impact on the current and working functionality).
  4. A client can raise SAP expertise internally or hire an external consultant to support the known functionality. There is no dependency on the knowledge of custom functionality.
  5. It provides easier business process standardization and scaling among different countries/regions.
  6. It helps to find treasury employees with known SAP Treasury experience, the knowledge can be taken from the market.

Nevertheless, it is quite hard to drop custom bespoke solutions; sometimes it must be applied in the design and implemented for the clients.

Sometimes custom solutions are needed

There are some reasons to implement custom solutions in a treasury system’s architecture:

  1. Strict and complex client requirements which cannot be met by standard functionality. There is no workaround in the standard. The most common example is cut-off time logic for POBO payments or calculation of internal FX rate types, among others.
  2. Standard functionality is not yet released to clients. However, it is crucial for a client to get it as soon as possible.
  3. Custom SAP functionality is already in place but needs to be enhanced.

Recommendations for the custom solutions

If a custom solution is inevitable, we have a couple of best practices.

Firstly, avoid the hardcoding of multiple conditions in the ABAP code. Instead, move the maintenance of the conditions to either custom or standard tables which can be supported by functional SAP support personnel or even by business users. Once a minor change in the conditions is needed there will be no need for a developer.

Secondly, leverage the use of SAP functional modules, programs, BAPIs and BADI etc. This makes the custom code more stable and leaves it less exposed to regression risks during the next system upgrade.

Also, avoid replacing significant pieces of the standard functionality with custom-developed ones which do not bring significant improvements. Supporting such SAP TMS becomes complex and expensive.

To conclude

We recommend that you minimize the volume of the custom solutions during TMS systems implementation. A good balance should be found between business requirements versus SAP standard functionality.

SAP continuously improves its solutions in response to customer feedback, changes in financial standards, regulatory requirements, technology trends, etc. Therefore, it is important to conduct the TMS audit from time to time to see if old and custom functionality can be scrapped since there is standard functionality already available.

If you need an audit of your treasury systems, have challenges with custom solutions or need help with the system design, please feel free to approach us. We have extensive experience in enhancing treasury technology and improving treasury functions.

This site is registered on as a development site.