Multi-Currency ERP: Lock the Exchange Rate to the Document, Not to Today

Your customer in Hamburg paid exactly what you invoiced. Every cent of it. The order said 48,000 euros, the invoice said 48,000 euros, the wire came in at 48,000 euros.

So why does your reporting show three different dollar figures for the same deal?

The euro is not the culprit here. The multi-currency ERP underneath it is.

This is the quiet tax on selling across borders. Not the currency swings themselves, those are just weather. The real damage comes from software that keeps recalculating the past. You open an order from three weeks ago and it politely converts it at today's rate. The number moves. Nobody touched anything, and the number moved.

Good software should do the opposite. It should remember.

Where the spreadsheet quietly breaks

Most manufacturers start with one currency and a simple rule: sell in dollars, report in dollars, done.

Then a German customer wants to be quoted in euros. A UK buyer wants pounds. Your Japanese distributor works in yen. Suddenly your finance lead is maintaining a tab in a spreadsheet with a column called "rate used" and a lot of hope.

Here is how it goes wrong, in order:

• The quote goes out in euros at whatever rate someone looked up that morning.
• Three weeks later the invoice is raised, and the system grabs a fresh rate. The invoice no longer matches the order.
• The customer pays six weeks after that, at a third rate.
• At month end, someone tries to reconcile the bank against the ledger and finds a gap of a few hundred dollars with no name and no owner.

The gap is real money. It just has no home in your system, so it gets absorbed into "miscellaneous" and quietly forgotten.

Multiply that by every foreign order in a year. That is the cost of a system that treats an exchange rate as a live value instead of a recorded fact.

What a multi-currency ERP should actually do

A rate is not a setting. It is a measurement, taken on a specific day, and it belongs to the document.

Once you accept that, the whole problem collapses. The order captures a rate on the day it is placed. The invoice carries that same rate forward, because it is billing that order. The payment captures its own rate, because that is the day the cash actually landed. And the difference between the invoice rate and the payment rate is not a mystery, it is a number you can name.

Qualis is built on exactly that model. Let me show you the whole thing on a real order.

Step one: pick the currency you think in

Every organization sets one base currency. That is the currency you report in, the one your management accounts are denominated in, the one your bank balance means something in.

Two things worth noticing here.

The base currency locks itself. Once your organization has money-bearing documents in the system, that setting refuses to change. Every stored amount is denominated against it, so switching it later would silently rewrite the meaning of your history. Qualis will not do that to you.

Live rates are a toggle, not a project. Turn on automatic exchange rates, pick daily, weekly or manual, and the rates arrive on their own. If you would rather key rates in by hand, turn it off and the manual path is fully supported.

Step two: the rates arrive, dated

Rates land in a table, one row per currency pair per day, each stamped with where it came from.

That is not decoration. That table is the audit trail. When someone asks in March why an August invoice was converted at that particular number, the answer is a row you can point at, with a date and a source next to it.

Look closely at the euro rows. On August 9 the rate was 1.156036. On August 12 it was 1.153633. Hold on to those two numbers, they are about to matter.

When a document needs a rate, Qualis takes the most recent rate on or before that document's own date. A backdated invoice gets the rate that was true on its issue date, not the rate that is true right now.

Where a document's rate can come from

A document's rate has one of three origins, and Qualis records which one every single time.

• From the rate table. The normal path. The system looks up the dated rate for the document's date.
• Typed in. Someone with rate permissions entered it directly, usually because a contract fixed the rate.
• Inherited. The document copied its rate from the parent document it came from. More on this in a moment, because this is the one that saves you.

Step three: the order remembers

Here is a real sales order for a German aerospace customer, placed on August 9.

Nobody typed "EUR" into that order. The customer record carries a default currency, so the order simply arrives in euros. The rate for August 9 is captured, applied, and stored alongside the total.

Read that bottom line again:

48,000.00 euros. USD 55,489.72. 1 EUR = 1.156036 USD, Aug 9, 2026.

Six facts are now stored on that order: the document currency, the base currency, the rate, the date the rate applies to, where the rate came from, and the converted base amount. That last one matters more than it looks. The dollar figure is stored, not recalculated when you open the page. Which is precisely why it will still say 55,489.72 next March.

While the order is still a quotation you can change your mind, and the rate re-derives. The moment it moves past quotation, the rate is frozen. Trying to change the currency on a posted document is rejected outright rather than quietly accepted.

Step four: the invoice ties to the order

This is the step that most systems get wrong, and it is the step that generates the angriest emails.

You bill the order. A fresh rate gets grabbed. Now the invoice total in your reporting currency does not match the order total in your reporting currency, and neither matches the customer's purchase order. Somebody has to explain the difference to a procurement manager who did not ask for a lesson in foreign exchange.

Qualis does not do that. An invoice raised from a sales order inherits the order's frozen rate.

Same 48,000 euros. Same 55,489.72 dollars. Same rate, same date. The invoice ties to the order to the cent, and the invoice records that its rate was inherited from that specific order, so the link is auditable rather than coincidental.

Once the invoice is finalized, that rate is frozen too. A finalized invoice is a legal document. Its numbers do not get to drift.

The same snapshot rides on purchase orders, credit notes and customer payments, so the behaviour is consistent whether money is coming in or going out.

Step five: the cash lands, and the gap gets a name

Three days later, the wire arrives. Full amount, 48,000 euros, nothing short.

But August 12 is not August 9. The rate that day was 1.153633.

There it is, on the record, with a label: Realized FX gain/loss, -$115.35.

The arithmetic is not complicated, and that is the point:

• Invoiced at 1.156036, so 48,000 euros was worth $55,489.72
• Settled at 1.153633, so the same 48,000 euros arrived as $55,374.37
• The euro drifted, and the difference is $115.35

Your customer paid in full. The invoice balance is zero. Nothing is outstanding, nothing is in dispute. You simply banked 115 dollars and change less than the invoice was worth on the day you raised it, and now that fact has a name, a number and a document it belongs to.

That is the entire difference between a finance team that reconciles in twenty minutes and a finance team that spends a day hunting a rounding ghost.

What locking the exchange rate actually prevents

Put plainly, locking the rate to the document kills a specific family of problems:

• Numbers that change when nobody changed them. Historical orders and invoices report the same base-currency value today, next quarter and next audit.
• Invoices that do not tie to their orders. Copy-forward means the billing document agrees with the commercial document by construction, not by luck.
• Unexplained reconciliation gaps. The difference between invoicing and settlement is calculated, labelled and attached to the payment that caused it.
• Silent conversion at the wrong rate. A foreign-currency document cannot be saved without a complete rate snapshot, so there is no path where an amount gets converted by guesswork.
• Arguments with no evidence. Every rate carries its date and its origin.

And when the rate feed has a bad day, Qualis keeps the rates it already has and tells your administrators rather than inventing a number to keep the screen looking tidy. A missing rate should be loud, not creative.

The whole journey, end to end

One rate is captured at the order and carried to the invoice, so the commercial and billing documents always agree. A second rate is captured when the cash lands. The distance between them is measured, named and recorded.

Three documents. Two rates. Zero mysteries.

Frequently Asked Questions

What is a multi-currency ERP?

It is a system that lets you transact in the currencies your customers and suppliers actually use, while reporting everything in one currency you choose. Orders, invoices and payments each keep their own currency and their own exchange rate, and the system converts to your reporting currency and stores the result.

Why does my ERP show a different value for an old invoice every time I open it?

Because it is converting on read instead of storing the conversion. The system holds the foreign amount and multiplies it by whatever rate it finds at the moment you look. The fix is to store the converted amount and the rate used at the time the document was created, so the figure is a record rather than a live calculation.

Should the invoice use the sales order's exchange rate or a new one?

For the invoice to tie back to the order that generated it, it should inherit the order's rate. That keeps the commercial document and the billing document in agreement, which is what your customer, your auditor and your own reporting all expect. Qualis inherits the source order's rate automatically and records that it did.

What is a realized FX gain or loss?

It is the difference in your reporting currency between what an invoice was worth on the day you raised it and what the cash was worth on the day it settled. The customer pays the invoiced amount in full, but because the rate moved, the amount that lands in your base currency differs. Qualis calculates that figure when a payment is applied and records it on the payment.

Can I set a fixed exchange rate for a specific contract?

Yes. Alongside the automatic dated rates, a user with the right permission can enter the rate directly on the document. The system records that the rate was entered manually rather than pulled from the rate table, so the provenance stays clear.

Can I change my base currency later?

Once your organization has money-bearing documents, no, and that restriction is protecting you. Every stored base-currency amount is denominated against that setting, so changing it would silently reinterpret your entire history. Choose it during setup, before the first order is raised.

The bottom line

Currency movement is not your problem to solve. Currency movement is going to happen whether your ERP is clever or not.

Your problem is knowing. Knowing what a deal was worth when you agreed it. Knowing that the invoice matches the order. Knowing exactly how much the rate moved between billing and banking, and being able to point at the document that says so.

That is what locking the rate to the document buys you: a set of numbers that stop moving on their own, so your finance team can stop chasing them.

If you sell across borders and your month end involves a spreadsheet column called "rate used", see how Qualis handles multi-currency orders and invoices. And if you also buy and sell in different units, the same fail-closed thinking applies to unit of measure conversion, and to deposit invoices when you bill up front.