=DAYS360(start_date; end_date; [method])

The official Zoho reference explicitly describes method = 0 as the U.S. NASD convention and other values as the European method. Its own examples include a method of 2, so a nonzero numeric value is a documented way to select the European method. For clarity, these examples use 0 and 1, with native validation still pending. Do not silently assume every spreadsheet application’s logical TRUE/FALSE or arbitrary negative method input has identical coercion rules.

For European counting, a 31st becomes the 30th. Microsoft’s U.S. NASD explanation includes a different adjustment: when the end date is the last day of a month and the adjusted start date is before day 30, the end can be treated as the first of the next month. Zoho’s short reference names the conventions but does not enumerate every end-of-February and 31st-day operation; the finer points require tests in Zoho Sheet.

Create a DatePeriods worksheet. Enter these sample data in A1:E9. Keep B:C as genuine date-valued cells; the companion CSV contains ISO-formatted strings for practice but has not been imported into Zoho.

Column D is for another tutorial and does not affect DAYS360. To enter a date without relying on locale interpretation, use a date-building formula such as =DATE(2024;1;1) in the appropriate cell.

1. Enter US 30/360 in F1, European 30/360 in G1, and Actual days in H1.
2. In F2, enter =DAYS360(B2;C2;0) or =DAYS360(B2;C2) for the documented default.
3. In G2, enter =DAYS360(B2;C2;1), selecting Zoho’s documented European-style option.
4. In H2, enter =DAYS(C2;B2)—the separate DAYS function takes end before start; this last column is an alternative for actual calendar days.
5. Fill all three formulas down to row 9, then format the results as integer numbers.

Expected independent model results, not Zoho execution results:

Why the 2026-01-15 to 2026-01-31 result can differ

The U.S. NASD adjustment described by Microsoft treats an ending 31st as the first of the next month when the starting day is earlier than the 30th. On the January 15–31 interval, that means 16 synthetic days in our implementation. The European method instead turns January 31 into January 30, giving 15 synthetic days. This is the kind of choice that matters when reconciling a lender’s or investor’s interest statement. It is inappropriate to claim identical February-end logic across all products without native tests.

Explain the mathematics on an ordinary date range

For January 1 through July 1, 2024, no edge-day adjustment is needed: six complete notional months × 30 days = 180 days. However, the true calendar interval contains 182 days in leap-year 2024. This difference is the point of DAYS360 rather than a rounding error.

Suppose J2 contains an annual amount of 12000 in your reporting currency. To compute a 30/360 prorated amount for P101:

=ROUND(J2*DAYS360(B2;C2;0)/360;2)

The independent expectation is 6000.00 because 180 ÷ 360 × 12000 = 6000. For the same period on an actual/365 convention, =ROUND(J2*DAYS(C2;B2)/365;2) would instead model 5983.56 (182 ÷ 365 × 12000), but whether a contract requires that alternative is a legal/accounting question. Do not infer that one convention is universally correct for accrued interest.

For a ledger that can select a convention per row, put the method code in K2 and use =DAYS360(B2;C2;K2); for example, 0 selects the documented U.S. mode and 1 selects a documented nonzero European mode. Explicitly label the convention in the ledger and keep a copy of the source contractual terms.

• Day count is not true day subtraction. When two dates span February, leap years or month-end, DAYS360 and DAYS can differ dramatically. First decide which one is appropriate.
• Month-end adjustments matter. January 31 and the final day of February require special scrutiny. The vendor reference does not fully specify how each edge case is implemented; maintain a native test matrix before treating any high-stakes projection as validated.
• Unrecognized text dates: Zoho’s generic errors include #VALUE! for invalid argument types. Ensure cells are dates, not text that merely looks like dates. Formatting a text string as a date does not always convert the stored value.
• Bad function names or quotes: Zoho describes #NAME! as commonly caused by incorrect function names or malformed text references. Confirm the spelling DAYS360 and correct separator for your environment.
• Reversed dates: The linked Zoho page does not directly specify the sign or error convention for end earlier than start. The independent model can produce negative synthetic days, but this is not a measured Zoho result. Check before using reversed intervals.
• method data type: Zoho explicitly says 0 or other values, whereas Microsoft Excel describes a FALSE/TRUE logical argument. Do not silently assume Zoho treats empty text, error cells, or arbitrary nonnumeric text like Excel.
• Date display: A result formatted as Date can look like an unrelated old date because the numeric day count is being rendered with a date format. Change the result column to Number.
• Different fixed-income 30/360 conventions: Terms such as 30E/360 ISDA and 30/360 PSA describe specialized variants not established by Zoho’s simple two-method reference. Do not assert DAYS360 reproduces them.

Microsoft Excel uses DAYS360(start_date,end_date,[method]) with comma-separated examples in English, and defines the method argument as a Boolean for U.S. or European calculations. Zoho’s web-help syntax uses semicolons and explicitly documents numeric 0 versus other values. Even if sample values agree, data conversion and end-of-February edge behavior must be checked before treating an imported workbook as equivalent. No Google Sheets native run or compatibility claim is made here.

Use YEARFRAC when you need a fraction of a year; its basis 0 / 4 are conceptually connected to 30/360. Use DAYS for elapsed calendar days, NETWORKDAYS for business days, or EOMONTH for finding the last date of a month. Zoho’s desktop beta announcement confirms a partially overlapping set of web features, but it does not document an exact first-support version or per-account/mode parity for DAYS360.

• YEARFRAC — review proposal in this batch, not a confirmed live page.
• DAYS — prior review proposal; note that its argument order differs from DAYS360.
• EOMONTH — prior review proposal for month-end dates.
• NETWORKDAYS — prior review proposal for weekday-only counts.

These are editorial references, not hyperlinks to verified published internal pages. Connect real URLs only after the owner approves the destinations.

• Zoho Sheet — function documentation
• Zoho Sheet Windows/macOS desktop beta announcement

Verification status: Official documentation checked; example outcomes were independently reasoned or arithmetically checked where applicable. Not executed in Zoho Sheet.

• No genuine Zoho Sheet screenshots are included; this guide does not use mock application images.