DAYS360 in SoftMaker PlanMaker: 30/360 Accounting Date Calculations

Use DAYS360 for financial schedules whose terms explicitly require a 360-day year containing twelve assumed 30-day months. That convention is common in some interest calculations, but not universal. DAYS360 is a contractual day-count convention, not a measure of elapsed days. For actual calendar days, use DAYS; for workdays, use NETWORKDAYS.

Example: January 1 to April 1, 2024 represents 91 actual Gregorian days (2024 has February 29) but 90 30/360 days under the European method. If a lender’s agreement specifies Actual/365, Actual/Actual or some other basis, DAYS360 is the wrong tool. Choosing the correct method is a finance/business-policy decision, not a formula default.

=DAYS360(StartDate, EndDate [, Method])

This is not the same argument order as DAYS. DAYS360 uses start first; DAYS uses end first. The Method argument is a logical boolean according to the official English reference. No additional optional arguments are documented. Use unambiguous numeric DATE(Year,Month,Day) values in the worksheets below. Formulas show the comma separator used in the English examples; on installations requiring semicolons, use the correct locale-specific function separator. SoftMaker 2026 reference.

How the 30/360 convention works

The European method (TRUE) adjusts day 31 to day 30 in either endpoint; for otherwise ordinary dates, the 30/360 difference can be independently verified using:

360 × (end year − start year)
+ 30 × (end month − start month)
+ (adjusted end day − adjusted start day)

This explanatory arithmetic is not a replacement for PlanMaker’s formula and is not a native implementation test. For example, January 31 → March 31 has both endpoints adjusted to day 30, producing 60 30/360 days. The U.S. NASD method has different month-end handling; see the important compatibility warning below.

Enter the following data:

In C2 type:

=DAYS360(A2,B2,TRUE)

Expected C2: 90 under the European 30/360 convention. In D2 type:

=DAYS(B2,A2)

Expected D2: 91 actual calendar days, because February 2024 has 29 days. Both expected values were independently calculated; neither formula was executed in PlanMaker. This is the most useful sanity check: the two functions answer different questions.

PlanMaker’s reference specifies two choices:

• TRUE (European): convert day 31 in either endpoint to 30.
• FALSE or omitted (U.S. NASD): SoftMaker describes day-31 adjustments, including an end-of-month rule and a special case when both dates fall on the 31st. The exact U.S. rule is not reproduced here as an independent tested implementation because its prose differs from Microsoft’s rules.

These examples deliberately use the European method, which is explicit and checkable:

The official SoftMaker reference independently documents DAYS360("01/01/2018","02/01/2018",TRUE) as 30, DAYS360("02/01/2018","03/01/2018",TRUE) as 30 and DAYS360("01/01/2012","01/01/2013",TRUE) as 360. Those three are vendor-documented results, not observed application runs. SoftMaker source.

Assume an agreement explicitly requires the European 30/360 basis, principal of 10,000 and annual simple interest of 6%. For January 1 through April 1, 2024, use:

=10000*0.06*DAYS360(DATE(2024,1,1),DATE(2024,4,1),TRUE)/360

Expected numerical value: 150, independently checked as 10,000 × 0.06 × 90 ÷ 360. This is an illustration of arithmetic only, not financial, lending or contractual advice. Before using actual transaction data, verify the required convention, start/end inclusivity, handling of holidays and any contract-specific rounding.

Microsoft Excel also has DAYS360(start_date,end_date,[method]), with omitted/FALSE denoting U.S. NASD and TRUE denoting European. But Microsoft’s published NASD description specifically addresses the last day of a month and uses a condition on whether the starting day is before day 30. SoftMaker’s PlanMaker 2026 reference instead describes a rule concerning dates that fall on the 31st and an exception when both dates are 31st. These prose descriptions do not establish identical behaviour for February-end or all 30th/31st cases.

Untested U.S.-method edge-case outcomes should not be treated as verified PlanMaker behavior. For a workbook exchanged with Excel, native-test start/end dates that include February 28/29, the 30th and the 31st before relying on accounting accruals. See SoftMaker DAYS360 and Microsoft DAYS360. The ordinary European cases above are independently reasoned, not an exhaustive cross-application parity test.

Error and troubleshooting checklist

• Wrong result by one or more days: confirm whether the contract uses actual elapsed days or 30/360 days; these are fundamentally different quantities.
• U.S. versus European result differs: check the third argument. TRUE is European. Omitting it selects U.S. NASD.
• Unexpected change around February or a month end: month-end conventions differ, and official descriptions of U.S. NASD are not word-for-word identical across vendors. Native-test your exact boundary dates.
• Result appears as a date: the result is a count of assumed days; format the output cell as General/Number, not a date display.
• Text-based dates interpreted incorrectly: use actual date-valued cells or DATE, not ambiguous strings such as 03/04/2024; regional settings determine interpretation.
• Comma separator rejected: use the argument separator expected by your installed locale (possibly a semicolon).
• Invalid date or nonlogical Method: exact PlanMaker error codes and coercion/defaults beyond the documented boolean/omission rule have not been verified; do not copy Excel errors as if they were tested in PlanMaker.

The PlanMaker 2021, 2024 and 2026 English documentation documents the same argument order and optional logical method (called Mode in the 2021 reference), with the U.S. method as default and the European method selected by TRUE. This confirms the documented surface, not every edition’s runtime, mobile availability or error/round-trip compatibility. Excel has a matching named function and argument structure, but U.S.-method end-of-month parity has not been established here. PlanMaker 2021 · PlanMaker 2024 · PlanMaker 2026.

For further context, see the official vendor documentation on DAYS, DATEDIF and NETWORKDAYS.

• SoftMaker PlanMaker 2026 — DAYS360, accessed 2026-10-12: syntax, method default, documented month-end description and 2018–2013 examples.
• SoftMaker PlanMaker 2024 — DAYS360, accessed 2026-10-12: earlier documented syntax and method behaviour.
• SoftMaker PlanMaker 2021 — DAYS360, accessed 2026-10-12: earlier documented syntax and method behaviour.
• Microsoft Excel — DAYS360, accessed 2026-10-12: independently checked Excel documentation, not a PlanMaker runtime observation.

Verification status: Official documentation checked; 30/360 European arithmetic independently calculated. Not executed in PlanMaker or Excel. No genuine application screenshot. U.S./NASD month-end parity, native errors, and edition-specific execution remain unverified.