EXCEPTIONS HANDLED · #13 · Currency & FX
FX Rates, Payment Processor Discrepancies, and Accounting Drift
THE PROBLEM IN PLAIN ENGLISH
You sold something in the UK for £50. The payment processor converted it to $63.40. By the time it posted to QuickBooks, the exchange rate had moved and it recorded $62.85. That’s a fifty-five cent gap on one order. Multiply by your international volume and you’ve got a currency drift that nobody budgeted for.
International selling adds a layer of complexity that most ecommerce accounting systems handle poorly: currency conversion. The exchange rate at the moment of sale, the moment of payment processing, and the moment of accounting entry are all different. Each system — the marketplace, the payment processor, and QB — may use a different rate source, a different rounding method, and a different conversion timestamp. The result is a persistent, small, seemingly random variance on every international transaction that accumulates into a material discrepancy by year-end.
Currency issues hide in plain sight. They look like normal variance until you add them up.
Persistent small variances on international orders
Every order from a foreign currency channel is off by a few cents. Individually insignificant. Collectively, it’s hundreds or thousands of dollars.
FX gain/loss account growing unexpectedly
Your unrealized FX gain/loss account is accumulating faster than your international volume justifies. Conversion rate mismatches are the culprit.
Payment processor payout doesn’t match expected conversion
PayPal or Stripe converted at a different rate than what the marketplace displayed at checkout. The customer paid one amount, you received another.
Multi-currency QB mode causing posting errors
QB multi-currency mode has specific requirements for how foreign transactions are entered. Incorrect setup causes posting failures.
Multi-currency accounting is complex but manageable with discipline.
Choose a single FX rate source
Pick one: marketplace rate, payment processor rate, or QB’s rate. Apply it consistently across all international transactions.
Post in the original currency
If QB supports multi-currency, post the transaction in the customer’s currency. Let QB handle the conversion. This creates an FX gain/loss entry automatically.
Reconcile FX gain/loss monthly
Review the account every month. If it’s growing faster than expected, you have a rate mismatch or a conversion timing issue.
Document your FX policy
Write down which rate source you use, when conversion happens, and how you handle variances. This is critical for audit.
Webgility handles multi-currency posting with configurable rate sources and automatic FX tracking.
Configurable FX rate source
Choose to use the marketplace’s rate, the payment processor’s rate, or a custom rate. Applied consistently to all orders.
Original currency posting
International orders are posted in the original currency with automatic conversion at your chosen rate. QB’s FX gain/loss is generated correctly.
FX variance reporting
See the cumulative impact of currency conversion across all channels and periods. No spreadsheet gymnastics required.
☐ Verify QB multi-currency mode is configured correctly
☐ Choose and document your FX rate source (marketplace, processor, or custom)
☐ Review FX gain/loss account balance for the last quarter
☐ Compare payment processor conversion rates against your posted amounts
☐ Ensure international orders are posted in the original currency, not pre-converted
No. Post in the original currency and let QB handle the conversion. Pre-converting loses the FX trail and makes reconciliation harder.
Either your volume is high enough that normal variance adds up, or you have a systematic rate mismatch between your conversion source and QB’s rates.
VAT should be recorded in the original currency and converted alongside the order. Check with your accountant on VAT recovery and reporting obligations.