With the new release SAP S/4HANA Financial Products Subledger, it is time to reflect on some of the questions asked around this innovative solution.
On June 29 this year, SAP released the first version of its S/4HANA Financial Products Subledger (FPSL), the result of its co-innovation with Swiss Re. Six months later, right before the next release on December 17, and many discussions down the road, I thought it might be time to take stock and address some of the common questions about FPSL.
Let’s first take a look at what the solution actually is. The financial products subledger is an intelligent response to the challenges posed by insurance accounting requirements. It is a multi-GAAP subledger intended for use by primary insurers and reinsurers that contains processes to manage calculations and postings related to actual transactions, as well as estimated amounts. Using near-real-time processing and a continuous close concept, FPSL provides CFOs and CIOs with a real option to upgrade their finance landscapes based on intelligent concepts and latest technology.
For companies and departments accustomed to working with SAP and knowing its solid foundation in accounting, FPSL is just a logical innovation in line with SAP’s newer S/4 HANA, C/4 HANA technologies, and acquisitions in areas such as artificial intelligence and data mining. For those with less exposure to SAP, this may raise a number of questions, some of which are asked and answered below.
SAP IS MORE THAN ACCOUNTING
Q. SAP refers to a system used by our accountants to store information needed to produce the financial statements, but it has nothing to do with my daily business. Is calculating and analyzing information for IFRS 17 a strength for SAP?
A. While SAP is known for its strength in accounting software, it’s also a market leader in ERP software. Because of its accounting strength, SAP is sometimes perceived to be good at posting to so-called systems of record but offers little else. This perception is untrue, and in fact, SAP offers solutions covering the complete end-to-end insurance process from the front office (Customer Experience) to mid office (Core Insurance) to back office (Finance & Risk) and has made headlines with its end-to-end cloud insurance experience.
FPSL is not meant to be an unintelligent posting engine to ensure that debits and credits match. Instead, it can consume actuarial results (such as cash flows, patterns or present values) and transform them into accounting information for as many GAAPs as you require, at any time you require it. IFRS 17, US GAAP and Solvency II are pre-configured out of the box; further calculations are completely configurable and are processed in memory during run-time using the SAP HANA database for extremely high performance.
ALL THE CONTROL IS IN YOUR HANDS
Q. Because SAP is an accounting system, won’t using FPSL also mean our IFRS 17 governance structure will be predetermined. Will actuaries lose control over the numbers produced?
A. No. A decision to use FPSL is not inherently a governance decision. All SAP software contains an extensive authorization concept that lets you decide which departments and people can view data, run processes, or change the configuration. So, if you want your actuarial department to be in charge of configuring calculation logic, it is possible. Or if all changes should go to IT first, no problem. Such decisions are completely up to you.
ESTIMATES CAN TAKE MANY FORMS
Q. I hear that FPSL assumes actuarial solutions must deliver best-estimate cash flows. Does this make sense if cash flow modeling is based on stochastic processes?
A. Best estimate cash flows aren’t the only option to deliver estimates, but it is the recommended interface between the actuarial solutions and the subledger if you want to leverage the full capabilities of FPSL to completely automate multi-GAAP accounting. If you choose best estimate cash flows, FPSL can process all GAAP specific amounts in parallel, and with one of the upcoming release, full simulation capabilities will be made available. This option makes it easy to achieve a high degree of automation and reduce dependencies on the delivery of estimate data during the closing process.
If there are reasons to not provide best-estimate cash flows or to provide them only for some types of cash flows or some LOBs, FPSL has other various import options (e.g., import a present value). However, it is important to clearly identify the information requirements on both sides of the interface to ensure all disclosure requirements including auditability can be met, for both initial and subsequent measurement.
NOTHING VENTURED NOTHING GAINED
Q. There are differences between our current processes and the processes foreseen by FPSL. So, in addition to implementing IFRS 17, we will need to manage organizational change. Isn’t this risky? And is there tangible benefit from taking on this additional challenge?
A. To leverage the benefits of FPSL, there will be organizational change. But to imply that organizational change is a hassle rather than an opportunity would be a shame. I’m sure there are many people working in actuarial or insurance accounting who would agree that processes need improvement, and data reconciliation is a headache. But if you take a step back, to look at the opportunities of an innovative approach such as this, I feel you will find many long-term benefits for you and your organization. Adding spot solutions to an already overloaded landscape might be a quicker approach right now, but it’s unlikely to bring benefits in the long term.
THE BASELINE-DELTA APPROACH CAN MAKE SENSE FOR JUST 1 OR 2 ACCOUNTING STANDARDS
Q. The Baseline-Delta Approach has great advantages for multi-national companies, but realistically I only need a solution for IFRS 17 and local GAAP. Isn’t this overkill?
A. Simply put the Baseline-Delta Approach provides a baseline number for undiscounted best estimate cash flows. From there we apply GAAP-specific calculations to produce the amounts as required by the relevant reporting standard, which are called deltas. In the context of IFRS 17, there is a delta for discounting and unwinding tasks, a delta that calculates or imports the risk adjustment, and a delta for the CSM. For a single accounting standard, it is not more complicated than that. And even if you do not have external multi-GAAP requirements, you may find benefits for different internal valuations or even different IFRS versions.
SIMPLICITY BY TACKLING THE COMPLEX
Q. The results produced under the IFRS 17 standard are strongly determined by actuarial modeling assumptions. Won’t it be easiest to perform all calculations in our actuarial systems and hand them over to the accounting teams?
A. At first glance, probably yes. Especially if we just look at the logical starting point — how to calculate the CSM at initial recognition for the GMM. The calculation itself is not complex, and no history is required. But the subsequent measurement calculations are more complex, and they are not just a snapshot taken at a single point in time. The loss component needs to be tracked over time, and once it has been reversed, the CSM built up again. Additionally more generic accounting requirements such as the requirements around multi-currency accounting as per IAS 21, or the necessity to store accounting information in an auditable fashion over many years, or the practical need to be able to perform manual adjustments which can be automatically reversed at a future point in time. All these items should be considered before making a decision which software can best help you to get compliant.
Whether you choose to go down this path or not, it’s worthwhile to take a serious look at the solution — if you have an IFRS 17 issue to solve or simply because you know there is a lot of potential to make insurance accounting more insightful and more efficient.
For more information on SAP S/4HANA Financial Products Subledger, please go to our website here.
