Reversing a Depreciation Run in Asset Accounting
There have been several postings on the ERP Financials and Asset Accounting forums in the past year related to the reversal of depreciation in the fixed asset area. I decided to write up a quick blog to discuss the SAP functionality provided around this topic. As a reference point you can first look at some of the forum threads and .
First, the Question
The question that has been asked is whether or not it is possible to reverse a depreciation posting run in SAP ERP.
To clarify, I’m referring to the reversal of a depreciation posting run, i.e. from the depreciation posting program RAPOST2000 (or RABUCH00 if you are on an older SAP release). This is different than resetting depreciation or adjusting depreciation… two other common phrases related to this subject area.
Now, the Answer
There is no standard solution offered by SAP to reverse a depreciation run. To even attempt a solution would require a significant series of adjustments to the associated FI-AA tables as well as the corresponding FI documents generated by the Depreciation Posting program. To create a solution for this that would still maintain proper consistency of the sub-ledger to support future depreciation runs and fixed asset reporting, as well as maintain the reconciliation between the General Ledger and the asset Sub-Ledger would be enormously difficult. For those customers that have a legitimate requirement to reverse a depreciation run, SAP offers a remote consulting service ($$$) to assist in this highly technical area… but this is not a standard solution and not freely available.
Resetting depreciation (transaction OAGL) should NEVER be executed in a live system. The only reason that SAP even delivers the program in the first place is to assist in the initial configuration and setup of a new ERP instance. As an example, during the initial implementation it is normal to have to execute the depreciation program multiple times to flush out issues surrounding account assignment, reporting, depreciation calculation, authorization, etc. During this time of constant change it is often necessary to reset the various asset tables so that depreciation can be run anew for a given company code or fiscal year/period. It is important to mention that there is no way to reverse the effects of a program like this. Also keep in mind that your userID is logged in SAP whenever this is run which provides a very easy-to-follow audit trail if it were ever necessary to track down who ran the program.
Adjusting depreciation… well, that’s a topic for about another dozen blogs. There are numerous ways to adjust depreciation in SAP and even more requirements based on transactional processing and reporting.
Oops... I did this once for a client in their live system. This was two months after implementation. Asset upload was completely wrong (of course done by someone else..), golive date was something like 1st of May, asset net values were according to 1st of June by upload (one month extra depreciation) and the "consultant" somehow managed to depreciate one month as extra in SAP after upload (so, all tohgether there was two months difference comparing to the real values). There did not seem any other feasible solution, than to clean up everything with OAGL and start again. And it turned out to be a success, however I don't want to encourage anyone! 🙂
ec
Well... in that crummy situation I'm sure we could agree that it was never truly 'live', right? So running OAGL and OABL would be an acceptable solution. :-0
While at SAP we would get at least one customer per year that had executed either of those two reset tcodes in their live system. Sometimes it was run accidently (but why is their company code in test status?) and other times they actually did it because they didn't like the financial results that they were looking at. Absolutely ridiculous.
Thanks for the comment.
-nathan
we have a company code that went live in may. the assets for this company code were transfered from another company code. the asset capitalisation date is on 05/31/08, the system calculated dep from june 01. the depreciation has not been posted yet for the assets in this company code. we are having some issues with the periods. either the close was not properly or the tables r not bein populated.
can we use OAGL, since the asset dep has not been posted yet in the live environment. I dont see another option, the settings all seem to be perfect.
I tested in DEV for OAGL and i am able to run the dep. for the required period.
Is there a way around? the help would be really appreciated.
We are in sap Ecc 5.0., using fiscal year variant is v3. My client performs manual depreciation for all periods for the year 2006, For the period 6 SEPT he mistakently executed unplanned depreciation for all assets in production server.
When i am looking in t.code AW01N it was showing me 124.65 in unplanned depreciation for an particular asset and it was posted with the same document number along with ordinary depreciation.Reversing an document will reverse the posted depreciation also which effects FI.(which should not be done since the books are prepared for 2006).
While uploading the balances on 30.9.2006 from legacy data they uploaded the asset balances with CALCULATED ORDINARY DEPRECIATION FOR 6 MONTHS -which is their mistake.
How can i remove that unplanned depreciation for all the assets for the particular year 2006 in production server with out changing the depreciation amount in FI --Because all the statements are made and the returns are filled with the authorities for the year 2006.
No transaction has happened in production server after these manual depreciation in 2006.
Now the client want to close the financial books for the year 2007-2008 ie 2007 for which no depreciation run has been executed as of now.
Since Asset accounting allows only two fiscal years & in the experts view in (sap img) it was showing the year 2008.
how can i move ahed for depreciation for 2007.
Whether reset posted depreciation is an option..Whether it reset the depreciation for all years or for an single year.
What is the effect of this in fi?
Pls guide me
Thanks & regards
Sandeep jain.
Hi Nathan,
That's fine but you have not explained why SAP is designed in such a way that planned depreciation cannot be reversed when as per the accounting principles it is not very wrong to do so...Is this functionality missed out by error?
Hi Mahendra,
what do you mean with "planned depreciation cannot be reversed"? This statement is incorrect, planned depreciation can anytime be changed in open fiscal years. For example if you would want to set the planned depreciation to zero you can change the depreciation key that way that planned depreciation zero is calculated (e.g. key 0000), and the system will adjust the planned depreciation.
The depreciation run will adjust the postings as of the next execution.
Regards,
Markus
Hi,
Yes depreciation keys can be used to post an adjustment value in the next planned run but i cannot reverse the posted depreciation. The posted depreciation will remain there further it will be cumbersome to use depreciation keys to reverse.
It will be easier to actually use AB08 to reverse the planned posted depreciation but the posted planned depreciation won't be listed there for reversal. This is what i want to understand, what will terribly be wrong if you can just list the posted depreciations in the AB08 screen for reversals so that it makes our life easier and straight forward?
Yes it might be easier but that would first mean that depreciation would have to be posted at the asset level. For performance reasons this is not practical.
that's means the only way to adjust depreciation to make manual JV.
Simple and well explained blog...Repeat / restart / write -up are few options i guess to make things work.
Good one
Well explained and good one....
Very helpful!
Valuable blog thanks for sharing
Happy New Year nathan
Regards
Diwa
Its very Helpful Mr. Nathan.. 😎
thanks very helpful
good one.. Very useful
useful blog
Hello,
Super.
Thank you for sharing knowledge.
all the best Erwin
Very enlightening topic. Great. Thanks.
very helpful blog. up for this one.