.png)
Multi-Currency Without the Manual Corrections
FX rates arrive automatically, corrected to your own buy and sell positions. Guardrails catch a rate that’s drifted too far from the market before it posts. And when a payment settles at a different rate than the invoice, the gain or loss is recorded on its own, without anyone calculating it.
Invoice, cost and settle in any currency, with the rates handled for you
.avif)
A currency field isn’t the hard part. Sourcing the rate, applying your own correction, catching an error before it posts, and recording FX where it belongs. That’s where the work actually sits.
.png)
Multi-currency support usually means a field you can type a rate into. The rate still has to come from somewhere, your buy and sell positions still have to be applied, someone still has to notice when a figure is wrong, and the FX consequence still has to be worked out when the payment eventually lands. Shipthis takes all four off a person. Rates are fetched and corrected to your positions, validated against the live market before they save, and any FX difference on settlement posts itself to the right account.
.avif)
.avif)
Fixed Additions, Percentage Fallbacks, or a Locked Pair Rate
Market rates fetched for every currency you trade in, with separate buy and sell corrections held per currency and a percentage fallback where no specific correction is set.
Rates come in automatically for every currency you’ve configured. On top of that, you hold your own buy-side and sell-side corrections per currency, either a fixed addition to the market rate, or a percentage markup that applies wherever no specific correction has been set.
Where a contractual or board-approved rate needs to apply to a specific pair regardless of the market, that can be fixed at the pair level for a region rather than re-keyed on every document.
Tolerance You Set, Enforced Before It Saves
A rate that deviates too far from the live market is blocked, and same-currency or different-currency mismatches are refused outright.
Every rate is checked before it saves. If it drifts beyond your configured tolerance from the current market rate, the document won’t post. You set that tolerance per region, tighter for stable corridors, looser where volatility is genuine.
The obvious errors are refused too: a same-currency document that isn’t at parity, a cross-currency document that is, or any rate at zero. None of them reach the ledger to be found later.
Realised and Unrealised Gains, Never Conflated
When a payment settles at a rate different from the original booking, the realised gain or loss posts automatically to its own account.
Currencies move between invoicing and settlement, and that movement is a real gain or loss the moment the payment is approved. Shipthis calculates it against the original booking rate and posts it to dedicated FX gain and loss accounts without anyone working it out.
Outstanding balances still carrying exposure at period end are handled separately through revaluation, so realised and unrealised movements stay distinguishable.
Paid in One Currency, Banked in Another, Reported in a Third
Two distinct FX movements, the payment against the invoice and the bank’s own conversion, recorded separately rather than netted into one.
The straightforward case is one FX movement: payment rate against invoice rate. But when the currency a customer pays in isn’t the currency of the account it lands in, there’s a second, genuinely separate movement: what the bank actually converted at.
Netting the two together hides both. Shipthis records them as distinct legs, so the receivable movement and the bank conversion each stay visible and attributable. The bank ledger reflects what actually reached the account, not an approximation of it.
Each Region in Its Own Currency. The Group in One.
Regional balances restate into your group reporting currency at close, with the choice between current-rate translation to an equity reserve or temporal remeasurement through P&L.
Regions keep their books in their own currency; the group presents in one. That restatement runs as its own step at period close, distinct from ordinary FX revaluation. The two answer different accounting questions and can both apply in the same close.
Which treatment applies is your policy, set per region: current-rate translation with the difference to an equity reserve, or temporal remeasurement with the difference through P&L.
.png)
Supporting Multiple Currencies Is Common. Handling Them Is Not.
Rates sourced and corrected to your positions, bad rates refused at entry, FX posted on settlement, three-currency legs kept separate, and group consolidation as its own step.
.png)
Ask a system where the rate comes from, who applies your spread, what happens when someone mistypes, and how it handles a payment banked in a currency neither the invoice nor the books are in. The answers separate a currency field from actual currency handling.
Shipthis was built for the answers to be automatic, which matters most on the cases that are easy to get quietly wrong.
Base Currencies First, Transactions After
A dedicated implementation team sets up your currencies, rate rules and precision before go-live, so every rate is right from your first invoice.
Your regional base currencies drive all reporting and are best fixed before any financial data is entered, since changing one later is involved. Rate precision is also worth a moment: the default suits most currencies, but low-denomination ones need more decimal places to avoid truncating real value.
Implementation configures your currencies, correction positions, deviation tolerances and precision against how you actually trade, and sets the group reporting treatment with your finance team before your first multi-region close. Most customers are fully operational within 9 weeks.
Bring Your Messiest Currency Combination
Invoiced in one, paid in another, banked in a third, reported in a fourth. We’ll walk through what posts, and where.
The fastest way to judge currency handling is against a combination you’ve had trouble explaining before. Prefer to explore first? A free 30-day trial gives your team hands-on access with no commitment.
No credit card required. Implementation team maps your workflow before go-live.
Multi-Currency Billing Questions, Answered
They’re fetched automatically for every currency you’ve configured, then adjusted by your own buy and sell corrections before use.
Yes. Hold a fixed correction or a percentage markup per currency, or lock a specific pair rate for a region where a contractual rate applies.
A deviation tolerance you set per region blocks rates that have drifted too far from the live market, and structurally invalid rates are refused outright.
Yes. When a payment settles at a rate different from the original booking, the realised gain or loss posts automatically to its own account.
That’s treated as two separate FX movements, the payment against the invoice and the bank’s own conversion, recorded as distinct legs rather than netted together.
Regional balances restate into your group reporting currency as a separate step at close, using either current-rate translation or temporal remeasurement, set per region.
Yes, per region. The default works for most currencies, and more decimal places are available where truncation would lose real value.
