Invoice currency identifies the currency of the invoice’s monetary amounts. A tax accounting currency, where required by the applicable workflow, is a separate currency role for tax reporting information. Choosing the invoice currency does not automatically calculate a second tax amount or satisfy a requirement to report tax in another currency.
The invoice amount workflow uses one supported invoice currency in the current creator. There is no separate tax accounting currency, exchange-rate input or second-currency tax calculation. If your final invoice requires those features, use an appropriate system rather than assuming the country selector supplies them.
Identify the invoice’s monetary basis
Confirm the currency agreed for the sale before entering prices. A bare number such as 500.00 is incomplete without its currency context. Check the order, quote and customer agreement rather than selecting a familiar symbol from a previous draft.
The creator offers EUR, GBP, USD, CAD, AUD, CHF and PLN. Its current calculation model uses two decimal places for money across those choices. This is an application capability list, not a claim that it supports every currency rule or every jurisdiction’s invoicing requirements.
Keep currency consistent across the entered line amounts. The app does not let each row carry an independently calculated foreign-currency amount. If source costs were incurred in several currencies, those internal costs are not automatically the customer-facing invoice amounts.
Understand the separate tax currency role
A formal profile may distinguish the invoice currency from a tax accounting currency. Peppol BIS Billing, for example, documents a separate tax-currency field for the currency used for VAT accounting and reporting in the relevant context. That illustrates a specific structured role, not a universal requirement for every invoice.
Whether the role is needed depends on the actual transaction and applicable requirements. Do not assume every cross-border sale needs a second currency, or that selecting the seller’s country tells the creator which tax currency applies. The app does not make that determination.
Where a second tax currency is required, the workflow needs the correct amounts, conversion basis and structured representation. A note naming another currency is not equivalent to implementing those fields or validating the relationship between them.
Do not confuse currency selection with conversion
Changing the selector from EUR to USD does not multiply the values by an exchange rate. A price entered as 100.00 remains numerically 100.00, now under a different selected currency context. That can materially change the invoice’s meaning without changing its digits.
The guide to currency labels and amount conversion explains the practical risk. Review every amount when the agreed invoice currency changes. Do not rely on the preview looking similar as evidence that a conversion happened.
If conversion is necessary, determine the appropriate rate, date, source and rounding treatment under the actual agreement and requirements. The current creator does not retrieve exchange rates or decide which rate should be used. Preserve the conversion evidence outside the app when preparing data for a suitable final system.
Keep tax determination separate
A currency choice does not determine whether tax applies, which rate applies or which party accounts for it. The creator’s tax information is manually entered per line. Its field validation checks supported values and reasons, not the legal treatment of a foreign-currency transaction.
Likewise, a second tax currency would not by itself make an invoice formally compliant. The final system would still need the correct semantic mapping, syntax and business-rule validation for its destination. A matching tax figure in two currencies is only one part of that process.
Do not adjust the entered tax rate to approximate a desired foreign-currency tax amount. That changes the tax statement rather than adding a conversion. Use a workflow that can represent both roles accurately when the transaction requires them.
Review the final export context
Before exporting, compare the selected currency with the accepted price agreement and any payment instructions. A bank account capable of receiving several currencies does not establish which currency the customer owes. Make the intended monetary basis clear and consistent.
If you transfer the application JSON into another process, preserve its currency context with the numbers. Copying only the numeric amounts can lose information that is essential to interpretation. The line-item CSV is not a full formal invoice or a second-currency tax report.
Where tax accounting currency is required, complete the invoice in a system that genuinely implements the role, calculation and required validation. The current printable preview, JSON and CSV do not provide that capability. Keep the evidence for currency and conversion decisions with the final invoice records, and verify the destination requirements before treating the document as ready for delivery.
In a transfer checklist, label the currency roles explicitly rather than writing one unexplained currency code beside all amounts. Record which figures belong to the invoice and which are required for tax accounting. A later import should not assign the same number to both roles by default. Check the final system’s output against the role and conversion evidence, not just against the appearance of its currency symbol.