There are several ways that property is depreciated in the US.  The requirements can differ between federal and state agencies, regulatory agencies, as well as which corporate department is doing the calculation.  For this blog, I’m going to get into the details of a particular US tax requirement and a common error that customers can experience post go-live.

 

Period Recognition

The IRS has several types of depreciation that it will allow for corporate deductions.  Most of the time we’re using an accelerated mid-year method but there is a different approach for real property.  Per the IRS regulation:

Real property is any residential property, rental property, non-residential real property, and railroad gradings and tunnel bores.

 

For this type of property, a straight line convention is used but it must be calculated using a mid-month approach as opposed to the normal mid-year approach.

The mid-month convention:  Under this convention, you treat all property placed in service or disposed of during a month as placed in service or disposed of at the midpoint of the month. This means that a one-half month of depreciation is allowed for the month the property is placed in service or disposed of.
 
SAP satisfies the requirement easily using a delivered period control method that is dedicated for mid-period calculations.

 

Is that It?

At this point, having a depreciation key that is properly configured using the right period control method… and you need to double check that you have the right one because SAP delivers 22 of them…  does not necessarily result in the correct calculation.  We’ve seen customers that had a correctly configured depreciation key but never validated the calculation.  The mistake is typically found years later during an audit.

What’s the missing piece?  In order for the depreciation engine to calculate this requirement correctly, SAP must first be setup to use half-periods.  There are a few options to handle this, each with its own pros/cons, but either approach will yield the correct calculated amount so long as it is active at the time the asset is initially posted to.  This last part is a key point to this topic.

 

What is the Issue?

The point of this blog is to document how the half-period functionality is changed post go-live.  In standard SAP, it is possible to activate or deactivate half-period functionality subsequently.  There is no error message when the configuration is made in development (either turned ON or OFF).  The change can then be transported throughout the SAP landscape.  

However, once the change is in production along with all of your data, and the values subsequently recalculated, the depreciation engine will error out.  Why?  The depreciation engine makes a check against the configuration (half periods ON or OFF) and the periods that the asset should depreciate over.  If they are not aligned, then an error is issued.  Since it is issued by the depreciation engine, this is extremely pervasive to most all asset processing. What do I mean by that?  Basically, there is a long list of processes that will error out every time you work with an asset(s) in this situation.  You won’t be able to…

  1. … make any postings of any kind to that record,
  2. … change any depreciation relevant parameter (depreciation key, useful life, etc.),
  3. … recalculate the asset’s values,
  4. … and in some cases run reports. 

This constitutes the vast majority of asset processing.  If the issue is widespread, and keep in mind that this can occur across the entire subledger, then the entire subledger would be rendered useless.

Keep in mind that while this example is about activating half-periods to support mid-month calculations post go-live, this same issue comes up anytime there is a change in the Fiscal Year Variant (FYV) from an FI-AA perspective.  If you are switching from a 13 period FYV to a 12 period variant (or vice-versa) you’ll have this same issue to deal with.  If you have a Fiscal Year conversion as part of a merger or just a change in the Fiscal Year definition, the same error will come up.  The last example is around daily depreciation.  If you are switching an asset (or the entire subledger) from a depreciation key that calculates using daily depreciation to one that doesn’t (or vice-versa), the same error will come up.  Those situations come up occasionally but it’s the half-periods requirement that we see far more often.

 

Common Symptom

The most common symptom of this problem is error message AA662 “SYST: You cannot change the depreciation periods”.  This error will come up if the configuration relevant to depreciation periods is changed in a live system.  i.e., if you have asset records with values… which can exist in development, QA and production… and you change the relevant configuration, you’ll get this error.

 

 

Solution

Assuming that the configuration change is required… and as documented above, it often is…  then the only correction to this issue is to run a custom report to fix the underlying table inconsistencies.  The change can not be carried out using normal means because the fields that are impacted are not editable using standard dialog transactions.  We’ve handled this situation dozens of times in R/3, ECC and now in S/4HANA.  If your system has not been correctly configured to account for mid-period depreciation conventions or if you are already experiencing this error message, please contact us for a remedy.

 

When You're Ready To Get It Done Right!

Contact Us