Skip to main content
← All posts

Approve the Euros, Not a Guess: Foreign-Currency Purchases in Slack

October 6, 2026 · BuyFlow Team

A designer asks in Slack to renew a font license from a studio in Berlin. The quote says €4,800. The approver reads it, decides it's "about five grand," and approves. Three weeks later the bill shows up in the ledger at one dollar figure, the payment leaves the bank at another, and the card statement or wire confirmation shows a third. Nobody did anything wrong. But nobody approved a number that matches what the business actually paid.

Foreign-currency purchases are where a simple Slack approval quietly stops lining up with the books. This post covers what to capture on the request when the vendor doesn't bill in your home currency, how QuickBooks Online and Xero will treat the transaction afterward, and why the payment method changes where the exchange cost shows up.

The approved amount and the paid amount are different numbers

Once a purchase is priced in another currency, there are at least two dates that matter: the day the bill is recorded and the day it is paid. Exchange rates move between them.

Xero's own guide to multi-currency accounting works through exactly this case. A €5,000 invoice is recorded at one rate; if the GBP/EUR rate has moved to 1.15 by the time it is paid, the business pays £4,347.83, which is £74.33 more than originally recorded. That £74.33 is a realised foreign exchange loss (Xero UK). If the bill is still unpaid at the reporting date, the open balance gets revalued and the difference shows up as an unrealised gain or loss instead (same source).

Add a third number: the approver's mental conversion at request time, which might not match either of those dates. For a small purchase, the gap is noise. For a contractor retainer, a software contract, or equipment from an overseas supplier, it is the difference between "within budget" and "over threshold."

What to capture on the Slack request

The fix is not to make approvers do FX math. It is to make the request carry enough information that the approval means something specific.

1. The amount in the vendor's currency, exactly as quoted. €4,800, not "~$5k." This is the number that will appear on the vendor's invoice, and it is the number finance will key into the bill. If the request only stores a converted estimate, nobody can later tell whether the bill matches what was approved.

2. A home-currency estimate, with the rate and the date it came from. The approver still needs a number in your currency to judge it against budget and approval thresholds. Store the estimate alongside the rate used and when it was pulled, so a later variance can be explained in one line rather than reconstructed.

3. The currency the vendor bills in. This sounds redundant, but it matters for how the vendor is set up in the ledger (more below). A UK vendor might invoice you in USD; a US-based reseller might bill in EUR. Ask, or attach the quote that shows it.

4. How it will be paid. Card, bank transfer in the vendor's currency, or a USD wire the vendor's bank converts. As covered further down, each one puts the exchange cost in a different place.

5. A tolerance for re-approval. Decide up front how much the final home-currency cost can drift from the estimate before it goes back to the approver. Write it as a percentage in your spend policy so it isn't negotiated purchase by purchase. Movements inside the band are accepted as the cost of doing business abroad; anything outside it gets a fresh look, the same way a price change from a domestic vendor would.

Routing should use the home-currency estimate. If your policy says purchases over a certain amount need a second approver, a request that sits just under the line in today's rate can cross it by payment day. A small buffer on foreign-currency requests, or routing them on the estimate plus your tolerance, avoids approving something under one approver's limit and paying it over that limit.

QuickBooks Online: get the vendor's currency right the first time

In QuickBooks Online, multicurrency is a one-way switch. Once it is turned on, it cannot be turned off, because currency conversion information has to be accounted for going forward. Intuit's advice is to turn it on only if you actually have bank accounts, customers, or vendors that don't use your home currency (QuickBooks Multi-currency FAQ). Enabling it also locks your home currency (QuickBooks help).

The detail that bites purchase workflows is at the vendor level. Each QuickBooks vendor gets one currency. After you save a vendor with a currency, you can't change it, and once a vendor has recorded transactions, the only way to start billing them in a different currency is to make the existing profile inactive and add the vendor again with the right currency (QuickBooks help: Add a vendor with a foreign currency). A vendor profile can't hold multiple currencies; the community-recommended workaround is a second, slightly renamed profile per currency (QuickBooks Community).

So if the first bill for a new overseas vendor gets entered under a home-currency vendor record, someone will be creating duplicate vendor profiles later, and vendor-level reporting splits in two. Capturing "vendor bills in EUR" on the Slack request is what lets whoever sets up the vendor pick the right currency before the first transaction exists.

QuickBooks also lets you enter and use your own exchange rates rather than the default ones (QuickBooks help). If your team locks a rate with your bank for a large payment, recording that rate keeps the bill closer to what was approved.

Xero: more flexible per transaction, same timing problem

Xero handles the vendor side more loosely. You can assign a default currency to a contact, and bills and purchase orders will show in that currency, but you can also change the currency on individual transactions (Xero US). Xero supports over 160 currencies, updates exchange rates hourly, and lets you override the rate on any individual invoice, bill, or payment, for example to match a rate from a specific bank transaction (same source).

Two practical notes for Xero teams:

  • Plan level. In the US, multi-currency is available on the Established plan; Early and Growing plans need to change plans to transact in foreign currencies (Xero US). If foreign vendors are starting to show up in Slack requests, check this before the first bill needs entering.
  • Where the difference lands. When a foreign-currency bill is paid, Xero automatically calculates the realised foreign exchange gain or loss by comparing the original transaction-date rate with the payment-date rate (CALTRiX Xero Help Center; Ascentis). The bill's expense line keeps its bill-date value. That means the department's budget line won't absorb the FX movement; it shows up on a separate gains/losses line. That's correct accounting, but it's worth knowing when a budget owner asks why their actuals don't match the bank.

Xero also recommends reviewing unrealised gains and losses before period-end close and using currency revaluation at month end to update the home-currency value of open foreign balances (Xero US). Approved-but-unpaid foreign purchases are exactly the open balances that will move.

The payment method decides where the FX cost hides

The same €4,800 purchase can cost different amounts depending on how it's paid, and the extra cost shows up in different places.

On a card, the conversion happens inside the transaction. Ramp explains that the card network converts the foreign amount using its daily rate, typically on the settlement date one to three business days after purchase, and the transaction posts in USD with all conversion fees included (Ramp). On Ramp cards, that conversion can include a markup not exceeding 3% (same source). Brex applies an FX rate markup of up to 3% on international card transactions that need conversion (Brex support). Because the markup is baked into the posted amount, it lands in whatever expense account the transaction is coded to. No separate FX line, so it's easy to miss.

Ramp's guidance also flags dynamic currency conversion, where a merchant offers to charge you in USD instead of local currency, as something to always decline, citing markups of 5–12% plus fees (Ramp). That's a one-line note worth putting in the approval message for card-paid foreign purchases.

On a bank transfer or wire, the fee structure is different. Brex charges no per-transaction fee on international wires, but notes that non-USD wires use a foreign exchange rate chosen by Brex, and that intermediary and recipient banks may charge their own fees (Brex support). Ramp lists a $20 fee for international SWIFT USD payments through Bill Pay (Ramp). When the bill is entered in the vendor's currency and paid later, the rate movement flows to gains/losses as described above, and any bank fee should be coded separately.

None of this argues for one payment method over another. It argues for knowing the method at approval time, because "€4,800 by card" and "€4,800 by wire next month" are slightly different commitments.

A short checklist

For any Slack purchase request where the vendor doesn't bill in your home currency:

  • Quote amount and currency, copied from the vendor's quote or attached.
  • Home-currency estimate, with the rate and date used.
  • Vendor's billing currency, so the vendor record in QuickBooks or Xero is set up correctly before the first bill.
  • Payment method: card, local-currency transfer, or USD wire.
  • Your re-approval tolerance, applied when the bill or card charge lands.
  • Route on the home-currency estimate plus that tolerance, not on the raw estimate alone.

With those fields on the request, the bill can be checked against what was approved in the vendor's own currency, and the gap in your home currency can be explained without anyone digging through Slack threads.

Sources