Intelligent Asset Accounting in S/4HANA (Part 1): Introduction

Ever since SAP released S/4HSAP Cloud they’ve been continually revamping the finance solution to deliver real change and transformation to their customers. For those that have been implementing the OnPremise solution (aka, Private Cloud), a lot of those changes have not yet matriculated down to them. But with S/4HANA OP 2023, SAP has made available a new solution called Universal Parallel Accounting (UPA) to streamline the parallel accounting elements across all of the various finance modules.

This prompts some obvious questions… What is included in UPA for SAP Finance?  What are the impacts on Fixed Assets?  What are the technical chanages?  And what is the best way to migrate to this new solution?

Let’s get started!

Where to Start?

First, we have to level-set a bit and review SAP’s history in regards to parallel accounting.  This should highlight the current solution (prior to UPA) as well as the main advantage that UPA presents for this topic area.

If you go all the way back to R/3, there wasn’t a solution for parallel accounting even just within the General Ledger must less throughout FICO.

Once we went through the transition to ECC, this didn’t change at all until the NewGL was introduced circa 2005.  A lot has been written about the NewGL so I don’t have to go into too much background on it, but its major contribution to this topic was the introduction of a new Ledger field directly in the accounting code block. This was required because we had to have a way to separate accounting entries within FI.

Prior to implementing the NewGL… because it wasn’t something that customers could migrate to quickly… customers who had to be compliant with parallel accounting requirements had to use the so-called account approach.  This required an extensive re-design of the Chart of Accounts.  You had to break out GL accounts for each required GAAP (i.e., IFRS and a Local GAAP) and then retain your existing GLs as a ‘shared GAAP’ account.  Here is an example:

You could easily improve on the above approach by using ‘I’ for IFRS, ‘L’ for Local and leave the existing cash account alone as the common account. There were also some advantages to using a suffix but it was more of a pain to work with when entering in specific GL accounts for one of the valuations.

Here’s another image that we used a lot back then to show how the GL accounts, when combined, could be used when reporting for multiple valuation requirements.

The big downfall of this is that it was isolated at the GL level.  Fixed Assets had their own convuleted solution to abide by this which was based on depreciation areas.  The other modules had their own struggles… so everyone had their own unique solution and it wasn’t consistent within the system.  This makes reporting inconsistent, impedes integration, and is just generally more difficult to work with in FICO.  After all, it’s hard to integrate a dozen different finance modules if they don’t have a consistent code block between them other than the company code.

What happened in S/4HANA?

Once SAP introduced S/4HANA, they officially commited to a single GL and Fixed Asset solution.  Customers no longer could choose if they wanted the Classic (Old) or NewGL, or the Classic FI-AA vs New Asset Accounting.

SAP had also continued to work with the GL with different ledger solutions, a more prominent focus on Accounting Principle, and deeper/tighter integration between the GL and any feeding module.  I covered this extensively in our 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?

So… they made great progress in the GL and FI-AA areas for parallel accounting… but it wasn’t quite consistent or unified throughout the rest of finance.  For instance, the slide below (source: SAP) zeroes in on the finance modules that were most impacted by this; Fixed Assets, Material Ledger, and Controlling.  Each of these uses a different element as its core component when tracking different values in parallel.  In Fixed Assets, it’s the Depreciation Area.  In CO, it’s Versions and in the Material Ledger they use the Currency Type.  You’ll notice that none of these use Ledger which is what is used in the GL.

With these differences between the solutions there is no way to have a unified parallel accounting solution.  It’s hard to feed that data into the GL because of that missing integration element (Ledger) and you also can’t report within these modules at the Ledger level.  And most importantly, this isn’t something that can be solved via more code or some new reports because the underlying technical architecture in these solutions don’t segment their data in the same way that the GL does with Ledger.

Let’s look at a specific example in fixed assets.  One of the most important core processes we handle is the inbound acquisition postings that are usually coming in via settlement from a project.  Now, I’d wager that every PS or Asset consultant you talk to will tell you that settlement is done uniformly to all depreciation areas on the AuC…  and that it’s not possible to settle costs at the area level.  Well, they’d be wrong because there is a way to handle this using capitalization keys!  It’s not well known and not documented except in a very basic way.  Also, I’ve only seen it covered online one time so it’s clear that the industry isn’t aware of it (at least, not broadly).  We’ve implemented this solution frequently because in the US it’s not allowed to settle the amount of capitalized interest to the tax books.  You can settle those costs (and everything else, i.e., 100% of the balance on the WBS) to the corporate book but not the tax books.  So long as you track the amount of capitalized interest on a GL account(s), this solution works everytime.  But it’s not very well known and therefore rarely implemented.

There are some other examples for the costing/controlling and material ledger areas but the slide above gives the the most prominent examples of a limitation in FI-AA because of an inconsistent architecture design between it and the GL.  The other areas have similar limitations because of their reliance on Version and Currency Type.

Introduction of Universal Parallel Accounting

With UPA, SAP is making another significant architecture change.  This is made possible by the previous introduction of the Universal Journal since all of these feeder solutions are all posting to the same target.  The change they’re making now is to unify everything around the ledger.  The ledger is now the only valuation-relevant integration object used in each area and will be a unifying field so that each of them can integrate with each other. 

There are some key points about the slide above that need to be understood.

First, the ledger group and accounting principle are still important (and both are used in FI-AA) but it’s the ledger that has been designated as the go-forward entity to drive integration throughout finance.  That’s the ‘lead’ object.

Second, this impacts not just the GL but all feeder modules.  All of them have to support the ledger so that all postings, costs, and valuations are ledger specific throughout their process flow.

Third, by unifying around the ledger we will get more consistent reporting.  Since ledger will be used in each module and done so consistently, we’ll be able to run reports on assets, project spend in PS, inventory valuation in the Material Ledger, various CO reports on cost centers, and of course GL account based reports in the GL by ledger.  You can expect it as a main selection or filter criteria in all of the reports in those modules.

Lastly, by introducing and enforcing the Ledger in each module, SAP will achieve another technical goal where all of these modules have a more consistent design.  This will lead to better integration between the modules and set the table for more innovation down the road in future releases.  The Universal Journal (aka, ACDOCA) was the first stab at this goal but it wasn’t complete.  In fixed assets, we still had FAAT_DOC_IT and the other modules still had some lesser known line item tables.  Now, those redundances are being removed and pushed into ACDOCA. 

End-to-End Value Flow

Let’s talk about that last point a bit more.

Prior to this change parallel accounting was possible but in a more limited way.  In particular, as you went through your normal capital accounting process flow (i.e., project to asset settlement) and then kept going through CO, the ability to separate the different valuations reached its limit.  You could retain some of the parallel valuations by ledger from the project to the asset, but once you were operating within CO there was no longer a way to separate the different valuations because the leading ledger values (the blue lines in the below graphic) are applied to all ledgers within CO.  This is what caused manual adjustments, allocations, or additional revaluation activities at month-end.

Now to be honest, most management accountants (the CO folks) aren’t really concerned about this topic.  They’re mostly only concerned with the group valuation/GAAP and not the local statutory valuation so the fact that the local valuation is lost in the value flow just isn’t a concern to them.  However, there is a major technical concern here.  By introducing Simple Finance and the Universal Journal in S/4HANA, SAP has started to tear down the wall between FI and CO.  SAP is getting closer and closer to just having a single financial solution instead of the historical ‘dual ledger’ solution of FI and CO.  This greatly improves integration which improves reporting.  In our capital accounting specialty, we see this all the time with the project-to-asset process flow but there are other examples in inventory valuation and WIP calculation as well.   These are the areas that historically have been difficult for SAP to maintain parallel valuations.

But with UPA, there is a complete separation of the valuation postings throughout all of these modules.  We can now make ledger specific postings not just on the WBS but during it’s settlement to the asset, and then throughout the rest of Finance and the Material Ledger.

What Else is Addressed in UPA?

There are some other items included in UPA that are of particular interest to me.

First is the ability to implement an Alternative Fiscal Year.  In the past, Yes, we could assign a different fiscal year variant (FYV) to the asset company code and could also do it at the depreciation area level if necessary.  But there were restrictions on this that made it of little benefit for those customers with local requirements.  There are some countries that require financial statements to be provided in a fixed Jan-Dec calendar FY regardless of how your corporate FY is defined.  To continue with their mission for a complete parallel accounting solution, SAP is extending the scope of UPA to cover this requirement as well (parallel FY?).  For assets, they have a new solution to manage this that is far more flexible particularly as it handles post-capitalizations.  There are some gotchas but I’ll cover that in another blog.

The other significant benefit is in the area of multi-currency.  The Universal Journal introduced up to 10 additional currencies but that was only for ACDOCA postings.  Yay!  But it wasn’t a full solution where every feeding module would also have to track those currencies in a similar way.  In fixed assets, we had a parallel depreciation area which would then feed the Universal Journal but this would require one area per additional currency.  But those don’t post to the GL so you end up losing some detail between the two… it’s not clean.  Also, there were other limitations in CO and the Material Ledger (take a look at notes 2894297 and 2344012) that have now been addressed.  I’ll cover those impacts on fixed asset design in a future blog.

Here are some more benefits from UPA (some mentioned above) that are worth mentioning:

• The configuration throughout the GL and the sub-modules has been streamlined considerably.
• There is an updated UI in Fiori… big changes there for fixed assets.
• More consistent, integrated, and comprehensive reporting
• Less reconciliation
• More unified and consistent processes which should yield process improvements

What’s Next?

The next blog will introduce SAP’s new next-generation fixed asset solution; Intelligent Asset Accounting (IAA).