Excel's LAMBDA helpers return errors when opened in LibreOffice
Modern Excel workbooks lean on LAMBDA and its array helpers (MAP, BYROW, BYCOL, SCAN,
REDUCE, MAKEARRAY, ARRAYTOTEXT). Open one of those workbooks in LibreOffice Calc and the
formulas do not just return different numbers, they stop computing. An inline call such as
=LAMBDA(x,x*2)(5) returns #VALUE!, and every helper function returns
#NAME? because the name is not recognised at all.
The surprise
LibreOffice parses the word LAMBDA but will not evaluate a lambda you invoke
in place, so =LAMBDA(x,x*2)(5) becomes #VALUE! rather than 10. The
helper functions that consume a lambda (MAP, BYROW, BYCOL, SCAN, REDUCE, MAKEARRAY) are not
implemented, so they resolve to #NAME? — the same error you would get from a
misspelled function.
Executed results
Ranges below use A1:A3 = 1, 2, 3 and A1:B2 = 1, 2, 3, 4.
| Formula | Excel, desktop (documented) | Google Sheets (executed 2026-08-29) | LibreOffice Calc 25.8.7.3 (executed) |
|---|---|---|---|
| =LAMBDA(x,x*2)(5) | 10 | 10 | #VALUE! |
| =LAMBDA(x,y,x+y)(3,4) | 7 | 7 | #VALUE! |
| =MAP(A1:A3,LAMBDA(x,x*2)) | 2, 4, 6 | 2 — read-back 2, 4, 6 | #NAME? |
| =BYROW(A1:B2,LAMBDA(r,SUM(r))) | 3, 7 | 3 — read-back 3, 7 (matches) | #NAME? |
| =BYCOL(A1:B2,LAMBDA(c,SUM(c))) | 4, 6 | 4 — read-back 4, 6 (matches) | #NAME? |
| =SCAN(0,A1:A3,LAMBDA(a,b,a+b)) | 1, 3, 6 | 1 — read-back 1, 3, 6 | #NAME? |
| =REDUCE(0,A1:A3,LAMBDA(a,b,a+b)) | 6 | 6 | #NAME? |
| =MAKEARRAY(2,2,LAMBDA(r,c,r*c)) | 1, 2 / 2, 4 | 1 — read-back 1, 2, 2, 4 (matches) | #NAME? |
| =ARRAYTOTEXT({1,2,3}) | 1, 2, 3 | #NAME? | #NAME? |
The Excel column holds the documented-expected values recorded in our test corpus; we did not
run desktop Excel. The LibreOffice column is what our harness computed by recalculating each workbook in
LibreOffice Calc 25.8.7.3. Google Sheets was executed on 2026-08-29 via Drive import using plain (unprefixed) function names:
LAMBDA, MAP, SCAN, REDUCE, BYROW,
BYCOL and MAKEARRAY all returned Excel’s documented values. The
BYROW/BYCOL/MAKEARRAY figures come from a follow-up run that
resolved an earlier inconclusive result, where the same formulas stored with Excel’s
_xlfn. prefix were not mapped by Google’s importer. ARRAYTOTEXT
returned #NAME?, which is real: Google does not document it.
Consistent across LibreOffice versions
We ran the same cases through four builds — 24.2.0.3, 24.8.7.2, 25.2.0.3 and 25.8.7.3. The
helper functions returned #NAME? in every build; none of these releases implements
MAP, BYROW, BYCOL, SCAN, REDUCE or MAKEARRAY. The inline lambda call returned #VALUE!
in every build too. One small wrinkle: =LET(f,LAMBDA(x,x^2),f(4)) returned
#NAME? in 24.2.0.3 but #VALUE! from 24.8.7.2 onward — still broken, just
a different error label. There is no version in this range where the lambda helpers start working.
Why it happens
Two different failures hide behind two different errors. LAMBDA is a recognised
name in Calc — a formula that supplies the wrong argument count, =LAMBDA(x,y,x+y)(3),
even returns the same #VALUE! Excel documents — but Calc does not evaluate a lambda
that you define and immediately invoke with a trailing (...), so the useful case
collapses to #VALUE!. The helper functions are a harder wall: they simply are not part
of Calc's function set, so the parser treats MAP, SCAN and the rest as
unknown names and returns #NAME?. Google Sheets gives a third answer to that same
wrong-argument-count call: our executed LAMBDA_wrong_arg_count case
(=LAMBDA(x,y,x+y)(3)) returned #N/A in Sheets, not the #VALUE!
Excel documents. Three engines, three different error identities for one malformed formula — a
generic ISERROR guard catches all of them, but a check for one specific error code will
not.
How to migrate safely
The durable fix is to rewrite the array logic as ordinary formulas that every engine evaluates:
=MAP(A1:A3,LAMBDA(x,x*2)) becomes a helper column of =A1*2 filled down.
=BYROW(A1:B2,LAMBDA(r,SUM(r))) becomes =SUM(A1:B1) per row.
=REDUCE(0,A1:A3,LAMBDA(a,b,a+b)) becomes =SUM(A1:A3).
=SCAN(0,A1:A3,LAMBDA(a,b,a+b)) becomes a running total: =A1 in the first
cell, then =B1+A2 filled down.
=ARRAYTOTEXT(A1:A3) becomes =TEXTJOIN(", ",TRUE,A1:A3), which every
engine we execute supports — including Excel for the web, where all four
TEXTJOIN corpus cases returned their documented values on 2026-09-01.
Helper columns recalculate identically in Excel and LibreOffice and survive round-trips through .xlsx. Reserve LAMBDA for workbooks that will only ever open in modern Excel or Google Sheets.
Honest limits
The Excel values are Microsoft's documented behaviour, not something we executed in Excel.
Google Sheets does implement LAMBDA and these helpers, and our executed run confirms it for all
six: LAMBDA, MAP, SCAN, REDUCE, BYROW,
BYCOL and MAKEARRAY. The BYROW/BYCOL/MAKEARRAY
figures needed a follow-up run on 2026-08-29 that wrote the formulas with plain (unprefixed) function
names — the original _xlfn.-prefixed pass was inconclusive because Google’s
importer did not map that storage form, not because Sheets lacked the functions. Both runs are kept in
our results file, with per-function provenance recorded in subset_runs.
Excel for the web is the third engine we execute, and this is the one family it could not reach.
LAMBDA, MAP, MAKEARRAY, REDUCE and
SCAN are stored in an .xlsx with the _xlpm./LAMBDA
serialization, and the web app’s file-open refuses any workbook that carries it — proven
by bisecting the corpus down to a probe containing nothing else. BYROW and
BYCOL got further: their chunk opened and recalculated, but the two array formulas were
deleted from the downloaded package rather than computed. So there is no
Excel-for-the-web verdict for any of the seven, and none is implied here; that is a fact about the
transport, not about the engine.
Check before you migrate
A note on which Excel this is. The Excel column in the tables above is Microsoft’s documented behaviour for desktop Excel, as recorded in our test corpus — we do not run desktop Excel, and no value in that column is a measurement. Excel for the web is a different application with its own calculation engine, and that one we do run (recalculated on OneDrive, 2026-09-01). Its measured results are published on each function’s own page rather than in these guide tables. Because we have no desktop run to compare against, a disagreement between an Excel-web measurement and the documented column is genuinely ambiguous: it may mean the web engine diverges from the desktop one, or that the documentation is wrong about both. We do not claim to know which.