RECEIVED
Quirk foundCategory: 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
| Engine | Documented | Live-tested | Verdict |
|---|---|---|---|
| Excel (desktop) | Yes | No — documented only | n/a |
| Excel for the web | — | Yes (recalc, 2026-09-01) | Supported, behaves as documented |
| Google Sheets | Yes | Yes (Drive import, 2026-08-31) | Supported, behaves as documented |
| LibreOffice Calc | Yes | 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 version | Verdict | Tested |
|---|---|---|
| 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.
_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
-
=RECEIVED(A2,A3,0,A5,A6) on
LibreOffice Calc returned
#VALUE!, but the documented/expected
result is #NUM!.
Provenance
Microsoft documents: "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
-
=RECEIVED(A2,A3,A4,0,A6) on
LibreOffice Calc returned
#VALUE!, but the documented/expected
result is #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 vs expected: expected '#NUM!', got '#VALUE!'
-
=RECEIVED(A2,A3,A4,A5,5) on
LibreOffice Calc returned
#VALUE!, but the documented/expected
result is #NUM!.
Provenance
Microsoft documents: "If basis < 0 or if basis > 4, RECEIVED returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
-
=RECEIVED(A3,A3,A4,A5,A6) on
LibreOffice Calc returned
#VALUE!, but the documented/expected
result is #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 vs expected: expected '#NUM!', got '#VALUE!'
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.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(RECEIVED(A2,A3,A4,A5,A6),2) | Microsoft's documented worked example, at the published precision | 1014584.65 | 1014584.65ProvenanceMicrosoft 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.654407ProvenanceAsserted 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!ProvenanceMicrosoft 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!ProvenanceThe 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft 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.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(RECEIVED(A2,A3,A4,A5,A6),2) | Microsoft's documented worked example, at the published precision | 1014584.65 | 1014584.65ProvenanceMicrosoft 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.654407ProvenanceAsserted 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!ProvenanceMicrosoft 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!ProvenanceThe 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft 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)
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =ROUND(RECEIVED(A2,A3,A4,A5,A6),2) | Microsoft's documented worked example, at the published precision | 1014584.65 | 1014584.65ProvenanceMicrosoft 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.654407ProvenanceAsserted 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!ProvenanceMicrosoft 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!ProvenanceThe 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft 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!ProvenanceMicrosoft documents: "If settlement or maturity is not a valid date, RECEIVED returns the #VALUE! error value." |
Matched |
Docs & syntax
- Excel (desktop): official documentation
- Google Sheets: official documentation
- LibreOffice Calc: official documentation
Where RECEIVED behaves differently
- Bond and treasury functions after a migration: what actually breaks
Executed across 26 fixed-income functions and 161 cases: ODDFPRICE and ODDFYIELD are literal stubs in LibreOffice, TBILLPRICE prices a two-year bill, INTRATE's default basis loses a day, and MDURATION is wrong on actual/actual. 83 of 84 documented #NUM! cases arrive as #VALUE!. Google Sheets matched 127 of 161. - Every error code LibreOffice reports as #VALUE!
Across our 2,334-case executed corpus, 272 cases in 135 functions return #VALUE! in LibreOffice Calc 25.8.7.3 where Microsoft documents #NUM! (244), #N/A (15), #DIV/0! (10) or #REF! (3). Google Sheets returns the documented code on 239 of the 249 it has a function for. Identical in all four LibreOffice builds tested.