AMORDEGRC

Quirk found

Category: Financial · Last tested 2026-09-01

Real compatibility results for the AMORDEGRC function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.

Support matrix

Engine	Documented	Live-tested	Verdict
Excel (desktop)	Yes	No — documented only	n/a
Excel for the web	—	Yes (recalc, 2026-09-01)	Quirk found
Google Sheets	No	Yes (Drive import, 2026-08-31)	Unsupported (not recognized)
LibreOffice Calc	Yes	Yes (25.8.7.3, 2026-08-31)	Quirk found

LibreOffice version history

We executed the same test cases under each LibreOffice release to show exactly when AMORDEGRC’s support changed — not documentation claims, real results.

LibreOffice version	Verdict	Tested
24.2.0.3	Quirk found	2026-08-31
24.8.7.2	Quirk found	2026-08-31
25.2.0.3	Quirk found	2026-08-31
25.8.7.3	Quirk found	2026-08-31

Why isn't AMORDEGRC working in LibreOffice?

AMORDEGRC exists in LibreOffice 25.8.7.3, but it is not a drop-in match for Excel — our executed tests found real behavioral differences (detailed in the test results on this page). If a formula that works in Excel or Google Sheets misbehaves in LibreOffice, compare your usage against the failing cases above before assuming your data is wrong.

Why isn’t AMORDEGRC working in Google Sheets?

Google Sheets does not implement AMORDEGRC: we imported the formula into Sheets on 2026-08-31 and every case came back #NAME? (unrecognized function). Sheets is a rolling service with no version to pin, so this is a statement about the service on that date, and Google’s own function list does not document it either. Rewrite the formula with a documented Sheets equivalent — see the Excel ↔ Sheets equivalents table.

Discovered quirks

=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8) on Excel for the web returned 886, but the documented/expected result is #NUM!.
Provenance
Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got 886
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8) on Excel for the web returned 937, but the documented/expected result is #NUM!.
Provenance
Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got 937
=AMORDEGRC(A2,A3,A4,A5,A6,A7,A8) on Google Sheets returned #NAME?, but the documented/expected result is 776.
Provenance
Microsoft's page publishes this example's result as 776. Independently derived from the documented depreciation-coefficient rule: life = 1/rate = 6.667 years, which is "More than 6 years", so the documented coefficient is 2.5 and the effective rate is 0.15*2.5 = 0.375. Serial 39679 = 2008-08-19 and 39813 = 2008-12-31, so on basis 1 (actual) the prorated first period is 134/366 of a year (2008 is a leap year) and period 0 depreciates ROUND(2400*0.375*134/366) = ROUND(329.508) = 330. Period 1 then depreciates ROUND((2400-330)*0.375) = ROUND(776.25) = 776, reproducing the published figure exactly; MISMATCH vs expected: expected 776, got '#NAME?'
=AMORDEGRC(A2,A3,A4,A5,0,A7,A8) on Google Sheets returned #NAME?, but the documented/expected result is 330.
Provenance
Not published directly by Microsoft, but forced by the published period-1 figure: 776 = ROUND((2400 - period0)*0.375) has period0 = 330 as its only integer solution consistent with the documented mid-period proration ROUND(cost * rate * coefficient * days/year) = ROUND(2400*0.375*134/366) = ROUND(329.508) = 330. Verified in Python; MISMATCH vs expected: expected 330, got '#NAME?'
=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8) on Google Sheets returned #NAME?, but the documented/expected result is #NUM!.
Provenance
Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got '#NAME?'
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8) on Google Sheets returned #NAME?, but the documented/expected result is #NUM!.
Provenance
Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8) on LibreOffice Calc returned 696, but the documented/expected result is #NUM!.
Provenance
Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got 696
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8) on LibreOffice Calc returned 820, but the documented/expected result is #NUM!.
Provenance
Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got 820

Executed test cases

Excel for the web (executed 2026-09-01 via OneDrive recalculation)

These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.

Formula	Description	Result	Expected	Verdict
=AMORDEGRC(A2,A3,A4,A5,A6,A7,A8)	Microsoft's documented worked example: 2400 asset bought 2008-08-19, first period ends 2008-12-31, salvage 300, period 1, 15% rate, actual basis	776	776 Provenance Microsoft's page publishes this example's result as 776. Independently derived from the documented depreciation-coefficient rule: life = 1/rate = 6.667 years, which is "More than 6 years", so the documented coefficient is 2.5 and the effective rate is 0.152.5 = 0.375. Serial 39679 = 2008-08-19 and 39813 = 2008-12-31, so on basis 1 (actual) the prorated first period is 134/366 of a year (2008 is a leap year) and period 0 depreciates ROUND(24000.375134/366) = ROUND(329.508) = 330. Period 1 then depreciates ROUND((2400-330)0.375) = ROUND(776.25) = 776, reproducing the published figure exactly	Matched
=AMORDEGRC(A2,A3,A4,A5,0,A7,A8)	The prorated period-0 depreciation implied by the documented example's own arithmetic	330	330 Provenance Not published directly by Microsoft, but forced by the published period-1 figure: 776 = ROUND((2400 - period0)0.375) has period0 = 330 as its only integer solution consistent with the documented mid-period proration ROUND(cost rate * coefficient * days/year) = ROUND(24000.375134/366) = ROUND(329.508) = 330. Verified in Python	Matched
=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)	A 22% rate gives a 4.55-year asset life, which the documentation excludes	886	#NUM! Provenance Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6)	Mismatch
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)	A 40% rate gives a 2.5-year asset life, which the documentation excludes	937	#NUM! Provenance Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years	Mismatch

Google Sheets (executed 2026-08-31 via Drive import)

Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.

Formula	Description	Result	Expected	Verdict
=AMORDEGRC(A2,A3,A4,A5,A6,A7,A8)	Microsoft's documented worked example: 2400 asset bought 2008-08-19, first period ends 2008-12-31, salvage 300, period 1, 15% rate, actual basis	#NAME?	776 Provenance Microsoft's page publishes this example's result as 776. Independently derived from the documented depreciation-coefficient rule: life = 1/rate = 6.667 years, which is "More than 6 years", so the documented coefficient is 2.5 and the effective rate is 0.152.5 = 0.375. Serial 39679 = 2008-08-19 and 39813 = 2008-12-31, so on basis 1 (actual) the prorated first period is 134/366 of a year (2008 is a leap year) and period 0 depreciates ROUND(24000.375134/366) = ROUND(329.508) = 330. Period 1 then depreciates ROUND((2400-330)0.375) = ROUND(776.25) = 776, reproducing the published figure exactly	Mismatch
=AMORDEGRC(A2,A3,A4,A5,0,A7,A8)	The prorated period-0 depreciation implied by the documented example's own arithmetic	#NAME?	330 Provenance Not published directly by Microsoft, but forced by the published period-1 figure: 776 = ROUND((2400 - period0)0.375) has period0 = 330 as its only integer solution consistent with the documented mid-period proration ROUND(cost rate * coefficient * days/year) = ROUND(24000.375134/366) = ROUND(329.508) = 330. Verified in Python	Mismatch
=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)	A 22% rate gives a 4.55-year asset life, which the documentation excludes	#NAME?	#NUM! Provenance Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6)	Mismatch
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)	A 40% rate gives a 2.5-year asset life, which the documentation excludes	#NAME?	#NUM! Provenance Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years	Mismatch

LibreOffice Calc 25.8.7.3 (tested 2026-08-31)

Formula	Description	Result	Expected	Verdict
=AMORDEGRC(A2,A3,A4,A5,A6,A7,A8)	Microsoft's documented worked example: 2400 asset bought 2008-08-19, first period ends 2008-12-31, salvage 300, period 1, 15% rate, actual basis	776	776 Provenance Microsoft's page publishes this example's result as 776. Independently derived from the documented depreciation-coefficient rule: life = 1/rate = 6.667 years, which is "More than 6 years", so the documented coefficient is 2.5 and the effective rate is 0.152.5 = 0.375. Serial 39679 = 2008-08-19 and 39813 = 2008-12-31, so on basis 1 (actual) the prorated first period is 134/366 of a year (2008 is a leap year) and period 0 depreciates ROUND(24000.375134/366) = ROUND(329.508) = 330. Period 1 then depreciates ROUND((2400-330)0.375) = ROUND(776.25) = 776, reproducing the published figure exactly	Matched
=AMORDEGRC(A2,A3,A4,A5,0,A7,A8)	The prorated period-0 depreciation implied by the documented example's own arithmetic	330	330 Provenance Not published directly by Microsoft, but forced by the published period-1 figure: 776 = ROUND((2400 - period0)0.375) has period0 = 330 as its only integer solution consistent with the documented mid-period proration ROUND(cost rate * coefficient * days/year) = ROUND(24000.375134/366) = ROUND(329.508) = 330. Verified in Python	Matched
=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)	A 22% rate gives a 4.55-year asset life, which the documentation excludes	696	#NUM! Provenance Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6)	Mismatch
=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)	A 40% rate gives a 2.5-year asset life, which the documentation excludes	820	#NUM! Provenance Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years	Mismatch

Docs & syntax

Excel (desktop): official documentation
LibreOffice Calc: official documentation

Where AMORDEGRC behaves differently

FVSCHEDULE: LibreOffice drops text in the rate schedule
Microsoft documents any non-numeric value in FVSCHEDULE's schedule as #VALUE!. Executed, LibreOffice 25.8.7.3 returns 1.09 for =FVSCHEDULE(1,A1:A2) with A2 = "x" - a compounding period silently dropped - while Google Sheets returns #VALUE! as documented.