I wanted to quickly cover a topic in SAP Fixed Assets (FI-AA) that we rarely see here in the US. In fact, I’ve only seen two customers in the US use this depreciation functionality and both did so incorrectly (reference: I’ve been working on SAP since 1996). The first customer brought us in to turn off this functionality that was used across the subledger. That required a special custom correction program to be written and applied. This impacts how depreciation is calculated on the corporate book so it took about a month to spec, build, test, and implement throughout their landscape. The second customer… which is the reason why I’m blogging on this topic… is using this functionality but thought that what they were seeing was just ‘the SAP way’. i.e., standard functionality. They never thought that there might be a different way to calculate depreciation.
Â
What are we talking about?
The issue I’m covering today is referred to in SAP as ‘Depreciation to the Day’ but a lot of us just refer to it as ‘Daily Depreciation’. SAP doesn’t cover it too much in the documentation because it’s such a small item but it is briefly mentioned here in the SAP Help.
SAP uses a specific formula to calculate the annual depreciation for an asset. Needless to say, there is a lot that goes into it… but once that annual amount has been calculated, it then divides it over the number of fiscal periods to arrive at the monthly depreciation amount.
To be more specific, in ECC this monthly calculation is only performed at runtime. i.e., during the depreciation posting run, reporting, or the Asset Value Display (AW01N). It doesn't store the 'to be posted' monthly figure anywhere in the database... only in memory.
In S/4HANA this has changed. Once an asset record is valuated (new posting, or the balance carry forward), then database records are created for each of the planned monthly amounts.
What complicates this is the daily depreciation functionality. If it’s active, SAP will carry out one more calculation where it allocates the annual amount to each month based on the number of days in the month. It’s simple math… January uses 31 days over the total of 366, February uses 28 or 29, etc. Here’s an example. The below asset is a new record and acquired on the first of the year for 60,000.
It is depreciating using a straight line convention for 5 years.
5 years = 60 periods. For a $60k asset, that works out to a nice, even, predictable, and confidence inspiring $1,000.00 USD per month. Simple math!
Here is a different record. Same posting, amount and useful life as the above asset but the depreciation key assigned is configured for daily depreciation. Here we see that the monthly depreciation figure fluctuates based on the number of days in the month. There isn’t anything wrong with this but it’s not the normal math that most of us are taught when it comes to accounting for fixed assets.
Where is it required?
SAP designed this functionality back in the 1990s for a specific requirement in France. Since then, other countries (India and Thailand) have also specified a similar daily depreciation requirement but it’s definitely not a global standard. Here is some more information from SAP note 1940343 (emphasis mine)
This SAP Note describes the general conditions for using the "Depreciation by days" function. The function "Depreciation to the day" was released in particular for the country-specific requirements of France and Thailand.
And more from SAP note 2449030.
Depreciation to the day was created in accordance with legal requirements in France and Thailand.
Where Serio Consulting does most of it’s work, that being the rest of the EU and North America, daily depreciation is not a defined standard. To be fair, the accounting regulation boards in those countries don’t go to the trouble to define the requirement at the monthly level so it’s not been 100% addressed. However, I’d guess that the reason it hasn’t is because they have the same mindset that I do… which is that it should just be allocated evenly over the number of periods in the year.
Â
Why is it bad?
There’s a few reasons why this is bad. Obviously, if I have a specific requirement that requires this functionality than I’m happy to activate it. But minus that requirement, either regulatory or just the customer’s stated preference, it shouldn’t be activated for the following reasons.
First, as shown above, it causes the monthly depreciation amount to fluctuate. With all of the variables that go into the depreciation calculation particularly on large assets that have numerous postings, being able to justify and substantiate the calculation in SAP is both financially material and important in terms of establishing trust and confidence in the system. If the customer has nagging thoughts that the figures are incorrect, they’ll eventually find alternative solutions outside of the system. I routinely have to troubleshoot important depreciation issues and having this one extra variable just makes it so much harder… and doesn’t provide any benefit either!
Also, I’m not sure it’s to the company’s advantage because it delays the recognition of depreciation. I took the daily-calculated monthly figures from the image above and put it in Excel. As you can see, with the exception of period 1, the asset’s accumulated depreciation (column D) is below the 1,000/per month run rate every month until period 8, 10 and 12. So why do it?
Secondly, once the asset has been marked as using daily depreciation, you can’t turn it off using normal means. In a way, it ends up poisoning the asset record! I can’t change the key to a non-daily key, can’t change it to key 0000 to stop depreciating… once it’s active on that asset, it always will be. The only in-system solution I can think of is to transfer the value to another asset that is not using a daily depreciation method but that shouldn’t be done in mass. I’m not sure if you know but the hardest process we have to deal with in SAP FI-AA are transfers… I don’t like using them to fix other problems because they invariably cause their own. That said, it is possible to disable this feature using a custom correction program.
Â
Can it be turned off?
Yes. As I mentioned at the top of the blog, Serio Consulting has had a US customer that wanted to disable this globally because the previous implementation team incorrectly activated this functionality. It took about a month but we were able to develop the program and stabilize the calculation for them. Reach out to us if you’re interested in getting rid of this confusion functionality.
Reference:Â Error AA662: Changing Half-Periods for US Mid-Month Depreciation
