 # Depreciation calculation is not correct

@lubos @Tut
Purchase Value 5000, depreciation rate 20%, purchase date 4th dec

For dec 2019 (calculation for 4th dec to 31st dec 2019)
system calculation correct

Calculation for dec 2019, (1st dec to 31st dec 2019)
system calculation is not correct

system didn’t calculate for the whole month

2nd month onward, calculation wrong
system calculation didn’t consider leap year, amount calculation was on book value not on acquisition cost

expected result must be
1000/366*31
84.70

You need to carefully read the Guide: https://www.manager.io/guides/25021. Your screen shots illustrate you are not following it.

If you still believe these things after reading and following the Guide, please explain why and illustrate with further screen shots.

for 1st month, we can do adjustment>> then solve it out
for 2nd month, why system calculated on Book Value instead of acquisition cost

system didn’t calculate for the whole month

2nd month onward, calculation wrong
system calculation didn’t consider leap year, amount calculation was on book value not on acquisition cost

expected result must be
1000/366*31
84.70

@San_Thida_Myo_Latt, all you did was restate your original points. You did not explain why you think there are errors, as requested. And you have not shown any departure from functioning of the worksheet as explained in the Guide.

Because that is what the worksheet is designed to do, as very prominently stated in the Guide. It calculates depreciation using the declining balance method.

Why do you say this? It calculated for all 31 days in January, using the daily depreciation rate it calculated from the notional annual rate. This is also explained in the Guide.

Your expectation of a certain result does not make the program’s calculation wrong. Nowhere does the Guide tell you the program uses your formula during leap years. It explicitly says the daily depreciation rate is calculated from the notional annual rate for a typical, 365-day year, and that the daily rate is applied for the number of days in the period. The Guide tells you the depreciation calculated in leap years will be slightly higher.

There are probably as many ways of calculating depreciation as there are accountants in the world. Manager’s method is valid and widely used. If you don’t like it, calculate your own depreciation and enter it manually as described here: https://www.manager.io/guides/9119.

@San_Thida_Myo_Latt you have highlighted the 2 reasons why I have decided not to use the newly introduced Depreciation Worksheet.

1. Calculations in a leap year (rightly or wrongly) are different to the way I have calculated for my existing assets over many years.
2. The worksheet cannot be used on monthly basis as the worksheet uses the WDV (reduced balance) as at the start of each month (as opposed to the WDV at year start.)

I am hopeful that there are improvements in the pipeline that will address these issues so that depreciation calculations will reside in my manager database rather than the excel spreadsheet where they are at present.

You may not use the method Manager does, but that does not mean the worksheet cannot be used. If you are depreciating an asset monthly using a declining balance method, it is entirely appropriate to use the book value at the beginning of the month. Using the value at the beginning of the year would be some hybrid method and quite unconventional.

I have used a number of different accounting programs, over many years, that calculate and post depreciation on a monthly basis, based on the WDV at the beginning of the fiscal year, the number of days in the month, and the depreciation rate. In fact I have not experienced monthly depreciation calculated by using the WDV at beginning of each month at all.

You are correct, if Manager does not use the method I use it does not mean it cannot be used by others. However, IMO, there will be very few users that would want to calculate monthly depreciation the way that Manager does.

My previous post was to support the OP as I have experienced the same issues and to highlight that there may be other users with the same issue, with the view to flagging the need for improvements to the program.

If moderators of this forum continue to show a negative attitude towards genuine suggestions for improvements then I am rapidly coming to the conclusion that it may be futile to continue to be a contributor to this forum.

@generalegend, please do not misconstrue my message. My attitude towards improvement is not negative. I expressed my strong support for more robust depreciation options here: Depreciation Worksheet and Leap Years. I was merely making the point that the worksheet can definitely be used as designed, contrary to your assertion. I completely agree the current worksheet is limited in its flexibility.

thanks got it
normally we used straight line method
if manager can improve

2. Allow user to choose depreciation method
-Straight Line
-Declining Method

I have made those specific recommendations myself.

1 Like

WRONG, it is entirely inappropriate to use the book value at the beginning of each month, because it generates a totally false result because the asset base is being increasingly undervalued.

If an asset has an opening value of 5,000 and the rate is 20% then the annual depreciation is 1,000, however if you use the opening month value then the annual depreciation only totals 913 or 18.26%.

WRONG, using your suggested beginning of month value is the hybrid and quite unconventional method. The only way to correctly calculate a monthly depreciation is to repeatedly use the beginning of year value, as per the above illustration.

Totally and utterly agree, in fact the depreciation worksheet guide should warn users that the worksheet cannot be used on a month to month basis because the mathematical method being used by Manager will cause their annual depreciation to be undervalued.

The only way in which a user can use the worksheet for monthly depreciation would be by doing an annual worksheet and dividing the result by 12 or proportion it by days per month.

1 Like

@Brucanna, your statements merely confirm my earlier remark that, “There are probably as many ways of calculating depreciation as there are accountants in the world.”

Actually, what you have described and illustrated is not monthly depreciation via a declining balance method. It is annual depreciation, prorated to monthly installments. That is what I meant by a hybrid method. Under strict declining balance depreciation, once the first month’s depreciation is recorded, the second month’s depreciation can no longer be calculated on the basis of acquisition or beginning-of-year book value. The book value of the asset has decreased, and the next month’s depreciation is figured from the lower book value.

You correctly observe that the total depreciation over the first year, in your example, is only 18.26%, not the notional 20%. And that is true. One of the inherent features of declining balance depreciation is that depreciation tapers off over time and, absent lump-sum depreciation entries near the end of life, will never fully depreciate an asset. This is like trying to cross the street by repetitively covering half the remaining distance—you never make it to the other side. Many consider this method of depreciation to be more representative of actual asset value, since the fact an asset remains in service implies it has some value, rather than having its value drop to zero because some pre-defined lifetime has passed. Similarly, judicious selection of the notional depreciation rate can better model behavior of assets whose value declines very rapidly at the beginning of life.

Your statements suggest that you believe an asset with a notional 20% depreciation rate would be fully depreciated after 5 years. Under the declining balance method, that simply is not true.

You can like or dislike Manager’s methodology for depreciation calculation. You may also be restricted by law from using it. But it remains a valid approach and functions as described in the Guide, which is filled with notes and caution statements covering the limitations you raised. If you don’t like it, use your own method and make manual entries until more options become available. But please do not assert the method is wrong, even if you have never encountered it. Others certainly have, and the method is well documented in accounting literature.

20% per annum depreciation on a declining value is an exponential decay.
The maths is the same as compound interest paid over a term different to the annual interest rate normally quoted.

Mixing compound and simple interest calculations is wrong. When done correctly the percentage change for successive periods is the same but the dollar change is different for compound interest.

Also when done correctly the total change over sub period must add up to the quoted annual change. Not achieving this is also wrong.

That, of course, depends on how the rate is quoted. Just as with interest rates, depreciation rates can be quoted in many ways. And total depreciation over several periods depends on the calculation method used, in the same way that allocation of loan payments to interest and principal can vary, depending on terms of the loan.

Some loans, for example, are repaid on a fixed-payment method, with interest calculated on the declining principal balance. A mortgage repaid on that basis has a constantly shifting apportionment of the fixed payment to interest and principal. The amount of interest paid over a year will bear little relationship to the annual percentage rate and the initial balance.

Other loans call for constant interest payments with lump-sum or balloon principal payments at the end of the loan term. Still others capitalize some interest costs to achieve a desired repayment profile. As with varying depreciation methods, all are valid—assuming they are legal in a particular jurisdiction for the purpose of the loan, but produce different results.

The method by which Manager applies the notional annual depreciation rate you enter is fully described in the Guide. The fact is, it is not applied as an annual rate, but as a daily rate held constant over the depreciation period of the worksheet. But depreciation rates are typically given in annual terms, so that is what the program does.

In this case

an annual figure I believe, so the usual case.
So a calculation of sub periods which results in and annual depreciation of anything other than 20% is not correctly calculating the sub period depreciation.

That was my point, @Patch. Just as an advertised interest rate of X% seldom results in your paying X% of the initial principal balance on a loan over a year, a notional depreciation rate of 20% seldom results in depreciation of 20% of an asset’s acquisition cost over a year. And with declining balance depreciation, it never results in 20% in after the first period. When you move from annual calculations to monthly calculations, 1/12 of 20% of the acquisition cost is only figured for the first month.

A 20% annual depreciation correctly calculated will results in a 20% depreciation over a 12m period when calculated correctly.

The depreciation over any other period will vary depending on the depreciation method used.
In particular over 1 month it would only be (20%/12) if simple interest is used (not declining value).

For declining value / compound interest it is a larger percentage per month to achieve the 20% pa specified depreciation.

From memory the correct montly deprecation is
1 - (1 + 20%)^^(1/12)

We are quibbling over semantics, @patch. Notice that I keep referring to “notional annual rate” or “notional depreciation rate.” You keep referring to a 20% rate, without any modifiers. The Guide includes this in a Note:

None of the calculations are performed with the annual rate. That is just a more convenient way of entering rates, because that is how people usually think about rates. All calculations are performed with the daily rate.

Documenting a bug does not fix the bug, I just means there are 2 places to fix it.

Declining value is a compound interest calculation, and exponential progression. The mathematical calculations to extrapolate to a longer or shorter period are well established.

Which is not what is documented in the guide or apparently program behaviour.

I disagree there is a bug. The program behaves exactly as described in the Guide. And that behavior is mathematically correct.