← All functions

RECEIVED

Quirk found

Category: Financial · Last tested 2026-09-01

Real compatibility results for the RECEIVED function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.

Support matrix

EngineDocumentedLive-testedVerdict
Excel (desktop)Yes No — documented only n/a
Excel for the web— Yes (recalc, 2026-09-01) Supported, behaves as documented
Google SheetsYes Yes (Drive import, 2026-08-31) Supported, behaves as documented
LibreOffice CalcYes Yes (25.8.7.3, 2026-08-31) Quirk found

LibreOffice version history

We executed the same test cases under each LibreOffice release to show exactly when RECEIVED’s support changed — not documentation claims, real results.

LibreOffice versionVerdictTested
24.2.0.3 Quirk found 2026-08-31
24.8.7.2 Quirk found 2026-08-31
25.2.0.3 Quirk found 2026-08-31
25.8.7.3 Quirk found 2026-08-31

Why isn't RECEIVED working in LibreOffice?

RECEIVED exists in LibreOffice 25.8.7.3, but it is not a drop-in match for Excel — our executed tests found real behavioral differences (detailed in the test results on this page). If a formula that works in Excel or Google Sheets misbehaves in LibreOffice, compare your usage against the failing cases above before assuming your data is wrong.

Google Sheets: 1 case inconclusive. Our corpus is an Excel-authored .xlsx, and Google’s importer does not map every OOXML storage prefix (_xlfn., _xlfn._xlws., _xlpm.) — nor does the .xlsx export preserve full float precision or a blank result. Where the disagreement is explained by that round trip we report it as inconclusive rather than as a Sheets behavior. Google documents this function, so the result is not evidence of missing support. See the methodology page for the full caveat and the planned re-run with plain function names.

Discovered quirks

Executed test cases

Excel for the web (executed 2026-09-01 via OneDrive recalculation)

These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.

FormulaDescriptionResultExpectedVerdict
=ROUND(RECEIVED(A2,A3,A4,A5,A6),2) Microsoft's documented worked example, at the published precision 1014584.65 1014584.65
Provenance

Microsoft publishes =RECEIVED(A2,A3,A4,A5,A6) = $1,014,584.65 for a $1,000,000 investment settled 2008-02-15, maturing 2008-05-15, at a 5.75% discount, on basis 2 (Actual/360). DERIVATION from the formula Microsoft prints as an image, RECEIVED = investment / (1 - discount * DIM/B): the actual days from settlement to maturity are 90 (2008 being a leap year makes February 29th one of them), so the value is 1000000/(1 - 0.0575*90/360) = 1000000/0.985625 = 1600000000/1577 in exact rational arithmetic = 1014584.654407102... OpenFormula 1.3 section 6.12.43 gives the same formula written through YEARFRAC. NOTE ON MICROSOFT'S SYMBOLS: this page reuses the name DIM for days from SETTLEMENT to maturity, while the PRICEMAT page uses DIM for days from ISSUE to maturity -- the same three letters for two different quantities on two neighbouring pages. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/received-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB).

Matched
=ROUND(RECEIVED(A2,A3,A4,A5,A6),6) The same example carried to six decimal places 1014584.654407 1014584.654407
Provenance

Asserted at six places from the exact rational 1600000000/1577 = 1014584.654407102... On a value above a million, six decimals is already eleven significant figures, close to the limit of what a double carries -- which is why this case stops there rather than at ten.

Matched
=RECEIVED(A2,A3,0,A5,A6) An investment of zero, which the page excludes #NUM! #NUM!
Provenance

Microsoft documents: "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value."

Matched
=RECEIVED(A2,A3,A4,0,A6) A discount of zero, the other half of the same documented exclusion #NUM! #NUM!
Provenance

The second half of "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value", asserted separately because an engine can guard one argument and not the other. A zero discount is arithmetically harmless -- the formula would simply return the investment -- so an engine that computes it instead of erroring is following the arithmetic rather than the documentation.

Matched
=RECEIVED(A2,A3,A4,A5,5) A basis of 5, one past the documented range #NUM! #NUM!
Provenance

Microsoft documents: "If basis < 0 or if basis > 4, RECEIVED returns the #NUM! error value."

Matched
=RECEIVED(A3,A3,A4,A5,A6) Settlement equal to maturity #NUM! #NUM!
Provenance

Microsoft documents: "If settlement >= maturity, RECEIVED returns the #NUM! error value." OpenFormula 1.3 section 6.12.43 requires Settlement < Maturity as well.

Matched
=RECEIVED("not a date",A3,A4,A5,A6) A settlement date that is not a date #VALUE! #VALUE!
Provenance

Microsoft documents: "If settlement or maturity is not a valid date, RECEIVED returns the #VALUE! error value."

Matched

Google Sheets (executed 2026-08-31 via Drive import)

Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.

FormulaDescriptionResultExpectedVerdict
=ROUND(RECEIVED(A2,A3,A4,A5,A6),2) Microsoft's documented worked example, at the published precision 1014584.65 1014584.65
Provenance

Microsoft publishes =RECEIVED(A2,A3,A4,A5,A6) = $1,014,584.65 for a $1,000,000 investment settled 2008-02-15, maturing 2008-05-15, at a 5.75% discount, on basis 2 (Actual/360). DERIVATION from the formula Microsoft prints as an image, RECEIVED = investment / (1 - discount * DIM/B): the actual days from settlement to maturity are 90 (2008 being a leap year makes February 29th one of them), so the value is 1000000/(1 - 0.0575*90/360) = 1000000/0.985625 = 1600000000/1577 in exact rational arithmetic = 1014584.654407102... OpenFormula 1.3 section 6.12.43 gives the same formula written through YEARFRAC. NOTE ON MICROSOFT'S SYMBOLS: this page reuses the name DIM for days from SETTLEMENT to maturity, while the PRICEMAT page uses DIM for days from ISSUE to maturity -- the same three letters for two different quantities on two neighbouring pages. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/received-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB).

Matched
=ROUND(RECEIVED(A2,A3,A4,A5,A6),6) The same example carried to six decimal places 1014584.654 1014584.654407
Provenance

Asserted at six places from the exact rational 1600000000/1577 = 1014584.654407102... On a value above a million, six decimals is already eleven significant figures, close to the limit of what a double carries -- which is why this case stops there rather than at ten.

Inconclusive
=RECEIVED(A2,A3,0,A5,A6) An investment of zero, which the page excludes #NUM! #NUM!
Provenance

Microsoft documents: "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value."

Matched
=RECEIVED(A2,A3,A4,0,A6) A discount of zero, the other half of the same documented exclusion #NUM! #NUM!
Provenance

The second half of "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value", asserted separately because an engine can guard one argument and not the other. A zero discount is arithmetically harmless -- the formula would simply return the investment -- so an engine that computes it instead of erroring is following the arithmetic rather than the documentation.

Matched
=RECEIVED(A2,A3,A4,A5,5) A basis of 5, one past the documented range #NUM! #NUM!
Provenance

Microsoft documents: "If basis < 0 or if basis > 4, RECEIVED returns the #NUM! error value."

Matched
=RECEIVED(A3,A3,A4,A5,A6) Settlement equal to maturity #NUM! #NUM!
Provenance

Microsoft documents: "If settlement >= maturity, RECEIVED returns the #NUM! error value." OpenFormula 1.3 section 6.12.43 requires Settlement < Maturity as well.

Matched
=RECEIVED("not a date",A3,A4,A5,A6) A settlement date that is not a date #VALUE! #VALUE!
Provenance

Microsoft documents: "If settlement or maturity is not a valid date, RECEIVED returns the #VALUE! error value."

Matched

LibreOffice Calc 25.8.7.3 (tested 2026-08-31)

FormulaDescriptionResultExpectedVerdict
=ROUND(RECEIVED(A2,A3,A4,A5,A6),2) Microsoft's documented worked example, at the published precision 1014584.65 1014584.65
Provenance

Microsoft publishes =RECEIVED(A2,A3,A4,A5,A6) = $1,014,584.65 for a $1,000,000 investment settled 2008-02-15, maturing 2008-05-15, at a 5.75% discount, on basis 2 (Actual/360). DERIVATION from the formula Microsoft prints as an image, RECEIVED = investment / (1 - discount * DIM/B): the actual days from settlement to maturity are 90 (2008 being a leap year makes February 29th one of them), so the value is 1000000/(1 - 0.0575*90/360) = 1000000/0.985625 = 1600000000/1577 in exact rational arithmetic = 1014584.654407102... OpenFormula 1.3 section 6.12.43 gives the same formula written through YEARFRAC. NOTE ON MICROSOFT'S SYMBOLS: this page reuses the name DIM for days from SETTLEMENT to maturity, while the PRICEMAT page uses DIM for days from ISSUE to maturity -- the same three letters for two different quantities on two neighbouring pages. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/received-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB).

Matched
=ROUND(RECEIVED(A2,A3,A4,A5,A6),6) The same example carried to six decimal places 1014584.654407 1014584.654407
Provenance

Asserted at six places from the exact rational 1600000000/1577 = 1014584.654407102... On a value above a million, six decimals is already eleven significant figures, close to the limit of what a double carries -- which is why this case stops there rather than at ten.

Matched
=RECEIVED(A2,A3,0,A5,A6) An investment of zero, which the page excludes #VALUE! #NUM!
Provenance

Microsoft documents: "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value."

Mismatch
=RECEIVED(A2,A3,A4,0,A6) A discount of zero, the other half of the same documented exclusion #VALUE! #NUM!
Provenance

The second half of "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value", asserted separately because an engine can guard one argument and not the other. A zero discount is arithmetically harmless -- the formula would simply return the investment -- so an engine that computes it instead of erroring is following the arithmetic rather than the documentation.

Mismatch
=RECEIVED(A2,A3,A4,A5,5) A basis of 5, one past the documented range #VALUE! #NUM!
Provenance

Microsoft documents: "If basis < 0 or if basis > 4, RECEIVED returns the #NUM! error value."

Mismatch
=RECEIVED(A3,A3,A4,A5,A6) Settlement equal to maturity #VALUE! #NUM!
Provenance

Microsoft documents: "If settlement >= maturity, RECEIVED returns the #NUM! error value." OpenFormula 1.3 section 6.12.43 requires Settlement < Maturity as well.

Mismatch
=RECEIVED("not a date",A3,A4,A5,A6) A settlement date that is not a date #VALUE! #VALUE!
Provenance

Microsoft documents: "If settlement or maturity is not a valid date, RECEIVED returns the #VALUE! error value."

Matched

Docs & syntax

Where RECEIVED behaves differently