Multi-currency invoices: converting to euros (2026)

Not every incoming invoice is in euros. Freight carriers, IT vendors, Scandinavian partners and marketplaces (Amazon, eBay) send documents in PLN, GBP, SEK, USD or other currencies. In accounting that means an extra manual step: find that day's rate, convert the amount to euros, and only then enter it. This article explains why that takes time and how Ezura converts currency automatically — using the official Bank of Lithuania rate.

Why exchange rates slow accounting down

Lithuania's Financial Accounting Law does not prescribe one mandatory rate. It requires the company to fix two choices in its accounting policy: the source — the European Central Bank reference rate (or the Bank of Lithuania rate where the ECB publishes none), or another generally recognised market source — and which day's rate applies: the operation date's, or the last one published before it. Most Lithuanian companies choose the Bank of Lithuania accounting rates and the operation-date rate. In practice that means for every non-euro invoice someone opens lb.lt, finds the rate for the document date and converts by hand. Invoices dated on a weekend or holiday add another question: no rate is published that day, so the last one published before it applies.

Mistakes here are expensive: a wrong rate distorts the cost in euros and the result that follows from it, and if the EUR value never gets recorded the document reaches the accounting system without it — so it has to be fixed by hand inside the system. At a few dozen foreign invoices a month that becomes an hour nobody planned for.

Ezura applies the Bank of Lithuania rate automatically

When an invoice is read, its currency is not the euro and the document date is known, Ezura picks the Bank of Lithuania accounting rate applicable to that date and shows the EUR value under the totals: “≈ €1,234.56 (LB rate 4.3258, 2026-07-15)”. The rate is tied to the document (operation) date, not the moment of entry — which matches the policy variant most companies choose. If no rate was published that day — weekend or holiday — the last one published before it applies. And if your accounting policy records a different variant, tell us: the system should match your policy, not the other way round.

It is not only the grand total that gets converted. Stored on the invoice are:

• •the rate and its date (tied to the document date, not the entry day)
• •the net amount, VAT amount and grand total in euros
• •the original amounts in their currency — nothing is thrown away
• •the EUR value is recomputed if you edit the date, currency or amounts; once exported it is frozen as an audit record

About 170 currencies are supported — from the common ones (GBP, SEK, PLN, USD, CAD, AUD) to rarer ones. The accountant no longer looks up or types a rate; if some exotic currency has no rate, the document is flagged with a badge and exported as before.

Reverse charge on foreign invoices

Foreign suppliers' invoices are often reverse charge: under Article 95 of the VAT Law the obligation to account for VAT falls on the buyer, and the invoice carries a note reading “Reverse charge” or “Atvirkštinis apmokestinimas”. Ezura recognises these markers in both Lithuanian and English, so such a line is not entered as ordinary domestic 21% VAT. This matters because reverse-charge confusion is usually the real reason foreign invoices need manual work.

Several currencies on one invoice

Marketplace invoices (Amazon, for example) often list commissions, shipping and service fees in several currencies on one document, and the symbols are ambiguous: “$” can mean the US, Australian or Canadian dollar. Ezura disambiguates symbols by context — “AU $” as AUD, “C $” as CAD, “zł” as PLN — and converts the lines to euros instead of blindly treating everything as dollars. That keeps a multi-currency summary invoice from becoming an hour-long puzzle.

Export with the EUR amount and rate

The converted amount does not just sit on screen. Documents reach Rivile and Pragma with the EUR value and the rate already in place, so there is nothing to correct inside the program. EuroSkaita, Agnum, B1 and Navision receive the correct currency code, with the EUR value added where it is needed. The practical result is simple: a non-euro invoice closes in the same pass as a euro one instead of landing on the “fix this later” pile until month-end.

What the whole path looks like

A supplier emails a PLN or GBP invoice to your Ezura address. The system reads it, applies the Bank of Lithuania rate for the document date and computes the amounts in euros, detects reverse charge if it is stated, and assigns dimensions by your rules. The accountant reviews the result with the EUR value visible and approves — the document is exported with the EUR amount and rate already in place. The step of looking up a rate by hand is simply gone.