S/4HANA New Asset Accounting (Part 2): History of Parallel Valuation

In the previous blog (S/4HANA New Asset Accounting (Part 1): Introduction) we uncovered some basics of what S/4HANA is relative to SAP’s ERP solution offering. We’ve also already covered some specific changes in the IM and PS areas. Now, on to New Asset Accounting.

Blog Series:
S/4HANA New Asset Accounting (Part 1): Introduction
S/4HANA New Asset Accounting (Part 2): History of Parallel Valuation
S/4HANA New Asset Accounting (Part 3): SAP’s Asset Parallel Valuation Solution FIN_AA_PARALLEL_VAL
S/4HANA New Asset Accounting (Part 4): Functional Improvements
S/4HANA New Asset Accounting (Part 5): Technical Changes
S/4HANA New Asset Accounting (Part 6): Should you Migrate in ECC?

What started all of this?

The Asset Accounting (FI-AA) area of SAP has seen a lot of changes over the past decade. No, there hasn’t been a lot of fanfare and marketing spent on it but SAP Development has been busy re-coding select programs on ECC since the mid 2000’s. The Revaluation program RAAUFW02, Depreciation RAPOST2000, and some other reports have all been completely re-written. Then the NewDCP was released which was a major change for the asset community. The new depreciation engine provided significant improvements in how depreciation was calculated as well as several features that made it more compliant with country/regulatory requirements. It was a pretty big deal back then and is a foundational element to New Asset Accounting today as well as some other asset-based solutions that SAP has. But none of these changes were the driver for New Asset Accounting. What was?

Parallel Valuation

The real origin of New Asset Accounting was with parallel valuations. Let’s go back and cover some history first.

Parallel accounting requirements started to surface in 1998 but didn’t really mature until the early 2000’s. The problem? How best to manage financial activity in a second GAAP in addition to the existing local GAAP (usually US GAAP for our customers). This created a significant challenge to customers, auditors, and software companies such as SAP.

Remember that back then, we had two distinct ledgers; FI and CO. Financial postings could be made in one, or the other, or both depending on the data being posted. As compared to a single coding block from the mainframe era, SAP’s approach was more modular but not necessarily simpler for those that were new to it. I wrote about that previously here: Making SAP Software Simpler (Part 2): The Journey Continues.

How best to handle this new and growing requirement? Well, Special Ledger had some possibilities. SAP also (very quietly) introduced a new module called the Flex Ledger but neither it nor Special Ledger were built specifically for parallel valuation. For those customers that had a definitive requirement back then, the best way to do it was using parallel GL accounts.

Solution #1: The Account Approach to Parallel Valuation

The account approach meant that you had to essentially duplicate your GL accounts to handle each valuation requirement. You had to create new GL accounts that were pure IFRS accounts and another range of GLs that would be used for both valuations. Combined with your existing GLs that were already capturing local GAAP requirements, you could back in to an approach to track costs for both valuations. The slide below has a good diagram showing how the accounts should be split. What it doesn’t show was that you also had to design a series of complex validations to ensure that the parallel requirements were being met. I wouldn’t consider this an elegant solution but it worked at a time when there wasn’t specific FICO functionality to handle parallel valuations. There is some more information here.

Solution #2: SAP NewGL and the Ledger Approach to Parallel Valuation

SAP’s response to this requirement was to unify the two separate FI and CO modules into… guess what?… a single code block. It introduced the concept of a ledger and a ledger group to the code block. Later, they added an Accounting Principle as a way to streamline the solution. Of course, what I’m referring to is the New General Ledger (NewGL), now called the SAP General Ledger.

The biggest driver for this change in the FI/CO and GL architecture was the need to report financial results simultaneously under multiple accounting requirements such as US GAAP and IFRS, and to do so without cluttering up the chart of accounts. Note: SAP prefers that the chart be composed only of ‘natural’ GL accounts and that no other element contaminate the definition or usage of the GL account. Customers had requirements for parallel accounting in the past but once IFRS was codified and had a prominent seat at the regulatory accounting table, the SAP financial solution had to account for this in a more fundamental way.

Once SAP released the NewGL, there was now a second approach to solving this via the new ledger field. SAP referred to this as the Ledger Approach. The ledger approach relied on the new Ledger field which was used to segment the posting between one ledger (i.e., US GAAP) versus another (IFRS, Tax, FERC, etc.). The ledger was officially part of the FI posting interface and had to be accounted for as part of any FI posting. This was the case regardless if it was manually done by a user (ex. creating a posting at FB01 shown below) or automatically via the RWIN interface from another module (ex. an asset posting that was initiated from a project settlement to the asset).

Impact on Fixed Assets

During the NewGL renovation of FICO, the one module that was impacted the most (other than the GL itself) was FI-AA. Why? Because FI-AA is a subledger to the GL, it is the subledger’s responsibility to perform all calculations, valuations, and prepare the data to be posted. Nearly all of the data you see in an FI-AA generated GL document comes from the subledger, not the GL itself. It is FI-AA that has to send data via the RWIN interface so that the GL document is correct. This includes the actual structure of the line items in the FI document. Since the code block of the GL changed, it’s the asset subledger’s responsibility to provide the necessary data for the document to be posted. Besides, FI-AA has been maintaining parallel valuations of an asset anyways so it wasn’t overly disruptive to the solution for the subledger to provide those values. (Or, was it? I’ll get back to that later.)

The Fixed Asset Approach to Parallel Valuations

For parallel valuation requirements, the subledger had to start to provide the values for each ledger configured in the GL. Since each ledger had a different accounting treatment, different depreciation areas were required to be present on the asset that aligned with that accounting valuation. How was this done? Here’s an overview… I won’t go too much deeper into the details because this solution is no longer possible with New Asset Accounting.

First, we need a clearly defined set of ledgers / valuations in the GL. This is to support both local GAAP (US GAAP to me) as well as IFRS or additional GAAP requirements (i.e., tax or a regulatory requirement such as FERC).
Each of these ledgers need to map to a specific depreciation area. For instance, we use area 01 to manage the local US GAAP and area 10 to manage IAS/IFRS.
In addition to these, we’ll need a derived area in FI-AA. This is used to capture differences in the postings, as driven by the different GAAP requirements, between the valuations and ensure that those differences are posted up to the GL. This way, the asset subledger can remain in sync with the GL.

The image below summarizes this design approach.

The problem with this is two fold. First, it requires a derived area. Derived areas are primarily a reporting construct and were not originally intended to track values in this manner. It works… but it’s not ideal. I don’t think SAP ever intended or wanted to use derived areas in this manner but until New Asset Accounting came out, this is the solution that was used. Secondly, it required that values from the derived area be posted to the GL. SAP had long had an additional month-end job to post values periodically. The problem in this case is that the program, RAPERB2000, never went through the harsh real-world field testing that was now thrust upon it with the IFRS parallel valuation requirement. The program worked fine to track some values from a particular reporting area (i.e., tax) and post them to an alternative range of GL accounts. But very few customers used it this way. Now, the entire SAP customer base was pushing a massive amount of documents through this program and there were, not surprisingly, a few growing pains. The program is not real time (another drawback) and eventually you get some failed updates. V2 failures are fun the first few times you deal with them but certainly not on a monthly recurring basis.

This solution worked, but it wasn’t ideal.

The next blog will cover the specifics of SAP’s solution to manage parallel values and the introduction of FIN_AA_PARALLEL_VAL.