ACCRINTM

What it does

ACCRINTM(issue, settlement, rate, [par], [basis])

ACCRINTM returns the accrued interest on a security that pays all its interest at maturity. There are no coupons in between, so there is no schedule to reconstruct: the whole computation is one interval measured once.

Microsoft's Learn reference states the shape of the equation directly — "A = Number of accrued days counted according to a monthly basis", "D = Annual Year Basis", and "For interest at maturity items, the number of days from the issue date to the maturity date is used". Writing that out:

ACCRINTM = par × rate × (A / D)

So the mathematics is a single product of three numbers, and all of the difficulty is in the year fraction. The basis argument is not a detail on this page; it is the page.

That table is Microsoft's, verbatim from the Learn page. The basis-1 construction — what "actual year" means when the interval spans a year boundary or a leap day — is not specified there, and is the same unsettled question described at length on YEARFRAC. For an at-maturity instrument this matters more than usual, because the interval is typically long: a bill with a two-year term crosses at least one year boundary by construction.

One naming trap

The second argument is called settlement on the worksheet, and Microsoft's own Learn page describes it as "the security's maturity date". For an at-maturity security these are the same date in normal use — the interest stops accruing when the paper matures — but the argument name and the argument description do not agree, and code written against the name alone will pass the wrong date on any early-settlement scenario. The Handbook records the naming discrepancy; it does not resolve which reading Excel implements.

Arguments

ACCRINTM(issue, settlement, rate, [par], [basis])

rate is annual. Unlike ACCRINT there is no frequency to divide it by, so an annual rate goes in unmodified and the year fraction does all the scaling.

par scales the answer linearly, which is why a wrong par produces a plausible-looking wrong number rather than an obviously broken one.

Microsoft documents that "Issue, maturity, and basis are truncated to integers", and carries the standard warning that dates should come from DATE or from other formulas rather than being typed as text. Numeric slots otherwise follow the shared model in Coercion and lifting.

Try it

Quirks

Result and edge cases

Returns a Number: an amount of currency in the units of par.

• Long intervals under basis 1 are where the unspecified actual/actual construction becomes visible; two defensible constructions differ by a fraction of a day per year spanned.
• Fractional date serials contribute no fractional days, per the documented truncation rule.
• Empty, missing and error arguments follow the shared call model; see The value universe.

Errors

Microsoft's Learn page documents four conditions, in these words (it says "will generate an error" without naming a worksheet error value):

How to implement

Numerical notes

1. There is nothing to lose precision in. Three finite numbers are multiplied; the only rounding is in A/D and in the two products. The interesting engineering question is not accuracy but op order: par × rate × (A/D) and par × (rate × A) / D differ in the last bit, and an implementation targeting Excel compatibility must pin which one it forms.
2. D is a small integer in three of five cases, so A/D is a quotient of small integers by 360 or 365 — inexact in binary, and therefore genuinely last-bit-sensitive.
3. Basis 1 needs a written specification before it needs code. Which years contribute, how leap days are counted, and what happens across multi-year intervals are all choices, and the documentation makes none of them.
4. Truncate all three integer-valued arguments first, per the documented rule, before any arithmetic — including basis.

Rust code

9 accrintm_fn "ACCRINTM" (3, 5) [V "issue", V "settlement", V "rate", V "par", V "basis"] |s, a, sv| {
    let (issue, settlement) = (date_1900(s, a, 0, sv)?, date_1900(s, a, 1, sv)?);
    bond_out(s, bond::accrintm_kernel(issue, settlement, num(s, a, 2)?, Some(or(s, a, 3, 1000.0)?), Some(or(s, a, 4, 0.0)?)))
}

fn yf(s: i64, e: i64, b: DayCountBasis) -> Result<f64, BondCoreEvalError> {
    match b {
        DayCountBasis::Us30_360 => Ok(d360us(s, e)? / 360.0),
        // Excel's actual/actual rule, shared with YEARFRAC basis 1 (W111-5 G8-06).
        DayCountBasis::ActualActual => {
            crate::ported::day_count_common::excel_actual_actual_fraction(s, e).map_err(derr)
        }
        DayCountBasis::Actual360 => Ok(act(s, e) / 360.0),
        DayCountBasis::Actual365 => Ok(act(s, e) / 365.0),
        DayCountBasis::European30_360 => Ok(d360eu(s, e)? / 360.0),
    }
}

pub fn accrintm_kernel(
    issue: f64,
    settlement: f64,
    rate_: f64,
    par: Option<f64>,
    basis_: Option<f64>,
) -> Result<f64, BondCoreEvalError> {
    let issue = dser(issue)?;
    let settlement = dser(settlement)?;
    // ACCRINTM needs a strictly positive rate (rate 0 is #NUM!), and equal issue and
    // settlement dates accrue 0 rather than #NUM! (live Excel 20430, W111-5 G8-06).
    let rate_ = pos(rate_)?;
    let par = pos(par.unwrap_or(1000.0))?;
    let basis_ = basis(basis_.unwrap_or(0.0))?;
    if issue > settlement {
        return Err(derr(WorksheetErrorCode::Num));
    }
    Ok(par * rate_ * yf(issue, settlement, basis_)?)
}

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

• ACCRINT — the periodic-coupon counterpart. It needs frequency and calc_method because it must reconstruct a coupon schedule; this function needs neither. The two agree only in the degenerate case where the whole interval is one coupon period.
• YEARFRAC — the day-count engine. ACCRINTM(i, s, r, p, b) should be p × r × YEARFRAC(i, s, b), and testing that identity is the cheapest way to localize a disagreement to one of the two functions.
• INTRATE, RECEIVED, DISC — the discount-instrument family, which measures time the same way but quotes the result as a rate rather than an amount.
• Confused with: ACCRINT (above), and with ISPMT-style simple-interest arithmetic, which uses a period count rather than a day-count basis.

Named variants

No named variants are recorded yet.