AMORDEGRC Function in ONLYOFFICE Spreadsheet Editor

• Introduction: The original introduction release is not established by the sources checked.
• Current documentation: Listed in ONLYOFFICE’s unversioned official function help, checked October 18, 2026.
• Source scope: Inspected in official SDKJS tag v10.0.0.169, commit 3679e0375a758d7dc59d31337a45461be3525ed8. This is source inspection, not proof that every deployed editor contains identical code.
• Retired or deprecated: Neither status is established; the function is documented and implemented in the inspected source.
• Testing: Examples are independently calculated or explicitly source-derived. They have not been tested in the ONLYOFFICE application or calculation engine. No native screenshot or workbook-import compatibility is claimed.

Formulas use commas and English names. If your regional settings use semicolons, replace argument separators outside quoted text. Use DATE to create financial dates rather than ambiguous text dates.

AMORDEGRC calculates an asset’s depreciation for a selected accounting period using a degressive rate adjusted by a life-dependent coefficient. The result is the charge for that one period, not accumulated depreciation or remaining book value.

=AMORDEGRC(cost, date_purchased, first_period, salvage, period, rate, [basis])

The registered interface accepts six or seven arguments. Documentation/source disagreement: current help lists basis 2 (actual/360), but the inspected v10.0.0.169 implementation explicitly rejects it. Use 0, 1, 3 or 4 for the inspected implementation. This is a source-based limitation, not an observed application error. Basis 0 is US/NASD 30/360, 1 actual/actual, 3 actual/365 and 4 European 30/360.

On a fresh sheet enter:

Enter =AMORDEGRC(A2,B2,C2,D2,E2,F2,0) in G2. Under 30/360, the first interval is half a year. The implementation first adjusts the annual rate to 0.4, so the initial charge is 10000 × 0.4 × 0.5 = 2000. Format G2 as a currency amount, not a percentage.

Change E2 to 1 to request the next period. The expected charge is 3200: after the first charge the remaining cost is 8000, multiplied by adjusted rate 0.4. Keep the purchase and first-period dates fixed while changing the period number. Moving the first-period date on each row would define a different initial-period calculation.

The coefficient is selected from ceil(1/rate), not from an assumed life supplied separately:

At rate 0.2, reciprocal life is 5 and the coefficient is 2, so the adjusted rate is 0.4. The first charge is rounded to a whole unit using the implementation’s rounding operation. Later returned charges are also rounded to whole units; the internal recursive balance is not simply a schedule of user-rounded displayed charges.

For the worked example with salvage 0, the independently traced charges for periods 0–5 are 2000, 3200, 1920, 1440, 1440 and 0. This is not a plain “40% of balance forever” sequence. The implementation tracks a remaining-life count; at its special late-life boundary it takes half the remaining cost and sets the subsequent rate to 1. That produces the two final 1440 charges. Their sum with the earlier charges is 10000.

Use this sequence as a reconciliation example, not as a universal convention for depreciation. A different purchase fraction changes the first charge and life counter. Periods greater than the unrounded reciprocal life return zero in an earlier guard; fractional periods are not explicitly truncated, so enter integral periods deliberately.

Now change salvage from 0 to 1000 while keeping the other example inputs. An independent trace of the inspected source still gives 2000, 3200, 1920, 1440, 1440, 0. Before the last nonzero charge the remaining cost is 1440. The body checks whether that cost is already below salvage; because it is not, it takes the full 1440 rather than limiting the charge to 440.

The resulting source-derived schedule would reduce the book value below the intended 1000 salvage. This is an implementation limitation, not a native test result and not a valid assurance that salvage is preserved. Do not rely on a complete schedule for reporting without checking each charge against the allowed remaining depreciable amount. A manually capped schedule is a separate accounting model and should not be described as the raw function output.

The source rejects cost at or below zero; negative salvage or period; salvage above cost; rate at or below zero or at or above 0.5; reversed purchase/first-period dates; negative date serials; and unsupported basis values. These use its numeric-error category, conventionally #NUM!. Cost equal to salvage returns zero after validation.

The first-period helper caps its initial calculated charge to cost minus salvage before rounding. If the calculated first fraction is zero, it substitutes a full adjusted-rate charge instead of necessarily returning zero. Date adjustment and leap-year helper behavior are implementation-specific; no general leap-day equivalence is established here. Use valid DATE inputs and independently reconcile unusual purchase dates.

Very small rates and large period counts can stress the recursive calculation. The examples use modest rates and periods; no extreme-period or nonfinite behavior is claimed. This function’s degressive result should not be substituted for linear depreciation merely because both functions share the same argument order.

The following are expected values, not application observations. Numeric examples use independent arithmetic; implementation-specific outputs and errors are source predictions. Keep enough displayed precision to distinguish rounding from a changed formula.

Use the exact argument order above when moving a workbook between products. Similar function names do not establish identical date calculations, validation, rounding or optional-argument handling. This guide does not certify older ONLYOFFICE releases, mobile editors or file-format round trips. The inspected definition uses the canonical name AMORDEGRC; no alternate user-facing name is established here.

DATE creates the input dates. SLN provides a simpler straight-line calculation, and ROUND makes an explicit reporting-rounding policy visible.

• ONLYOFFICE AMORDEGRC help, current unversioned function reference, checked October 18, 2026.
• Official SDKJS v10.0.0.169 implementation, pinned source for argument defaults, validation and implementation details discussed above.

These formulas calculate supplied assumptions. They do not determine a security’s contractual terms, appropriate investment choice or permitted accounting/tax treatment.