@alymaghrabi2
Since your use of AMORLINC returns numeric values, obviously the problem is not related to the parameter separator (semicolon vs comma). Using the wrong parameter separator would result in a syntax error, not unexpected numeric results.
-----
Unfortunately, the MSFT Excel support page (click here) for AMORLINC is light in details. And that is an understatement. :sigh:
For more details, I suggest that we refer to the LibreOffice Calc documentation page (click here). Keep in mind that there might be differences between Calc and Excel. But to the point, the Calc documentation has some useful insights. And one point, in particular, might explain the "issue" that you have.
First, I note that you are using day count basis 0, which treats the year as 360 days and each month as 30 days. Elsewhere, Excel documentation explains that for day count basis 0, month day 31 is treated the same as day 30, as we should expect.
Thus, in the two examples whose results you say are wrong, the purchase date is effectively the same as the first period end-date, since DATE(2023,12,31) is treated the same as DATE(2023,12,30).
Second, note this excerpt from the Calc documentation page:
``Calc and Excel behave differently when the date of purchase coincides with the end of an accounting period. Calc regards the initial period 0 as of zero length, and thus returns zero depreciation. Excel regards the initial period 0 as the first full period.``
Consequently, for your example, Excel should (intends to) return 25% of the cost (according to the Calc documentation page). And it does.
I am not familiar with the French Accounting Standards. So, I cannot offer an opinion about whether the Excel behavior is correct or not.
(Okay, I can't resist. :wink: Conceptually, I agree with Calc, although the devil is in details that I'm not taking the time to verify. But again, I don't know if the FAS says otherwise. :surprise: )
If you can document that the Excel behavior is contrary to the FAS, you might consider using the Office Feedback feature to complain to MSFT.
But IMHO, that would be a waste of time. Even if MSFT concedes the error, it is not likely to fix it because of concerns for backward compatibility.
