After spending so much time on our tax depreciation blog series (link:Â Handling US Tax Depreciation in SAP (Part 1): The Basics) I wanted to cover a related topic that the majority of SAP customers eventually have to deal with.
Two Important Items
First, let’s quickly discuss how SAP projects categorize success and failure. This shouldn’t be a surprise to anyone but rarely is an SAP implementation 100% successful. Of course it depends on how you want to define success but within this topic area, if you go-live and then find out you’re missing some depreciation areas, then something definitely went wrong during the implementation. That’s not meant to be a criticism because there are a lot of competing interests on enterprise IT projects. Sometimes people forget just how intricate and massive these projects can be. It’s hard to get it even 90% correct much less 100%. If you don’t believe me, start googling around on ‘Enterprise IT failures’ and you’ll find an entire topic area that folks like Diginomica and other industry analysts frequently cover. But back to my point, if you’re missing an area for a particular valuation requirement and you just spent an entire 12 months focused solely on this topic area… well, that’s a failure point of the project.
Secondly, even if the original implementation was 100% accurate and successful in the area of fixed assets, we all know that businesses change. As the years quickly go by post go-live, new regulatory requirements or laws are passed that require additional asset valuation approaches. Sometimes it’s an industry specific valuation requirement that will trigger the need for a new depreciation area.
What Now?
The key question then is… is it possible to add a new depreciation area post go-live? After all, the depreciation area is a major organizational element of the FI-AA subledger and it’s usually not possible to add something of that magnitude in a live system.
The answer is a definite ‘Yes’. It’s easily possible to define a new area and have it work going forward for all newly created asset records. The key in this situation is to add it to the existing assets so that it’s consistently applied for all relevant company codes. That way you can immediately report on the new area for the entire company.
Let’s dive into it.
Why Is This Necessary?
New areas are often required for a change in valuation and there are many examples that have driven this over the years.
- Ledgers in the GL — When the New General Ledger (NewGL) first came out and introduced a Ledger field in the FI code block, then the asset subledger had a new requirement to fill the values stored in that ledger. That required a new depreciation area in FI-AA to map to the new ledger. Without it, how else could the new ledger (ex. IFRS valuation) be populated when the subledger itself didn’t have an area tasked with managing that valuation? When the NewGL projects came out, we were constantly helping customers create new areas to map to the new IFRS ledger. SAP formalized a lot of this process with their Switch2IFRS (S2I) initiative and even made several changes to RAFABNEW to improve the program for this specific scenario.
- Tax Requirements — The majority of the time that I’m creating a new area it’s usually for tax. The most common requirement was for a bonus vs. non-bonus tax valuation but we’ve also done it for state taxes or other niche country specific requirements.
- Re-implement tax — Similar to the previous point, there have been cases where we’ve decided to delete the existing tax books and completely re-implement them. I’m talking about doing that in a system that has been live for 10+ years! Yes, it happens! The tax area is frequently messed up during the project because the FI folks usually aren’t aware of the intricacies of the tax calculation and mess up the values/config from the very start. At that point the customer has to start extracting all of the data from area 01 each year and preparing their own asset tax datamart offline. Of course, that isn’t timely or accurate and something that the CFO/CIO probably aren’t pleased with after having spend tens of $millions$ during an implementation. Most customers eventually push to get that information back into SAP. It’s happened (way) more than once during my career.
- Asset Revaluation — I’ve always created a new area for a revaluation project (AR29N).
- Another common example I can think of is much smaller in scope. Sometimes someone will deactivate a specific area when creating the asset at [AS01]. Once the asset has been posted to you can’t just re-activate the area. You have to go through this process of adding it to the live record.
- The last example would be what I covered earlier. SAP implementations are difficult and it’s not uncommon to make a mistake in the depreciation area setup that has to be fixed post go-live.
What are the Limitations?
There are several issues with RAFABNEW that I have to keep in mind when using it.
First of all, this program is the most frequently copied and changed Z-program in the FI-AA subledger. Every module has a program like this… where the delivered program works for 99% of the requirements but the customer needs a small change (or a few of them). In these situations we just copy the program to a Z-version and then make the necessary changes to it. That way the standard program is still available and not modified.
The reason why it’s sometimes necessary with this specific program is that each of the below issues are quite small and easily solved with some simple code. The problem is that if you have a few of these that are impacted by the requirement, the changes start to add up which can create a bigger testing situation and adds more risk to the endeavor. The good news is that we’ve had to go through this so many times that we have a version of this program that handles all of these limitations. Here’s the list…
- AuCs with Line Item Settlement — The standard program won’t handle AuCs from investment measures that are configured for line item settlement. This scenario happens to be the most common implementation and usage of AuCs with projects or orders. If it’s not dealt with you’ll have a series of errors when the projects/orders are settled which will hold up your period end closing.
- Fiscal Years — The standard program only copies values for open fiscal years. But the business requirement, from a reporting perspective, often requires multiple prior years to be reported on using the standard asset reports. This is almost always the case with a new tax valuation requirement.
- Deactivated Assets — SAP tends to ignore deactivated assets in several other processes and that includes RAFABNEW. However, it’s a common requirement when creating the area that the area’s reporting for the current year be complete. That means it has to show the asset retirement and proportional values related to that retirement for the current year for this new area. The standard program skips deactivated assets.
- Depreciation Area Defaults — SAP has some reasoning and logic in how the values are copied (go figure!). This impacts how the depreciation parameters (key, useful life, start date, scrap value, etc.) are copied to the new area on the asset. However, this rarely lines up with the business requirement usually because the whole point of creating the area is to create a new valuation along with it. Again, SAP has some reasonable logic about why they do it this way (feel free to reach out to us if you want to know the answer) but this often requires a subsequent change process. It is easily possible to just adopt the asset class defaults or run the program through a custom table for more advanced situations.
- Posted Depreciation — SAP doesn’t copy the posted depreciation values to the new area. There is a good reason for this but if it’s something that is required, it only needs a small change in the program logic to accomplish. This impacts the reporting on the area as well as the GL after you’re done.
- General Usability — So many people struggle with executing this program because it doesn’t have a basic ‘Copy From’ field on it. SAP doesn’t document what the ‘Copy From’ area is in configuration but it makes sense once you know the answer. But, in general, there aren’t many options on the program so most people struggle with how to run it.
- Selection Criteria — The program is run at the chart of depreciation level. This makes sense and, in general, you should be consistent in a way that the new area is inserted uniformly for all relevant assets. However, I’ve had valid requirements from customers where they wanted certain companies to not get the new area. In another situation, it might be helpful to run the program at an individual asset level for test purposes. SAP routinely allows this to happen… selection by asset in test mode but it has to be run at the company code level in update mode. Running depreciation at AFAB comes to mind as an example. Anyway, with RAFABNEW, we don’t have that option.
What’s the Process Like?
Well, this blog has already run a bit long so I’ll push the screenshots into a subsequent post.
