Multi-Currency Invoicing: Automated Currency Conversion

Multi-currency invoicing is the handling of outside counsel invoices submitted in a currency other than your department’s system currency, with each amount converted so budgets, reports, and payments line up. Automated currency conversion does the arithmetic inside your ELM platform, using a configured exchange-rate source and a configured date. The arithmetic is the easy part. The decisions around it (which date sets the rate, what gets stored, how rounding and allocations behave) decide whether finance can reconcile your legal spend at quarter end.

What is multi-currency invoicing in legal eBilling?

Multi-currency invoicing in legal eBilling means a firm submits its invoice in its own currency, the platform keeps that native amount, and a converted amount in your system currency drives budgets and reporting. Most ELM platforms hold one system currency for the whole organization and record the invoice currency separately whenever a firm bills in another.

Three currencies can be in play on one invoice:

• Native currency. The currency the firm billed in, such as EUR or GBP. This is the legally binding amount and the one you will usually pay.
• System currency. Your reporting currency, typically USD for a US-headquartered department, used for budgets and dashboards.
• Budget currency. The currency a specific matter budget was set in, which can differ from both on a regional matter.

Departments with outside counsel in 10 or more countries commonly see five to eight invoice currencies in a year. Every one needs the same treatment, which is why conversion belongs in configuration and out of spreadsheets. Rates move constantly in a very large market: the 2025 triennial central bank survey found global FX trading reached $9.6 trillion a day, with the US dollar on one side of 89 percent of trades.

How does automated currency conversion work in an ELM platform?

Automated currency conversion in an ELM platform multiplies the native amount by an exchange rate drawn from a rate source for a set date. Onit Unity, Onit’s AI-native ELM platform, loads Open Exchange Rates data nightly and stamps each invoice with the most recent rate when the vendor submits it, and the stamped rate does not change afterward.

A simple example shows the moving parts. An invoice totals EUR 10,000, and the rate for the governing date is 1.08, so the converted amount is USD 10,800. The platform should keep the EUR figure, the USD figure, the rate, the rate source, and the date that selected it.

Check how conversion interacts with your billing rules before go-live. In Unity, only invoices submitted in US dollars can be adjusted manually or through automated rules, so foreign-currency invoices need their own review path. On any platform, a rate cap written in USD only works against an invoice in GBP once the conversion has happened.

Which date should set the exchange rate on a legal invoice?

The date that sets the exchange rate on a legal invoice should be written into your currency policy, because the worked date, the submission date, and the payment date each produce different numbers on the same invoice. Some platforms fix the basis for you, so check yours first.

• Line-item worked date. Each line converts at the rate for the day the work was done. This is the more precise method, and an invoice covering 30 days of work can carry 20 or more different rates.
• Submission date. The whole invoice converts at one rate, which is how Unity stamps it. This is simpler to explain to finance and to audit, and it matches how most AP teams think about a payable.
• Payment date. Your bank converts at the rate on the day it pays. Expect a gap between the eBilling amount and the settled amount, and agree where that variance is booked.

Whichever basis applies, document it in the solution design and apply it to every currency. A department where EUR invoices use worked dates and GBP invoices use received dates will spend every quarter end explaining the difference.

What currency data should every converted invoice keep?

Every converted invoice should keep enough currency data that anyone can recreate the converted figure months later without asking the platform. In Unity, the matter Invoices tab shows a Native Adjusted Total, and reports carry a Native Billed Amount beside the system-currency Billed Total.

• Native amount and currency. The original invoice, line, tax, and expense amounts exactly as the firm submitted them.
• Rate, source, and date basis. The rate value, where it came from, and which date selected it.
• Converted amount. The system-currency figure, stored, so a later rate refresh never rewrites history.
• Override history. Any manual rate change with the user, reason, timestamp, and approver.

Label every currency-sensitive report with the currency shown. A dashboard that quietly mixes EUR and USD totals is wrong in a way nobody notices for months.

How do currency conversions affect cost allocations?

Currency conversions affect cost allocations because a split written in fixed amounts stops adding up once the invoice total arrives in another currency. Percentage splits survive conversion, so most departments allocate foreign-currency invoices and split line items by percentage.

• Percentages must total 100. Check whether your platform rebalances them. Where it does not, a split of 33, 33, and 33 leaves one percent unallocated until someone corrects it by hand.
• Cost center splits need agreed percentages. If finance thinks in fixed amounts per entity, translate those into percentages before go-live and write the rule down.
• Line-level splits multiply the work. An invoice with 40 lines split across three entities is 120 allocation values to check, so keep line-level splits for the matters that genuinely need them.

Allocation is where most multi-entity departments discover conversion problems first, usually on the first foreign invoice that needs splitting.

How should rounding be handled in currency conversion?

Rounding in currency conversion should follow one documented rule for precision and one for where the rounding happens. Without both, converted line totals drift from the converted invoice total by a few cents, and finance flags every one.

• Precision. Two decimal places for most currencies, zero for currencies such as JPY that have no minor unit.
• Rounding point. Round each line and accept a small difference at invoice level, or convert the total and accept small line differences. Pick one.
• Tolerance. An approved tolerance (for example, 0.01 per line, capped at 1.00 per invoice) lets the platform pass small variances without a manual review.

How do converted amounts reach accounts payable and finance?

Converted amounts reach accounts payable through the integration that sends approved invoices to your ERP, and that integration has to say which amount and which currency it carries. Most departments pay firms in the native currency and report in the system currency, so the payment file usually needs the native amount, the currency code, and the converted amount for the general ledger.

Confirm the field your AP system expects and whether it can pay in the invoice currency. Check too whether accruals on foreign-currency matters are converted in the accrual record and its reports. Tax lines need the same care, so agree the treatment of converted VAT and GST with each country’s finance contact, using the VAT tables that validate tax on the original invoice. Map all of these fields once, as part of integrating ELM with finance and ERP systems.

How do you test currency conversion before go-live?

You test currency conversion before go-live by running real past invoices in every live currency through the configured platform and recalculating each converted figure by hand. A set of 50 to 100 invoices across all currencies usually covers the cases that break.

• One invoice per currency. Prove the rate, the date that selected it, and the stored converted amount.
• Edge cases. Include a JPY invoice, an invoice spanning a month end, a split allocation, and a credit note.
• Independent expected results. Build every expected figure in a separate calculation before testing starts, so the platform is never checking itself.

Repeat the checks after promotion to production, since rate-source settings are easy to miss.

How do you report legal spend across currencies?

You report legal spend across currencies by presenting everything in the system currency while keeping the native currency one column away. Budget and forecast reports that show values in the system currency after conversion make year-over-year and firm-to-firm comparison possible. Watch exchange-rate movement when you read trends. A 10 percent rise in USD spend with a UK firm can be entirely the pound strengthening, with hours and rates flat. Show native-currency trends next to converted ones for your top international firms, and report rate-missing, stale-rate, and allocation exceptions monthly. These views belong on the legal spend dashboards your department already tracks.

Conclusion

Multi-currency invoicing works when the conversion is predictable, documented, and traceable. Choose one date basis, store the native amount alongside the rate and converted figure, settle the allocation and rounding rules with finance, and confirm what the AP integration carries. Test every live currency against independent calculations before go-live. Once those decisions are made, the platform handles the arithmetic, and your quarter-end reconciliation becomes a routine check.

Frequently asked questions

What is multi-currency invoicing?

Multi-currency invoicing is the handling of invoices submitted in a currency other than the organization’s system currency, with each amount converted for budgets and reporting. The original native amount is kept alongside the converted figure.

Which exchange rate does Onit Unity use?

Onit Unity converts currency with Open Exchange Rates data loaded nightly. Each invoice is stamped with the most recent rate when the vendor submits it, and that rate does not change afterward.

Should invoices convert at the worked date or the submission date?

Either date works if the choice is documented and applied consistently. The worked date is more precise line by line, and the submission date gives one rate per invoice that is simpler for finance to reconcile.

How should a foreign-currency invoice be allocated?

A foreign-currency invoice is safest to allocate by percentage, since fixed amounts stop adding up once the total is converted. The percentages must total exactly 100, so check whether your platform rebalances them.

Do accruals need special handling for foreign currencies?

Accruals on foreign-currency matters need explicit handling, because accrual records and reports may hold the native currency. Confirm the behavior in your platform and agree the treatment with finance.

How many invoices should be used to test currency conversion?

A test set of 50 to 100 past invoices across every live currency usually covers the cases that break. Include no-decimal currencies, month-end spans, split allocations, and credit notes.

---

*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*