159 Currencies in the Invoice Maker: The Symbol, the Smallest Unit and the Rounding
Disclosure first: I work on OnePassApps. This is our own app, and every number below was measured in it today. 159 Currencies in the Invoice Maker: The Symbol, the Smallest Unit and the Rounding The Invoice M
Disclosure first: I work on OnePassApps. This is our own app, and every number below was measured in it today.
159 Currencies in the Invoice Maker: The Symbol, the Smallest Unit and the Rounding
The Invoice Maker at app.onepassapps.com/apps/invoice-maker has a Currency control in its Settings column, and it offers 159 currencies. What that control changes is more than the symbol on the invoice. It changes how many decimals the preview prints, which unit every amount is rounded to, and the totals themselves. The numbers below come from one invoice, one line and one signed-out browser session on 8 November 2026.
This is the companion to the earlier post on where the penny lands, which stayed on GBP the whole way. That post is about what the rounding does; this one is about what happens when the currency is not the one with two decimals.
The picker has 159 entries, and 59 of them have no symbol
Open the Currency control and the list has 159 entries, all of them different. 100 carry a symbol in brackets - "GBP (Β£)", "EUR (β¬)", "JPY (Β₯)" - and 59 are a bare ISO code with no symbol at all: AED, ALL, ANG, AWG, BGN, BHD, BIF, BTN, BYN, CDF, CHF, CVE and the rest of that list. For those, the button in the form shows the code and nothing else, so a Kuwaiti dinar invoice is set with a button that reads "KWD" and a Swiss franc one reads "CHF".
The sentence under the totals follows the currency
The preview prints one line under the totals, and it names the currency you picked:
- "Amounts are worked out in GBPβs smallest unit and rounded half-up on each line."
- "Amounts are worked out in EURβs smallest unit and rounded half-up on each line."
- "Amounts are worked out in JPYβs smallest unit and rounded half-up on each line."
- "Amounts are worked out in KWDβs smallest unit and rounded half-up on each line."
Same sentence, same rule, a different currency in it. That is the app stating the rule rather than this post inferring it.
One invoice, four currencies
The typed input was the same in every case: description Consulting, quantity 3, unit price 1234.56, tax rate 8%.
| Currency | Line amount | Tax row | Total |
|---|---|---|---|
| GBP (Β£) | Β£3,703.68 | Β£296.29 | Β£3,999.97 |
| EUR (β¬) | β¬3,703.68 | β¬296.29 | β¬3,999.97 |
| JPY (Β₯) | JPΒ₯3,704 | JPΒ₯296 | JPΒ₯4,000 |
| KWD | KWDΒ 3,703.680 | KWDΒ 296.294 | KWDΒ 3,999.974 |
The pound and euro rows carry the same value, because the arithmetic is the same and both currencies have a hundredth as their smallest unit. The yen row is that arithmetic carried to whole yen, and the dinar row is it carried to the third decimal.
The tax row prints its own base: "Tax at 8% on Β£3,703.68" for pounds, and "Tax at 8% on JPΒ₯3,704" for yen and "Tax at 8% on KWDΒ 3,703.680" for dinars. The totals row is labelled with the currency code - "Total due (GBP)" - and the chip at the top of the preview follows the money too: "A4 Β· Β£3,999.97" for pounds, "A4 Β· JPΒ₯4,000" for yen. The subtotal and the tax row add up to the total in each case: Β£3,703.68 plus Β£296.29 is Β£3,999.97, JPΒ₯3,704 plus JPΒ₯296 is JPΒ₯4,000, and KWDΒ 3,703.680 plus KWDΒ 296.294 is KWDΒ 3,999.974.
Two printing details worth knowing
The symbol in the picker and the symbol on the invoice are not always the same string. The yen amounts print with a country prefix - "JPΒ₯3,704" - while the picker says "JPY (Β₯)". And a currency with no symbol prints its code and a space, so the dinar line amount reads "KWDΒ 3,703.680" rather than a symbol and a number.
Switching currency does not convert anything
This is the part that catches people out. The Currency control is a formatting and rounding control, not a conversion control. The unit price field still held 1234.56 after switching to EUR, then to JPY and then to KWD, and the quantity still held 3 - the typed values were the same in every case. The panel has no exchange-rate field at all, so there is no rate to convert with. What changes is how those values are printed and which unit they are rounded to. So if you are billing a client in yen, you type yen amounts: the app will not turn pounds into yen for you, and it does not claim to.
The smallest unit decides how many decimals survive
The unit price cell keeps the digits you typed, with the currency in front - "Β£0.005" under pounds, "JPΒ₯0.005" under yen, "KWDΒ 0.005" under dinars, "Β£0.004" for four thousandths of a pound. It is the AMOUNT cell that gets rounded. With unit price 0.005, quantity 1 and no tax:
| Currency | Amount |
|---|---|
| GBP (Β£) | Β£0.01 |
| JPY (Β₯) | JPΒ₯0 |
| KWD | KWDΒ 0.005 |
And with unit price 0.004:
| Currency | Amount |
|---|---|
| GBP (Β£) | Β£0.00 |
| JPY (Β₯) | JPΒ₯0 |
| KWD | KWDΒ 0.004 |
A half penny becomes a penny in pounds and nothing at all in yen, while in dinars the same number is exactly five fils. The rule is the same everywhere: amounts are rounded half-up in each currencyβs own smallest unit.
Three decimals survive in a three-decimal currency
Type a unit price with three decimals - 1234.567 - with quantity 3 and tax 8%, and the line amount keeps all three in dinars: KWDΒ 3,703.701, with tax KWDΒ 296.296 and total KWDΒ 3,999.997. The same invoice in yen prints JPΒ₯3,704, tax JPΒ₯296 and total JPΒ₯4,000, with not one decimal anywhere.
The empty states
With no unit price typed, the AMOUNT column prints an em dash - "β" - and the totals print the currency at zero: Β£0.00. A 0% tax rate prints no tax row at all, so the number of rows changes with the rate rather than showing a zero line.
The fields behind the arithmetic
The unit price input accepts up to 22 characters, the quantity 12 and the tax rate 8, so a three-decimal amount fits comfortably and the tax field has room for a fractional rate. The rounding happens in the preview, on the way to the printed totals, not in the fields.
What I did not test
One build, one signed-out browser session, one invoice, one line, 8 November 2026. Four currencies were priced - GBP, EUR, JPY and KWD; the other 155 were read from the picker list but never put through the arithmetic. I did not touch the discount control, the Quote document type, the other paper size, the draft JSON export and import, or printing to a PDF, and the tax rate was 8% except in the two runs where it was 0%. Every total above is what the preview printed; I did not print a document.
If you want the arithmetic of the rounding itself, it is in the earlier post: https://dev.to/onepassapps/where-the-penny-lands-the-order-of-rounding-inside-the-onepassapps-invoice-maker-2ooo
The app itself: https://app.onepassapps.com/apps/invoice-maker?utm_source=devto&utm_medium=post&utm_campaign=invoice-currency&utm_content=invoice-maker-link
And the written guides: https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=invoice-currency&utm_content=guides-link
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.