FVSCHEDULE silently drops a text rate in LibreOffice, where Excel documents #VALUE!

FVSCHEDULE compounds a principal through a list of period rates: hand it 1 and the schedule 9%, 11%, 10% and it returns 1.33089, because 1 × 1.09 × 1.11 × 1.10 is 1.33089. It is the function you reach for when the rate changes every period — a floating-rate loan, a stepped-discount schedule, a year-by-year inflation series read out of a column.

Microsoft is unusually explicit about what happens if that column contains something that is not a number. From the FVSCHEDULE page, verbatim: “The values in schedule can be numbers or blank cells; any other value produces the #VALUE! error value for FVSCHEDULE. Blank cells are taken as zeros (no interest).” Two rules in one sentence: a blank is a 0% period, and anything else is a hard error.

LibreOffice implements the first rule and not the second. We executed =FVSCHEDULE(1,A1:A2) with A1 = 0.09 and A2 = "x". Calc 25.8.7.3 returned 1.09. Google Sheets returned #VALUE!, as documented.

Executed: the whole FVSCHEDULE corpus

These are all five FVSCHEDULE cases in our function corpus, run as written. The Excel column is Microsoft’s documented behaviour and is the value both executed engines are measured against — we do not run Excel. The Google Sheets column is executed output from the dated Drive-import run of 2026-08-31. The LibreOffice column is Calc 25.8.7.3, and every row returned the identical value in 24.2.0.3, 24.8.7.2 and 25.2.0.3 as well.

Four rows out of five are perfect agreement, including the two that carry the arithmetic: Microsoft’s own documented example and a negative rate that shrinks the principal. The blank-cell row is worth its own sentence, because it is the rule that does hold everywhere: 1000 × 1.1 × 1.0 × 1.1 = 1210, so the empty cell in the middle of the schedule really is a 0% period in both executed engines, not a skipped one. That is the opposite of how most statistical functions treat a blank, and it is documented.

What 1.09 does and does not tell us

Be precise about what the measurement proves. The executed value is 1.09, from a principal of 1 and a schedule of 0.09 followed by "x". There are two ways to get there:

The text was treated as a blank — that is, a 0% period. 1 × 1.09 × 1.00 = 1.09.

The text was skipped entirely, leaving a one-period schedule. 1 × 1.09 = 1.09.

Our corpus cannot separate those two readings, because on this input they produce the same number, and we are not going to assert one over the other from a single case. What we can say is the part that matters to a migration: the documented error did not occur, and the period contributed no growth. Under either reading the future value comes out as if that period had a rate of zero, so the financial consequence is identical — a compounding period silently dropped out of the calculation.

This is a rare kind of divergence

Most of the ways LibreOffice diverges from Microsoft’s documentation are error-code substitutions: the formula still fails, and only the label on the failure changes. We have executed 41 such cases; they are collected in every error code LibreOffice reports as #VALUE!. Those are a real migration problem, but they are a visible one.

Cases where LibreOffice returns an ordinary value where Microsoft documents an error are much rarer. Across our whole corpus — 954 executed cases over 299 functions — 108 cases have a documented result that is an error, and in LibreOffice Calc 25.8.7.3 exactly five of them come back as a value instead of any error at all:

FVSCHEDULE is the only finance function in that list, and it is the only one of the five whose silent result is a plain, believable amount of money. MROUND(5,-2) = 6 and POWER(-8,1/3) = -2 are at least arguable answers to a question the documentation calls invalid; _x0000_ is visibly wrong the moment you look at the cell. A future value that is 9% too low after one dropped period is none of those things.

A migration checklist for rate schedules

1. Find every FVSCHEDULE and look at the range, not the formula. The formula is fine. The hazard is entirely in what the schedule range contains on the day it runs. Search the workbook for FVSCHEDULE( and note the second argument of each hit.

2. Assume the schedule column has text in it until you have checked. The usual sources, in rough order of how often they turn up: a placeholder like n/a, TBD, — or ? left in a future period; a header row or label caught inside the range when someone extended it; a rate pasted from a PDF or a web page and stored as text; an apostrophe-prefixed cell. Any of these produces #VALUE! in Excel and Google Sheets, and a quiet under-compounding in LibreOffice.

3. Count the periods that actually compounded. The cheapest independent check is a second cell that does not use FVSCHEDULE at all: =SUMPRODUCT(--ISNUMBER(schedule)) against =ROWS(schedule). If those two disagree, some period in your schedule is contributing nothing, whatever the future-value cell says. This is arithmetic we are describing rather than a case we executed — treat it as a suggested guard, not as a measured result.

4. Guard the input rather than the output. Wrapping the call in IFERROR is exactly the wrong move here: in Excel and Sheets it swallows the #VALUE! that was warning you, and in LibreOffice there is no error to catch in the first place, so it changes nothing. If you want the workbook to behave the same in all three, test the schedule explicitly — something in the shape of =IF(SUMPRODUCT(--ISNUMBER(schedule))<>ROWS(schedule),NA(),FVSCHEDULE(p,schedule)) — so the failure is yours and not the engine’s. Again: a suggestion derived from the documented and executed behaviour above, not a formula we ran.

5. Watch the direction of travel. A workbook authored and sanity-checked in LibreOffice can carry a text cell in a schedule for years without anyone noticing, because it never complains. Open that same file in Excel or Google Sheets and the cell turns into #VALUE!, which then propagates into every total that touches it. The migration does not create the bug; it reveals one that was already producing wrong numbers.

Honest limits

The Excel column is Microsoft’s documented behaviour as recorded in our test corpus, quoted from the FVSCHEDULE page. We do not run Excel, and no value in that column is a measurement.

The Google Sheets column is executed output from a dated run, because Sheets has no version number to pin. A formula-only .xlsx carrying no cached results goes to Google Drive, is recalculated by Google’s engine, and comes back as .xlsx for readback, with a deterministic =1111+2222 canary in every sheet proving the recalculation happened. These five cases ran on 2026-08-31.

The LibreOffice column is executed output from Calc 25.8.7.3; the same five cases returned the same five values in 24.2.0.3, 24.8.7.2 and 25.2.0.3. Those four builds are the only ones we tested.

Scope. Our text probe is the literal string "x" in a two-cell schedule. We have no corpus case for a numeric string such as a rate stored as text, for an error value inside a schedule, for a logical value inside a schedule, or for a schedule passed as an array constant rather than a range — so we make no claim about any of those, and a workbook whose real-world hazard is “numbers stored as text” should be checked directly rather than assumed to match the "x" result. See our methodology for how recalculation is proven rather than assumed, and the FVSCHEDULE function page for the per-engine support matrix.

Check before you migrate