Skip to main content
A great deal of apparel work crosses currencies. A customer in Europe is billed in EUR; a fabric mill in Vietnam is paid in USD; the workspace itself reports in TWD. Between the day a foreign-currency is raised and the day it is settled, the exchange rate the workspace pays attention to may have moved. This page describes what happens when it does: the realized foreign-exchange gain or loss that the workspace records, the re-stamp that updates an order’s saved rate when you change the order’s currency, and the base currency every Finance figure ultimately reconciles to. The page is a behavior page — it does not introduce a Finance tab of its own. The realized gain or loss appears as an entry on the finance ledger; the re-stamp updates a field on an order; the base currency is the workspace setting that anchors every multi-currency figure. Each of those records is described in full on its own page; this page is the canonical place that ties the three together.

​
What realized foreign-exchange gain or loss is

A realized foreign-exchange gain or loss is the difference between the exchange rate in effect when a foreign-currency entry is first recorded on the finance ledger and the rate in effect when the payment that settles it is recorded — translated into the workspace’s base currency. It is realized because the rate movement is only recognised when money actually changes hands — when a customer receipt is recorded against a foreign-currency customer invoice, or when an approved vendor payment is released against a foreign-currency vendor invoice. The workspace does not mark open balances to a current rate at month-end; rate movement against an invoice that has not yet been paid is not recorded. A gain arises when the rate movement works in the workspace’s favour: a customer invoice in USD whose rate has risen since the invoice was raised brings in more of the base currency than the original charge was booked at, and the difference is a gain. A loss arises when the rate movement works against it: a vendor payment in USD whose rate has risen costs more of the base currency than the original charge was booked at, and the difference is a loss. The two cases are mirror images, on opposite sides of the ledger, and both are recognised the same way.

​
When it arises

Every realized foreign-exchange entry on the ledger comes from one of two business events:
  • A customer receipt against a foreign-currency invoice. When the team records a receipt on the Receivables board and the receipt’s payment date carries a different rate from the rate the invoice was booked at, the rate movement is recognised at the same save. The receipt itself posts on the receivables side in the invoice’s own currency; the gain or loss posts as its own entry on the foreign-exchange side in the workspace’s base currency.
  • An approved vendor payment against a foreign-currency vendor invoice. When a vendor payment a colleague submitted is approved on the Payables board and released, and the payment’s date carries a different rate from the rate the vendor invoice was booked at, the rate movement is recognised at the same save. The payment posts on the payables side in the invoice’s currency; the gain or loss posts on the foreign-exchange side in the base currency. Until the checker approves the payment, neither the payments-side entry nor the foreign-exchange entry exists. See Maker-checker approvals.
Two everyday cases produce no foreign-exchange entry, by design:
  • Same-rate settlement. A foreign-currency invoice paid on a date whose rate matches the rate at issue posts the receipt or payment without a foreign-exchange entry. There is nothing to recognise.
  • Same-currency settlement. A receipt or payment in the same currency as the invoice it settles — including a base-currency invoice paid in the base currency — has no rate to compare against. No foreign-exchange entry posts.

​
How it posts to the ledger

A realized gain or loss is one entry on the foreign-exchange side of the finance ledger — the third side the ledger recognises alongside receivables and payables — recorded in the workspace’s base currency. The entry carries the same facts every ledger entry carries: the side, the direction, the amount, the date the movement happened, who recorded it, and the link back to the customer or vendor invoice and the receipt or payment that produced it. A gain raises the foreign-exchange balance for the period; a loss reduces it. The original receivables or payables entry is left alone in the invoice’s own currency — the foreign-exchange entry is the third record that captures the rate movement, distinct from the two it sits between. Two consequences follow from the entry living on its own side:
  • The customer or vendor balance is unaffected by the rate. A customer who owes a USD invoice still owes exactly the USD amount on the invoice, no more and no less. The Receivables and Payables boards never blend a rate movement into a counterparty’s outstanding balance.
  • The reporting view of the rate movement is in one place. Every realized gain or loss the workspace has recorded sits on the foreign-exchange side, in the base currency, and is read off the ledger the same way every other balance is read.
A foreign-exchange entry is permanent the moment it is recorded, on the same rule that governs every ledger entry. When the receipt or payment that produced the entry is later unwound — a receipt un-applied, a vendor payment voided — the foreign-exchange entry is reversed by a fresh entry of the opposite direction, linked back to the entry it cancels. Both stay on the ledger; the foreign-exchange balance reads the same as it would have had the original entry never been recorded, but the trail of what was recorded and what was later reversed reads in full. See the finance ledger for the rule.

​
Changing an order’s currency: the FX-rate re-stamp

Every order carries an FX rate field — the exchange rate captured from the FX Rates page at create, against the order’s Order date, and saved on the order from that moment on. The rule that an FX Rates update afterwards does not rewrite the rate saved on the order is what keeps the order’s reporting figures stable. See Order: FX rate field. There is one case where the platform does rewrite the order’s saved rate: when you change the order’s currency itself. An order opened in TWD that you switch to USD is no longer in the same money — the rate the order should carry is no longer the saved TWD rate, but the USD rate for the order’s date. The platform re-stamps the FX rate field at the same save:
  • The new rate is read from the FX Rates page against the order’s Order date (or today, when no order date is set), using the same lookup the order’s original create used.
  • The saved rate on the order is replaced with the new rate; the order’s reporting math from that moment on uses the new rate.
  • The currency change itself, and the new rate, are recorded on the order’s history.
A currency change is rejected when no rate exists on FX Rates for the new currency on the order’s Order date. The save reports “no exchange rate found for this currency and date” and nothing changes; you enter the rate on FX Rates and try the currency change again. The re-stamp is the only exception to the order’s captured-at-create rule. A non-currency edit — changing the customer, the season, the deposit percentage, a style line — does not re-read the rate; the order keeps the rate that was on it before the edit.

​
The base currency

Every workspace has one base currency — the reporting currency that every multi-currency figure ultimately reconciles to. The base currency is set up by the GarmentFlow team when the workspace is provisioned and shown read-only on Workspace settings → Company info; it is not changeable from the workspace. The base currency is where the workspace anchors three Finance behaviours:
  • The FX Rates page is expressed against it. A saved rate of 32.50 for USD means one US dollar converts to 32.50 of the base currency. See FX Rates.
  • The ledger’s base-currency equivalents are computed against it. Every ledger entry carries the amount in the document’s own currency and the equivalent in the base currency, at the rate in effect on the entry’s date. The base-currency view is how a foreign-currency receivable can be read alongside the workspace’s own money without re-keying.
  • Realized foreign-exchange gains and losses are recorded in it. The entry on the foreign-exchange side is always in the base currency; the workspace’s realized foreign-exchange result rolls up in one money.
The base currency does not authorise the platform to blend currencies on a counterparty balance. A customer billed in USD and again in EUR carries two outstanding figures, not a blended one. The Receivables and Payables boards read every figure in its own currency; the base-currency column sits alongside as a second view, never replacing the original. The same rule applies to the order’s payment-progress view: an order whose total is in one currency and whose receipts arrived in another shows them separately, without conversion.

​
Where you see it

You do not open a foreign-exchange screen of its own — the realized gain or loss lives on the finance ledger and surfaces in everything that reads the ledger:
  • The Receivables and Payables boards. Both boards carry an outstanding column in the base currency alongside the document-currency column, and neither folds the foreign-exchange side into the counterparty balance. See Receivables and Payables.
  • Customer invoices and vendor invoices. Each carries the base-currency equivalent at the rate in effect on the invoice’s date, saved on the ledger entry the invoice produced. See Invoices.
  • The Reports tab. The receivables and payables detail reports, the customer Statement of Account, and the workspace’s expense and AP reports read off the ledger, and surface the realized foreign-exchange figures alongside the receivables and payables figures.
The order’s FX rate field — including a value that was re-stamped after a currency change — is the rate the order’s own reporting math reads. The order’s Payment Summary card carries it; see Order: FX rate field.