EUROCONVERT

What it does

EUROCONVERT(number, source, target, [full_precision], [triangulation_precision])

EUROCONVERT is a historical artifact with unusually precise semantics. It converts between the euro and the currencies it replaced, at the irrevocably fixed conversion rates set when each currency joined — not at market rates, which is why the function can be deterministic and offline at all. It exists to implement the conversion rules that came with those rates, including a mandated rounding regime and a mandated way of routing one legacy currency to another.

Three conversion directions, with different arithmetic:

1. National → euro. Divide by that currency's fixed rate.
2. Euro → national. Multiply by that currency's fixed rate.
3. National → national (triangulation). Convert the source to euro, round that intermediate euro amount to triangulation_precision significant digits, then convert the rounded intermediate to the target currency. The mandated intermediate step is what "triangulation" names, and it is the reason this function cannot be replaced by a single multiplication: a direct source-to-target rate would give a different, non-conforming answer.

And one identity case Microsoft states explicitly: if the source ISO code is the same as the target ISO code, the original number is returned.

The rate table covers fourteen ISO codes:

BEF LUF DEM ESP FRF IEP ITL NLG ATS PTE FIM GRD SIT EUR

The rates themselves are not Excel's invention — they are the fixed conversion rates adopted in EU law when each currency's euro entry was settled, and they never change. The Handbook does not transcribe them on this page; the authoritative source is named under Sources, and any implementation should take them from there rather than from a spreadsheet.

The rounding regime

full_precision selects between two very different results. When it is FALSE (Microsoft documents FALSE as the default), the result is rounded according to currency-specific rules; when TRUE, all significant digits from the calculation are kept.

Microsoft's documented precision table:

The third row is the interesting one and is not a typo: for the escudo and the drachma, calculation precision and display precision differ. Those currencies had subunits that were no longer in practical use, so amounts were computed to whole units but presented with two decimals. Any implementation that collapses the two columns into one will be wrong for exactly two of the fourteen currencies — a defect that is invisible for most test data.

Note also that these are currency precisions, not a single function-wide rounding rule. The same formula rounds differently depending on which target currency you name.

Arguments

EUROCONVERT(number, source, target, [full_precision], [triangulation_precision])

• number (required) — the currency value to convert, or a reference to a cell containing it.
• source (required) — a three-letter ISO code from the list above, as text or a cell reference.
• target (required) — likewise, the ISO code to convert to.

Try it

This spelling is not registered in the OneCalc preview engine, so calculation returns #NAME? here. See the function guide for Excel availability.

Quirks

Result and edge cases

A number, with two documented behaviours that are easy to miss:

• "Excel truncates any trailing zeros in the return value." So the value is rounded to the currency's precision but the representation does not preserve trailing zeros — a conversion to a 2-decimal currency landing on a round amount does not come back as 12.50.
• "This function does not apply a number format." The result is a bare number; currency formatting is the workbook's job. That separation is consistent with the Handbook's model, in which function pages describe values and not cell presentation (see the call pipeline).

And one structural restriction with no analogue elsewhere in this batch: "This function cannot be used in array formulas." Almost every scalar function in Excel lifts over arrays; this one is documented as refusing to. That makes EUROCONVERT an explicit exception to the array-lifting baseline described in coercion and lifting, and the manner of the refusal — error, first-element-only, or entry-time rejection — is not stated.

Errors

As documented by Microsoft:

• #NAME? — the Euro Currency Tools add-in is not installed and loaded. This is the characteristic failure of the whole add-in-owned category: the workbook is fine, the formula is fine, and the name simply does not exist in this session.
• #VALUE! — "Invalid parameters return #VALUE." Microsoft gives no finer breakdown, so an unrecognized ISO code, a non-numeric number, and a triangulation_precision below 3 are all documented as landing on the same code.

How to implement

Notes for implementers

• Triangulation is not associative with plain rounding. Convert FRF → DEM directly by a composed rate and you get a different answer from the mandated route through a significant-digit-rounded euro intermediate. The intermediate rounding is the specification, not an implementation detail.
• Significant digits, not decimal places. triangulation_precision is documented as significant digits with a floor of 3. Implementing it as decimal places will agree on some magnitudes and diverge on others, which is the worst kind of bug.
• Calculation precision and display precision are two columns. See PTE and GRD above.
• The array-formula restriction is a real behavioural axis. A modern reimplementation will naturally lift over arrays and will thereby accept formulas Excel refuses. Whether that matters depends on whether the goal is compatibility or utility — the Handbook's four-flavour framing is exactly the place to make that choice explicit (see implementation options).

Rust code

This entry has no Rust implementation yet.

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• CONVERT — the function readers reach for and the one that does not do currencies. CONVERT handles physical units (mass, distance, time, temperature). The two are neighbours in intent and disjoint in domain.
• CALL and REGISTER.ID — the other entries in the same "installed with add-ins" category, though they are a registration seam rather than a computation. What EUROCONVERT shares with them is the #NAME?-when-absent behaviour.
• STOCKHISTORY and the Currencies linked data type — the modern, market-rate path for currency conversion. They are not replacements for EUROCONVERT and must not be treated as such: EUROCONVERT implements a legal conversion at a frozen rate, not a market quote. Using a live rate to convert a legacy amount is a different and usually wrong operation.
• ROUND — worth naming because the temptation is to reimplement EUROCONVERT as a multiplication plus a ROUND. That reproduces neither the two-column precision table nor the triangulation intermediate.

Named variants

No named variants are recorded yet.