How Day-Count-Fraction Algorithms Turn Calendar Days into Interest: ACT/360, ACT/365, 30/360, Actual/Actual and Leap-Year Edge Cases

Reader question: Two contracts can both say “5% interest” and cover the same calendar dates. Why can they produce different cash interest?

Because the percentage rate is only one input. Financial contracts also specify a day-count convention: an algorithm that converts dates into a fraction of a notional year.

The basic interest formula is often:

Interest = Principal × Rate × DayCountFraction.

If one contract uses ACT/360 and another uses ACT/365, the numerator may count the same actual days while the denominator differs. Other conventions such as 30/360 alter the day-count numerator itself. Actual/Actual conventions can depend on leap years or the contractual coupon schedule.

What this page owns — and what it does not

This page owns the algorithm:

(start date, end date, convention, schedule context) → year fraction.

It does not replace the financial date engine, which creates and adjusts schedule dates; the floating-rate loan algorithm; bond accrued interest; or swap valuation.

Those owners consume a year fraction. This page explains how that fraction is calculated and falsified.

The simplest family: actual days divided by a fixed denominator

Under Actual/360:

DCF = actual calendar days in the period / 360.

Under Actual/365 Fixed:

DCF = actual calendar days in the period / 365.

ISDA’s published definitions describe Actual/360 in exactly this structural way: the actual number of days in the calculation period divided by 360.

The Bank of England’s UK Money Markets Code illustrates how market convention differs by currency: it lists USD and EUR money-market business commonly on ACT/360, while GBP and SGD are among currencies commonly using ACT/365, with an explicit warning that conventions should be agreed rather than assumed.

A 90-day example

Take principal 1,000,000, annual rate 5% and an accrual period containing exactly 90 calendar days.

Under ACT/360:

Interest = 1,000,000 × 0.05 × 90/360 = 12,500.

Under ACT/365 Fixed:

Interest ≈ 1,000,000 × 0.05 × 90/365 = 12,328.77.

Nothing changed about principal, nominal rate or elapsed calendar days. The contractual basis alone changed the cash amount.

This is why a rate without a day-count basis is incomplete financial data.

Which endpoint days are counted?

“Actual number of days” still needs an interval convention. Financial date arithmetic commonly treats an accrual interval as including one boundary and excluding the other so adjacent periods do not double-count the shared date.

A robust implementation should not rely on vague language such as “between these dates.” It should define the exact library operation and validate it against market-standard examples.

Off-by-one errors are especially dangerous in daily accrual engines because they can persist across millions of positions while remaining individually small.

30/360 changes the calendar before dividing

The 30/360 family imagines a standardized year of twelve 30-day months. A simplified form resembles:

DCF = [360(Y₂−Y₁) + 30(M₂−M₁) + (D₂′−D₁′)] / 360.

The primes matter. Different 30/360 variants transform month-end day numbers differently.

That is why “30/360” is not one universal formula. Market documentation distinguishes variants such as 30/360 Bond Basis, 30E/360 and 30E/360 ISDA.

Why month-end rules create disagreements

Consider a period involving 28 February, 29 February, 30th or 31st of a month.

One convention may replace a 31st with day 30. Another may have special treatment for the last day of February. A European 30E/360 variant can normalize endpoints differently from U.S.-style 30/360.

For ordinary mid-month dates, multiple variants can return the same result. At boundaries, they diverge. A test suite that contains only 15 January to 15 July can therefore give false confidence.

ISDA publishes worked 30/360 and 30E/360 examples precisely because names alone are not enough to implement the formulas safely.

Actual/Actual is a family too

It is tempting to read “Actual/Actual” as simply:

actual days / actual days in year.

But there are multiple Actual/Actual conventions with different logic.

Actual/Actual (ISDA) effectively accounts for the portions of a period falling in leap and non-leap calendar years using their respective year lengths.

Actual/Actual (ICMA) is tied to coupon periods and reference periods. It can require schedule context such as coupon frequency and regular reference dates, especially for irregular first or last coupons.

This creates an important software boundary: some day counts can be computed from two dates alone; others need the contractual schedule.

Actual/Actual (ISDA): split across years

Suppose an accrual crosses 31 December. Under an ISDA-style Actual/Actual approach, the part in a non-leap year can be divided by 365 and the part in a leap year by 366, then the fractions are added.

Schematically:

DCF = days in non-leap-year segment / 365 + days in leap-year segment / 366.

The exact interval boundaries must still follow the governing definition.

The algorithm is therefore piecewise rather than using one denominator selected from the start date or end date.

Actual/Actual (ICMA): the schedule is part of the input

For regular coupon periods, Actual/Actual (ICMA) relates elapsed days to the coupon period and coupon frequency. For irregular stubs, the calculation can require hypothetical regular reference periods.

This means a function signature such as:

yearFraction(start, end)

is insufficient for every convention.

A safer abstraction is:

yearFraction(start, end, convention, schedule/referencePeriods).

This directly connects to the date-engine article: a malformed coupon schedule can make an Actual/Actual ICMA calculation wrong even if the day-count code itself is bug-free.

Leap years: 29 February is not an exotic edge case

Leap years affect:

• Actual/Actual denominators;
• the number of actual calendar days in periods;
• February month-end logic in 30/360 variants;
• annual schedule generation;
• overnight benchmark compounding spans.

A period from late February to early March can therefore be a high-information regression test.

Systems should test both leap and non-leap years and distinguish “contains February 29” from “occurs in a leap year” where the governing convention requires that distinction.

Market conventions attach to products, not mathematics textbooks

The Bank of England’s Money Markets Code publishes usual day-count conventions by currency, but it also warns participants to agree the basis where domestic and non-domestic practices differ.

Securities can specify their basis in the prospectus. Derivatives use governing definitions and confirmations. Loans can specify a contractual basis. Benchmarks can publish their own compounding methodology.

Therefore the algorithm should not infer day count from “USD” or “bond” if the actual instrument terms supply a different rule.

SOFR makes ACT/360 visible in a live benchmark calculation

The New York Fed states that the SOFR Averages and Index calculate interest using the actual number of calendar days while assuming a 360-day year, consistent with broader U.S. dollar money-market convention.

Weekends and holidays matter because one business-day SOFR observation can apply across multiple calendar days. In the New York Fed’s notation, n_i is the number of calendar days for which a given SOFR value applies.

This creates a clean connection between day count and benchmark construction: the benchmark value and the year-fraction denominator are separate inputs to the interest factor.

SONIA illustrates a different currency convention

Sterling money markets commonly use an ACT/365 convention. The Bank of England publishes the SONIA Compounded Index and provides formulas for deriving compounded rates over custom reference periods.

This is why simply transplanting a U.S.-dollar ACT/360 compounding engine into sterling products can be wrong even when the benchmark observations themselves are correct.

Business-day adjustment and day count must stay separate

Suppose a contractual period end falls on Saturday and payment moves to Monday under a business-day convention.

The question “which date is the payment made?” belongs to the date-adjustment layer.

The question “which dates define the accrual fraction?” belongs to the contract’s day-count and period rules.

Some instruments accrue to the unadjusted period end but pay on an adjusted date. Others use adjusted dates in specified ways. If software blindly feeds the payment date into the day-count function, a two-day weekend shift can accidentally create extra interest.

Inputs and outputs

A day-count engine can require:

• accrual start date;
• accrual end date;
• day-count convention identifier;
• coupon frequency where relevant;
• reference-period dates for Actual/Actual ICMA;
• maturity flag or termination context for variants with special maturity treatment;
• calendar/schedule convention version;
• inclusive/exclusive boundary definition.

Outputs should include the exact or high-precision year fraction, convention used, intermediate day counts or segments where diagnostic traceability matters, and any missing-context error rather than a guessed fraction.

Evidence polarity: what supports confidence?

Evidence for confidence includes agreement with ISDA or market-standard worked examples, correct leap-year segmentation, correct 31st/February handling, stable results under independent libraries, matching contractual coupon schedules, and cash-interest round trips that reproduce published examples.

Evidence against confidence includes one formula being used for every “30/360” name, Actual/Actual calculated without schedule context when ICMA requires it, off-by-one day differences, leap-year discrepancies, payment-date adjustments leaking into accrual boundaries, or a library silently substituting a default convention.

Counterexample: ACT/360 and ACT/365 do not merely differ in naming

For positive rates and the same actual-day numerator, ACT/360 produces a larger year fraction than ACT/365. Therefore it produces more interest for the same quoted nominal annual rate and principal.

Changing the basis while keeping “5%” unchanged is an economic change, not a formatting change.

Counterexample: 30/360 can say two different calendar intervals are equally long

Because 30/360 normalizes months, a 31-day calendar interval and a 30-day calendar interval can map to the same standardized day count under some endpoint patterns.

That is intentional. The convention is not trying to measure astronomical elapsed time perfectly; it is defining a contractual accrual basis.

Counterexample: an Actual/Actual result can be wrong even when actual-day counting is right

If software counts every real day correctly but applies 365 as the denominator across a leap-year segment where the convention requires 366 treatment, the numerator is perfect and the year fraction is still wrong.

Similarly, Actual/Actual ICMA can be wrong if the reference coupon period is wrong.

Counterexample: a default day count can hide missing legal data

Suppose a trade record arrives with no day-count field. The system silently assumes ACT/360 because the currency is USD.

The calculation runs, the cash amount looks plausible, and no exception is raised. Yet the contract may specify 30/360.

A strong engine treats a missing required convention as a data-quality failure, not an invitation to guess.

Weak links in implementation

String aliases. “ACT/365”, “ACT/365F”, “Actual/365 Fixed” and other labels can be mapped incorrectly if aliases are not normalized to a controlled enumeration.

Variant collapse. All 30/360 families or all Actual/Actual families are treated as one.

Schedule loss. The day-count function receives dates but not the coupon reference period.

Leap-year bug. Gregorian leap-year rules are implemented as “divisible by 4” without century exceptions.

Endpoint bug. Start/end inclusion differs between implementations.

Adjusted-date contamination. Payment-date movement changes accrual days unintentionally.

premature rounding. Year fractions are rounded before multiplying principal and rate.

silent default. Unknown convention falls back to a common basis instead of failing.

Diagnostics: how to test the engine

• same-period basis test: compare ACT/360 and ACT/365 on identical dates.
• 31st test: include start/end dates on the 31st for 30/360 variants.
• February test: include last day of February in leap and non-leap years.
• year-crossing test: cross 31 December under Actual/Actual ISDA.
• stub test: calculate irregular first and final coupon periods under Actual/Actual ICMA.
• one-day test: verify a one-day interval and adjacent periods do not double-count the shared boundary.
• reverse-order test: reject or explicitly handle end dates before start dates.
• independent-library test: compare a trusted second implementation using the same convention definition.
• cash round-trip: multiply the returned fraction by principal and rate and compare with an authoritative worked example.
• missing-context test: remove schedule context from an ICMA calculation and require an explicit error.

What would falsify confidence?

Confidence should be withdrawn if the engine disagrees with authoritative worked examples; if aliases route to different formulas unexpectedly; if leap-year and February boundary tests fail; if Actual/Actual ICMA can run without necessary schedule data; if payment-date adjustment changes the accrual period without a contract rule; or if repeated calculations with the same inputs and convention version are not deterministic.

Alternatives and limits

A spreadsheet can calculate simple day counts, but generic functions may implement specific variants whose details need to match the contract. Library names are not substitutes for definition verification. A fully general financial convention engine should keep day-count definitions versioned and test them against the governing documentation.

No mathematical formula can decide which basis a contract intended when the documentation is missing or ambiguous. That is a data/legal interpretation issue, not a numerical one.

How this connects to the surrounding knowledge estate

The date engine decides the relevant schedule dates. The day-count engine converts those dates into year fractions. Floating-rate loan algorithms combine those fractions with benchmark observations. Bond accrued-interest algorithms use them to convert coupon entitlement into dirty price. Swap valuation uses them in fixed and floating cash flows. A small date-basis error can therefore propagate into valuation, accounting and settlement.

Verification and update triggers

Preserve the convention identifier, exact formula version, schedule inputs, boundary rules, rounding policy and source documentation. Revalidate after ISDA/market-definition upgrades, financial-library migrations, benchmark-convention changes, new product support, date-engine changes or any unexplained interest discrepancy between independent systems.

Primary and high-quality references

• ISDA, Actual/Actual Day Count Fraction.
• ISDA, Market Practice Statements and Issues, including worked 30/360 and 30E/360 calculation examples and Actual/Actual convention material.
• Bank of England, UK Money Markets Code, including usual currency day-count conventions and the warning to agree the applicable basis.
• Federal Reserve Bank of New York, Additional Information about Reference Rates, documenting actual-calendar-day/360 treatment in SOFR Averages and Index calculations.
• ICMA, International Capital Market Association, for bond-market conventions including Actual/Actual ICMA.

Educational boundary: This article explains interest-accrual mathematics. It does not determine the terms of any reader’s loan, bond or derivative and does not provide personalized financial advice.