DDB

What it does

DDB(cost, salvage, life, period, [factor])

DDB(cost, salvage, life, period, [factor]) returns the depreciation charge for one period under the double-declining-balance method, or any other declining rate you name.

Microsoft's Learn page gives the rule in one line:

Min( (cost − total depreciation from prior periods) × (factor / life),
     (cost − salvage − total depreciation from prior periods) )

Writing book for cost minus the depreciation already taken, that is:

charge = min( book × factor / life,  book − salvage )

The first term is the declining-balance charge: a constant fraction factor/life of the remaining book value. With the default factor = 2 that fraction is twice the straight-line rate, which is where "double declining" comes from — the method writes off twice as fast at the start and tapers.

The second term is a clamp: the charge may never take the book value below salvage.

Two properties define the method, and both matter:

1. The rate is given, not derived. Unlike DB, which solves for the rate that lands exactly on salvage, DDB applies whatever factor/life you specify and lets the clamp deal with the consequences.
2. salvage enters only through the clamp. It does not affect the declining-balance term at all, so for early periods DDB returns the same number whatever salvage is.

Arguments

DDB(cost, salvage, life, period, [factor])

period is 1-based, like DB and unlike the French pair AMORLINC / AMORDEGRC.

period and life must be in the same units. Monthly depreciation of a five-year asset means life = 60 and period in months — and factor/life shrinks accordingly, which is the point.

Numeric slots follow the shared model; see Coercion and lifting.

Try it

Quirks

The clamp, and why DDB never switches

Declining balance has a well-known defect: book × factor/life shrinks geometrically and never reaches zero, so the asset is never fully written off within its life. Standard accounting practice is to switch to straight line for the remaining periods once straight line would give the larger charge.

DDB does not do that. Microsoft is explicit: "Use the VDB function if you want to switch to the straight-line depreciation method when depreciation is greater than the declining balance calculation." DDB runs pure declining balance, clamped at salvage, for the whole life.

So a DDB schedule summed over 1 … life does not generally reach cost − salvage. It approaches it geometrically and stops short — unless the clamp cuts in near the end, which happens only when salvage is large enough for the geometric tail to reach it. This is the single most common surprise in the depreciation category, and it is documented behaviour, not a defect.

The comparison that makes the family legible:

Result and edge cases

Returns a Number: the charge for the requested period, in the units of cost.

• salvage is invisible early. For any period where book × factor/life is below book − salvage, the answer does not depend on salvage at all. A spreadsheet in which changing salvage changes nothing is behaving correctly.
• The clamp can zero the charge. Once the book value has fallen to salvage, every later period returns 0 rather than an error.
• factor > life makes factor/life exceed 1, so the first period would write off more than the whole asset; the clamp reduces it to cost − salvage. Nothing in the documentation forbids it.
• Fractional life is accepted; the final partial period is shorter than 1 and its charge is prorated accordingly.
• The schedule does not exhaust cost − salvage, per the section above. This is not an edge case; it is the normal outcome.
• Empty, missing and error arguments follow the shared call model; see The value universe.

Errors

Microsoft's Learn page documents no error values and no error conditions — only the "all five arguments must be positive numbers" remark, which is contradicted on the same page.

How to implement

Numerical notes

2. The clamp is a min and therefore a branch. Near the crossover the two terms are close, and which one wins is decided by a floating-point comparison. Two implementations that agree on both terms to the last bit can still disagree on the answer at exactly one period.
3. factor / life is one division, not a per-period recomputation. Forming it once and multiplying is not the same as multiplying by factor and dividing by life each period; pin the choice.
4. No transcendentals. Unlike DB, which needs a general power, DDB is multiplication, subtraction and comparison throughout. It is the most numerically straightforward member of the family — which makes it a good calibration surface for a future vector suite, since any disagreement is semantic rather than about a library pow.
5. The fractional-period proration is an extension, not a documented behaviour. It reuses the VDB interval logic on a unit interval, which is a defensible reading and is not the only one.

Rust code

24 ddb_fn "DDB" (4, 5) [V "cost", V "salvage", V "life", V "period", V "factor"] |s, a, sv| {
    let (cost, salvage, life, period) = (num(s, a, 0)?, num(s, a, 1)?, num(s, a, 2)?, num(s, a, 3)?);
    let factor = if a.len() > 4 { num(s, a, 4)? } else { 2.0 };
    out(s, dep::ddb_kernel(cost, salvage, life, period, factor))
}

pub fn ddb_kernel(
    cost: f64,
    salvage: f64,
    life: f64,
    period: f64,
    factor: f64,
) -> Result<f64, WorksheetErrorCode> {
    validate_finite(&[cost, salvage, life, period, factor])?;
    if cost < 0.0 || salvage < 0.0 || life <= 0.0 || period <= 0.0 || period > life || factor <= 0.0
    {
        return Err(WorksheetErrorCode::Num);
    }
    ddb_period_depreciation(cost, salvage, life, period, factor)
}

No implementation has been published with a Handbook test suite for this function.

Version differences

The recorded environments below distinguish a reading from a same-input comparison. Counts describe captured inputs in each environment; overlapping captures and comparisons are not totals of unique worksheet calls.

The record contains no same-input comparison between these environments. Reading different inputs on different builds does not establish either a version change or cross-build agreement.

Recorded environments and comparison details.

Alternatives

Relationships

• DB — the other declining-balance function, which derives and rounds its rate and prorates the first year by a month count. See the comparison table above.
• SLN — the straight-line charge (cost − salvage)/life. Comparing DDB against SLN period by period is how you find where a switching method would switch, and therefore where DDB starts under-charging relative to accounting practice.
• SYD — sum-of-years-digits: also accelerated, but it does exhaust cost − salvage exactly.
• AMORDEGRC — the French accelerated method. Its acceleration coefficient looks like factor but is derived from rate and cannot be supplied, and its last two periods are forced to 50 and 100 per cent. Not a substitute.
• Confused with: VDB (above), and with the assumption that a DDB column sums to cost − salvage.

Named variants

No named variants are recorded yet.