Reference case

Lessons from a High Radius Finance transformation

16 April 2025

Making financial transitions work

When going through a financial transition, whether it is an organizational or an automation transformation, there are five important points of attention to avoid hick-ups during the transition and to achieve the initial intended goal:

  • Good preparation is key. Map the ASIS process, define the gap with the TOBE process and, most importantly, remediate the gap or mitigate the risk of the gap and assess with all stakeholders if the solution is feasible.
  • The quality and governance of the master data is also key. Assess the quality and remediate before kicking off with the transformation project.
  • Understand the tooling required for automation - what are the necessary conditions for success? What happens if those conditions aren’t met? Is the goal still achievable? The same applies to any organizational transformation: What is the desired end state? And within what conditions must the transformation occur?
  • The approach of the project, and how the project is carried out is very important. A top-down approach is not always the best way forward. Successful transformation requires the involvement of all stakeholders -both directly and indirectly impacted. An inclusive approach, such as bottom-up, middle-out, or a collaborative model, often delivers significantly better results.
  • Ensure that the right set of skills are in your team to implement the automation, but also in the team of users. The ability to shift from solution thinking to process thinking requires a team with a strong digital mindset.

Optimizing O2C

A multinational listed food and beverage company with a decentralized structure, required assistance with its O2C transformation. To support the Shared Service Center (SSC) for the Benelux, the company sought an experienced O2C project manager to oversee the implementation and deployment of various ongoing projects.

  • The automation of the AR and collection processes using High Radius (HR). It is an End to End (E2E) cloud solution to automate your finance processes in the O2C flow, using AI and robotics by defining automation rules (general a specific).
  • Support in the ongoing “Themis harmonization” project, which was basically a carve-out of several business units in Belgium and the Netherlands and the integration in other business units.
  • The integration of the invoicing and claims management process.
  • The merge and alignment of two existing credit policies into one new credit and payment term policy, including an update of all credit limits.

The automation of the AR, using High Radius

The transformation to a highly automated Accounts Receivable (AR) process - driven by the implementation of the so-called Cash Automation Application (CAA) - was led in a top-down manner by the organization.
While this approach aligned with top management’s strategic goal to maximize standardization, reduce implementation costs, and significantly cut down on manual effort in daily operations, it also resulted in several common pitfalls (see examples below). Many of these issues could potentially have been avoided with a more bottom-up approach, incorporating insights from operational teams early in the process.

In the pursuit of maximum standardization, local needs were largely overlooked. Furthermore, no AS-IS mapping of the AR processes across the various SSC clusters was conducted in preparation for the blueprint or system architecture. Instead, the existing way of working at the UK SSC -chosen as the pilot location - was simply rolled out across the other SSC clusters, without proper consideration for local variations or operational differences.

From constraint to 97%

This approach led to a disruptive core model in High Radius. The core model was the global blueprint of the tool. Basically, it defined how all SSC clusters had to work globally to receive, process and book payments. As the core model could not be changed this led to ongoing, often circular, change requests (by-passes) and tickets, disrupting the day to day processes. As not all issues could be resolved through quick fixes, the different SSC clusters in Europe could not reach the desired level of automation and there remains today a lot of manual re-work.

This was also the case for the SSC Benelux. When the project started, the High Radius blueprint was already designed and only the core model could be implemented with very little room for local needs. For each individual customer was needed:

  • to define specific automation rules, how to read the payment advices
  • to set up alternative payers (in case another organization is paying for the invoices), and aliases (if a customer has multiple accounts)
  • to set up lock-boxes, which enables efficient management of incoming payments by automating the process of reconciling and posting payments received in various formats, such as checks or electronic transfers

This was a comprehensive exercise as previously no mapping of the ASIS process was executed. Naturally, extensive testing was required to ensure alignment between our local way of working and the core model. After the sign-off of the Process Design Document (PDD), which described the HR | CAA processes for the SSC Benelux, and the User Acceptance Testing (UAT) the project went live and a staggering automation rate of 97% was reached. It was the highest automation rate of all European SSC clusters, for which we received a standing ovation during the HR | SSC clusters gathering in March 2022.

Mitigating risk, missing efficiency

To achieve this success rate, several sequential strategies were defined to mitigate the efficiency risks:

  • question the core model to the max, to have it altered via change request to meet the Benelux business demands
  • align the present way of working with the processes in High Radius
  • bi-weekly follow-up meetings with the project-team and tech-team to discuss the statuses of the different change requests, tickets, testing and solutions
  • elaborate a Minimum Internal Control Standard (MICS) in Power BI to ensure correct bookings, with regards to lock boxes, quality of bookings and controls on the interface High Radius >< SAP, which was a boundary condition for success
  • ensure training and reference material for the AR-team, to use HR and to execute the necessary controls and remediation in SAP

However, despite the high automation rate, there was only a limited efficiency gain on the work floor, compared to the previous way of working (SAP|FEBA), as the maintenance to keep High Radius up and running was demanding a lot of attention and resources:

  • ongoing internal controls and re-work on the interface HR >< SAP
  • follow-up of tickets as HR was not stable
  • follow-up of Change Request (CR) for the maintenance of specific automation rules to read remittance advices, As there was no governance around this boundary condition for success, a CR was necessary for every update. This approach depleted the regular budget for CR’s as there was no specific budget for the maintenance of the specific automation rules. This maintenance was essential for success, as outdated rules would prevent the automation from functioning properly
  • exhausting communication with the tech-team
  • the Global Design Authority (GDA), which had to oversee and align all change requests, was still not live, resulting in faulty patches and adaptations in HR. Change requests were approved without assessing the impact in other clusters. As a result, rules which were working in the past suddenly generated issues.

As an overall result, the automation rate declined from 97% to 75% over a period of one year.

The automation of collections, using High Radius

The automation of the collection was a different story, but with many similarities. The blueprint of the collections module (CLS) was already defined at the start of the project, allowing only implementation of the core model for collections. However, the various collection strategies still required setup and fine-tuning.

However, due to the CAA module requiring more time and resources than anticipated, there was limited time to test the CLS module. To adhere to the project timeline, the PDD and UAT were approved, despite minimal end-to-end testing being conducted. The PDD and UAT were subsequently signed with numerous remarks and reservations.

Later, when the module was set to go live, it became apparent that the CLS module was exhibiting unusual behavior. As a result, it had to be taken offline during hyper care. For example, duplicate invoices were sent to incorrect customers, the proposed actions in the work list were inaccurate, and the sequential timelines were misaligned. Further fine tuning and adaptations in the design were necessary. However, as the PMO overlooked the reservations in the PDD and UAT, the tech team was hesitant to make further adjustments and fine-tune the CLS module. Budget constraints also played a significant role in this decision. As a result, the CLS module remained offline.

The Themis harmonization project

The Themis harmonization, which was actually a carve-out of different business units, on one hand and the integration in another business unit on the other hand, had as purpose to simplify and harmonize the master data and different order entry processes which were used within the company.

This meant that customer databases and their hierarchy (up to seven levels) needed deduplication and harmonization; contracts, payment terms and price matrices needed harmonization, etc. The deduplication was very challenging as it appeared that, on 2/3 of the customer database, VAT numbers were missing, addresses were not updated, names were not correct, etc.

Initial focus was placed on improving the quality of the master data, as starting the exercise required clean data. However, the lack of democratization of the master data made this highly challenging.

Secondly, the merge and alignment of two existing credit policies was also necessary. Furthermore, the credit limits also needed updating in light of this new credit policy and the merged customer accounts.

The integration of the invoicing and claims management process

Last but not least, on demand of Global I2C, the SSC Benelux also had to integrate the invoicing and claims management (previously in scope of Customer Service). As this was also pushed top-down, there was no or little buy-in from the different stakeholders (Customer Service & Sales), which made the preparation and transition very challenging.

Based on experience, a middle-out approach proved more effective in this context, involving collaboration between top and middle management to drive change. This approach helps bridging the gap between high-level strategy and day-to-day operations, as middle managers typically understand both strategic goals and operational challenges.

From questions to clarity

The scope of the integration was not clearly defined by Global I2C, leading to several open questions. For instance, clarification was needed on the role of invoicing within the broader O2C process - from order entry to cash collection. Since the invoice is the automated outcome of the order entry process, it is inherently linked and cannot be isolated from it.

Another point of discussion concerned the inclusion criteria for claims: whether to incorporate only price-related claims or also quantity-related claims, the latter involving a more complex and labor-intensive process.

To define the scope and support effective discussions with stakeholders regarding the transfer of activities, the following approach was taken:

  • a benchmark of the invoicing and claims management process and way of working in the different SSC clusters in Europe, through online interviews
  • a mapping of the existing invoicing and claims management process in the Benelux, through online interviews and a summary in a flowchart, followed by a gap analysis compared to the benchmark
  • a proposal to define the RACI matrix, which is a common tool used to document and communicate roles and responsibilities in a clear and organized manner, ensuring that everyone involved understands their role in a given process.
  • a proposal to define a Service Level Agreement (SLA) with all stakeholders, with regards to the registering, analysis and resolution of the claims (throughput time)
  • a proposal to define the resources (FTE’s) needed to perform the job
  • a roadmap to define the transition period and process improvement period
  • an overview of specific price & quantity process improvements, related to missing controls

Following multiple discussions with the PMO, CFO, and Head of I2C, and based on the gathered information, a proposed scope, roadmap, and set of process improvements were presented to the CEO and other stakeholders during a kick-off meeting to initiate the negotiation process.