VibeWeek
Home/Grow/Currency & FX Handling: Multi-Currency Pricing, Exchange Rates, Settlement, and Reporting Without Drift

Currency & FX Handling: Multi-Currency Pricing, Exchange Rates, Settlement, and Reporting Without Drift

⬅️ Day 6: Grow Overview

If you're running a SaaS in 2026 selling outside a single country, currency handling stops being optional somewhere between the first international customer and the first finance team complaint. Most founders default to "USD-only on the pricing page" indefinitely, then panic-add Euro pricing when an EU customer asks, then realize three months later that revenue numbers in their dashboard don't match what's in Stripe, the bank, or QuickBooks — because nobody decided which exchange rate matters when.

A working currency / FX system has clear answers to: which currencies do we accept, what rate do we use to convert at checkout, what rate do we use for revenue reporting, where does FX gain/loss live, and how do we display localized prices without making refunds and renewals into a nightmare. Done well, multi-currency feels invisible to the customer and clean to finance. Done badly, you're explaining to your CFO why ARR went up 8% last month when the underlying business didn't actually grow.

This guide is the implementation playbook for shipping a currency-aware billing system that's honest about FX risk, plays well with Stripe / Paddle / Polar, and won't make finance hate you in twelve months.

Decide Which Currencies You Actually Need

Multi-currency is not free. Every currency adds checkout-flow complexity, refund edge cases, reporting overhead, and FX gain/loss accounting. Don't add currencies for vanity.

Help me decide which currencies to support.

Three buyer-experience tiers:

**Tier 1: USD-only with foreign cards (the 70% case for indie SaaS)**

You charge in USD; foreign customers pay in USD; their card issuer converts at their rate.

Pros:
- Zero FX risk for you
- Simplest accounting (every dollar is a USD dollar)
- One pricing page; one set of revenue reporting
- No Stripe currency-conversion fees on your side
- No multi-currency refund edge cases

Cons:
- Customers see foreign-exchange fees on their statement (psychological friction)
- Some procurement teams refuse non-local pricing
- Pricing-page perception (a German B2B prospect sees "$49/mo" and mentally converts to ~€45 with awkward fractions)

Pick when: <30% of revenue from outside USD; you''re not enterprise sales-led.

**Tier 2: Local-currency display, USD settlement (the 20% case)**

You display localized prices on the pricing page; customer pays in their currency at checkout; Stripe / Paddle settles you in USD.

Pros:
- Customer sees clean local pricing (€49, £45, ¥6500)
- You still report in USD
- Stripe handles the FX conversion (~1% fee)
- Only modest accounting complexity

Cons:
- Stripe / Paddle take ~1% on FX
- Pricing differs across currencies (you must price each)
- Annual renewals at fixed local price = your USD revenue varies if FX moves
- Refund must match original currency

Pick when: 30%+ revenue international; you want a local-feeling experience.

**Tier 3: Local-currency display + local-currency settlement (the 10% case)**

Customer pays in EUR; you receive EUR in a EUR bank account; you report by currency.

Pros:
- Zero FX cost on collection
- True local presence (often a tax/marketing necessity)
- Cleaner relationships with EU / UK customers

Cons:
- You bear FX risk between collection and home-currency conversion
- Need multi-currency bank accounts (Mercury / Wise / Stripe Treasury)
- Multi-currency accounting (QuickBooks / Xero multi-currency mode)
- Significantly more finance ops complexity

Pick when: $1M+ ARR; structural international presence; finance team can handle it.

For my company today:
- Total revenue
- % from each currency-zone
- Sales motion (self-serve / sales-led)
- Finance team (founder-only / accountant / CFO)

Output:
1. Which tier you should be on
2. The currencies to support (3-5 max for tier 2/3)
3. The trigger for moving up a tier
4. The current pricing-display strategy

The biggest unforced error: adding 8 currencies before you have customers in 6 of them. Every additional currency is overhead that compounds. Start with USD; add EUR + GBP when you actually have demand; add CAD/AUD/JPY only when you have material revenue from those zones. The pricing page can have a currency switcher that lazy-converts at request-time using a market rate API; full local-currency settlement is a separate, much heavier decision.

Exchange-Rate Sources and the "Which Rate" Question

There is no single "the exchange rate." There are multiple rates, all valid for different purposes. Pick deliberately.

Help me pick exchange-rate sources for my system.

The four rates that matter:

**1. Display rate (pricing-page)**

The rate you use to show "$49/mo ≈ €45/mo" on the marketing site.

- Refresh: daily or weekly
- Source: any free FX API (exchangerate.host, openexchangerates.org free tier)
- Why daily: avoid rate-of-the-second flicker; customer-perceived stability
- Round to clean numbers (€45 not €44.78)

**2. Checkout rate (transaction)**

The rate at which money actually changes hands.

- This is set by your payment processor (Stripe / Paddle / Lemon Squeezy)
- Stripe Currency Conversion: charged at Stripe''s daily mid-market + 1%
- Paddle: handled internally; ~1.5-2% spread
- You don''t really pick this; you accept the processor''s rate

**3. Reporting rate (revenue / ARR)**

The rate at which you report revenue in your home currency.

Two valid approaches:
- **Settlement rate**: USD revenue = whatever Stripe deposited in USD (after their FX conversion). Cleanest; matches the bank.
- **Booking rate**: USD revenue = invoice amount in foreign currency × month-end mid-market rate. Useful for ARR consistency across cohorts.

For most indie SaaS: use settlement rate (matches bank; auditable; no manual FX math).

**4. Accounting rate (GAAP / IFRS)**

For statutory accounting, you typically book transactions at the rate on transaction date, then revalue balances at period-end at month-end rate. The difference is FX gain/loss.

This is your accountant''s problem; just be sure the data you feed them is timestamped accurately.

**FX API providers (for display rates)**:

| Provider | Free Tier | Paid Starter | Notes |
|---|---|---|---|
| exchangerate.host | Free | $9/mo | Open data; rate-limited |
| openexchangerates.org | Free (1K/mo) | $12/mo | Solid; ECB + bank averages |
| Currencylayer | Free (100/mo) | $14/mo | Good API |
| Fixer.io | Free (250/mo) | $14/mo | ECB-based |
| ExchangeRate-API | Free (1.5K/mo) | $10/mo | Good free tier |
| OANDA / XE | Custom | $$$$$ | Enterprise / banking-grade |

For most SaaS: free tier of exchangerate.host or ExchangeRate-API is fine for display purposes. Cache for 24 hours.

For my system:
- Which display rate source
- Which payment-processor handles checkout rate
- Which approach for reporting (settlement vs booking)
- Cadence for refresh

Output:
1. The four rate decisions
2. The data flow (where each rate is fetched / stored)
3. The cache TTL per source
4. The reconciliation plan (how often we check that displayed ≈ charged)

The biggest single-source confusion: using ECB rates for display but Stripe rates for charging — and being surprised when the customer is upset. If your pricing page says "≈ €45" and Stripe charges €46.10 because Stripe''s rate differs, the gap is small but visible. The fix: either show clean local prices that you''ve fixed (€45 hard-coded; you absorb the FX delta), OR show a "≈" qualifier with a tooltip explaining "final amount depends on your card issuer / processor." Don''t pretend the displayed rate IS the charged rate.

Pricing-Page Strategies

How you display prices depends on the tier you picked. Get the UX right; minimize confusion.

Help me design the pricing-page currency UX.

Three patterns:

**Pattern A: Single currency (USD) with implicit conversion**

- Pricing page shows: "$49/mo"
- No currency switcher
- Foreign customers convert mentally
- Stripe charges $49 USD; their bank converts

When to use: Tier 1; <30% foreign revenue; B2B technical buyer; want simplicity.

**Pattern B: Currency switcher with display-only conversion**

- Pricing page shows: "$49/mo" or "€45/mo" or "£39/mo"
- Switcher lets visitor toggle
- Conversion shown is illustrative; actual charge in USD
- Footnote: "Charged in USD; your bank may add FX fees"

When to use: Tier 1 with international visibility; you want to feel local but settle in USD.

**Pattern C: Multi-currency pricing (different prices per currency)**

- Pricing page detects locale via IP / Accept-Language
- Shows local price in local currency: €49/mo (separate from USD $49)
- Charged in local currency; Stripe settles in chosen currency
- You set each price independently (€49 might be $54 USD-equivalent at current rates)

When to use: Tier 2/3; revenue justifies the per-currency pricing; you''re willing to manage rate drift.

**The "psychological pricing" trap**:

In Pattern C, $49 USD ≠ €49 EUR. They''re different products with different price points. Common mistake: founders set €49 thinking "same price" — but at $1.07/€, €49 = $52. Now you''re charging EU customers more than US customers. Either:

- Price slightly below for parity: €45 (~$48)
- Price slightly above accepting localization premium: €49 (~$52)

Just be deliberate.

**Annual-plan currency handling**:

If a customer signs up for $588/yr (12 × $49) in January, do they renew in January next year at $588 or at the new local price? Common patterns:

- **Lock the price**: They renew at $588 (legacy price); good for retention
- **Roll to current**: They renew at current pricing; cleaner finance but customer might churn
- **Grandfather X cycles**: Lock for 1 year, then move to current

Pick one and document it.

**The IP-based localization caveat**:

Detecting locale via IP is unreliable (VPNs, travel, multi-region offices). Always allow manual override via a switcher. Never lock the customer into a currency they can''t change.

For my pricing page:
- The pattern (A / B / C)
- The currencies displayed
- The annual-plan policy
- The locale-detection strategy
- The switcher UI

Output:
1. The pricing-page UX
2. The price-per-currency table
3. The renewal policy
4. The "trust me; my system handles this correctly" verification plan

The biggest pricing-page mistake: silent IP-based locale switching with no manual override. A user in London on a US-based VPN gets $49 USD when they expected £39 GBP, or vice versa. Always show the detected currency in the UI prominently, and let them switch in one click. Trust > magic.

Database and Data Model for Multi-Currency

How you store amounts determines whether reporting will be sane in 18 months.

Help me design the multi-currency data model.

The core principle: **store both the amount AND the currency**, always. Never store currency in a different column "implicit by region" — explicit is non-negotiable.

**Schema patterns**:

```sql
CREATE TABLE invoices (
  id UUID PRIMARY KEY,
  customer_id UUID NOT NULL,

  -- Original transaction (what the customer was charged)
  amount_charged BIGINT NOT NULL,           -- in cents
  currency_charged CHAR(3) NOT NULL,        -- ISO 4217: USD, EUR, GBP

  -- Reporting (what we report in home currency)
  amount_home_currency BIGINT NOT NULL,     -- in home-cents (USD cents)
  currency_home CHAR(3) NOT NULL DEFAULT 'USD',
  fx_rate_used NUMERIC(18, 8) NOT NULL,
  fx_rate_source VARCHAR(50),               -- 'stripe_settlement', 'ecb_2026_04_30', etc.
  fx_rate_at TIMESTAMPTZ NOT NULL,

  -- Settlement (what hit the bank in home currency)
  amount_settled BIGINT,                    -- after Stripe FX conversion
  currency_settled CHAR(3) DEFAULT 'USD',
  settled_at TIMESTAMPTZ,

  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE fx_rates (
  source VARCHAR(50) NOT NULL,              -- 'ecb', 'stripe', 'manual'
  base_currency CHAR(3) NOT NULL,           -- USD
  quote_currency CHAR(3) NOT NULL,          -- EUR
  rate NUMERIC(18, 8) NOT NULL,             -- 1 USD = 0.92345678 EUR
  rate_date DATE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now(),
  PRIMARY KEY (source, base_currency, quote_currency, rate_date)
);

Always store:

  • Amount in the original currency
  • The currency code (ISO 4217)
  • The FX rate used (if converted)
  • The rate source + date
  • The home-currency amount derived from above

Never do:

  • Store amounts as floating-point (use integer cents always; floats lose precision)
  • Implicitly convert at read-time (you''ll get different answers as rates change)
  • Use a "USD-equivalent" column without recording the rate (un-auditable)
  • Mix currencies in the same total (a SUM(amount) across currencies is meaningless)

The Money value object:

In application code, wrap amounts in a Money type that carries currency:

class Money {
  constructor(
    public readonly amountCents: number,
    public readonly currency: string  // 'USD', 'EUR', etc.
  ) {}

  add(other: Money): Money {
    if (other.currency !== this.currency) {
      throw new Error(`Cannot add ${this.currency} and ${other.currency}`);
    }
    return new Money(this.amountCents + other.amountCents, this.currency);
  }

  convert(rate: number, targetCurrency: string): Money {
    return new Money(Math.round(this.amountCents * rate), targetCurrency);
  }
}

This prevents silent bugs: subtotal + tax blows up if currencies don''t match, instead of producing a nonsense number.

The "subscription has a fixed currency" rule:

A given subscription / invoice / payment is in ONE currency, always. Don''t mix. If a customer wants to change currency, that''s a new subscription (not a mid-cycle switch).

For my schema:

  • The amount + currency columns
  • The FX-rate table
  • The Money value object in code
  • The migration plan if currently single-currency

Output:

  1. The schema migration
  2. The Money value-object code
  3. The rules (never mix currencies in totals, etc.)
  4. The data validation (CI / tests)

The biggest data-model mistake: **storing one "amount in USD" column and a separate "original currency" column, but not the rate that was used.** Six months later, the rate has drifted; you can''t reproduce the original calculation; auditing is impossible. Store the rate explicitly with every converted amount. It''s 8 bytes per row; storage is free; truth is priceless.

## FX Risk and How Much to Care

If you accept multiple currencies, you have FX risk. Quantify it; manage it; don''t pretend it doesn''t exist.

Help me quantify and manage FX risk.

The risk:

Settlement-timing risk:

Customer pays €100 on Day 1. You receive €100 in EUR account on Day 2 (or USD-converted at Day 2 rate). EUR/USD moves 0.5% in that day. Your USD revenue is $0.55 different than it would have been at Day 1 rate.

Per transaction: small. Per quarter: adds up.

Pricing-cycle risk:

You set EU pricing at €49 (target $54 USD-equivalent at $1.10/€). Six months later, EUR/USD is $1.05. You''re now collecting $51 USD per EU subscription instead of $54. ARR didn''t grow; FX moved.

This is the bigger risk for SaaS.

ARR-reporting risk:

If you report ARR using current-rate revaluation, ARR fluctuates with FX even when underlying business is stable. Boards interpret this wrong; investors calibrate on noise.

Quantification:

Calculate quarterly:

  • % revenue in non-home currency
  • Average FX move during the quarter
  • Estimated FX impact on revenue: % foreign × % move

If <2% of revenue moves due to FX in a quarter: not material; don''t over-engineer.

If >5%: hedging or pricing-policy is justified.

Mitigations (in order of complexity):

  1. Stick to home currency (Tier 1 strategy)

    • Zero FX risk on settlement
    • Customer bears the conversion cost
    • Most indie SaaS at <$5M ARR

  2. Periodic price-list revalidation

    • Once or twice a year, review local-currency prices
    • Adjust if rate has drifted >5%
    • Explicit vs. invisible drift

  3. Banking with multi-currency support

    • Hold EUR / GBP balances; pay EU bills in EUR
    • Reduces conversion churn
    • Mercury / Wise / Stripe Treasury

  4. Forward contracts (large companies)

    • Lock in FX rate for next 6 months on expected EUR inflows
    • Bank does the hedging
    • Justified at $20M+ ARR

  5. Constant-currency reporting

    • Report ARR using a fixed reference rate (e.g., year-start rate)
    • Removes FX noise from internal metrics
    • Common at growth-stage / public companies

For most indie SaaS:

  • Tier 1 (USD-only): no FX management needed.
  • Tier 2 (display / local checkout / USD settle): occasional price review; nothing else.
  • Tier 3 (multi-currency settlement): multi-currency bank account; quarterly price review; constant-currency reporting if board cares.

Don''t:

  • Hedge FX as an indie SaaS (overhead > benefit)
  • Ignore drift (review prices annually minimum)
  • Report ARR fluctuations as growth/decline without an FX disclaimer

For my company:

  • Current FX exposure (% revenue per currency)
  • Quarterly FX-impact estimate
  • Whether the impact is material
  • The mitigation tier appropriate for my size

Output:

  1. The FX exposure today
  2. The quarterly impact estimate
  3. The mitigation choice
  4. The pricing-review cadence

The biggest FX-risk mistake: **adding hedging / forward contracts at $500K ARR.** It''s overhead that drains founder attention without material benefit. The right answer at small scale: stick to USD pricing or let the FX delta run as an accepted variance. Time spent on hedging at $500K ARR could be spent on product. At $20M+ with material EUR exposure, revisit.

## Refunds, Renewals, and Currency Edge Cases

Multi-currency operations create edge cases that single-currency setups don''t. Handle them explicitly.

Help me handle the multi-currency edge cases.

Edge case 1: Refunds in original currency

Customer paid €49; you must refund €49 (not the USD-equivalent).

  • Stripe enforces this — refund happens in transaction currency
  • Your USD-equivalent on refund day differs from charge day
  • Net P&L impact: a small FX gain / loss
  • Don''t try to "be fair" by refunding USD-equivalent — it''s not how processors work

Edge case 2: Partial refunds with FX

Original charge €100; charged → settled $107 USD; refund €50 → settled $54 USD (rate changed). Customer is whole (€50 returned); your revenue is $107 - $54 = $53 (not $50 USD-half). This is correct accounting; your books reflect the actual cash flow.

Edge case 3: Annual renewal with rate drift

Customer signed up for €588/yr in 2025; renews €588/yr in 2026.

  • 2025 rate: $1.10/€ → $647 USD revenue
  • 2026 rate: $1.05/€ → $617 USD revenue
  • ARR appears to drop $30 even though customer didn''t leave

Solution: report ARR in transaction currency or at fixed reference rate; disclose FX impact separately.

Edge case 4: Currency switch on renewal

Customer was charged in USD; now wants to switch to EUR for tax reasons. Pattern: end the USD subscription; start a new EUR subscription with prorated discount. Don''t try to convert mid-cycle.

Edge case 5: Disputes / chargebacks

Chargeback hits in transaction currency. Your bank account loses that amount in the settlement currency. The chargeback fee may be in a third currency (Stripe charges $15 USD for a EUR dispute). Audit trail: log all three currencies in the dispute record.

Edge case 6: Pricing-tier upgrade across currencies

Customer on $49 USD plan upgrades to "$199 plan" — but they''re in EU and your EU pricing is €189. Either: charge them USD $199 (jarring switch from EUR) or €189 (consistent local). Pick local consistency; document the policy.

Edge case 7: Tax + currency interaction

EU VAT is calculated in local currency; report to tax authority in local currency; you owe in local currency. Per tax-vat-handling-chat: tax engine handles currency; verify it does.

Edge case 8: Stripe currency-conversion fees

Stripe charges 1% on currency-converted transactions. If you accept EUR but settle USD, you pay 1% extra. Either accept the cost (Tier 2 strategy) or settle in EUR with a EUR account (Tier 3). Track this fee separately in P&L.

Edge case 9: Failed payment retry with rate change

Initial €49 charge fails. Retry 3 days later. Rate has moved 1%. Charge: still €49 (original amount). Settled USD differs by 1%. Don''t change the original amount; rates move; that''s fine.

Edge case 10: Discount / coupon in foreign currency

You have a $10 USD off coupon. Customer pays in EUR. Do you discount $10 (~€9) or €10? Decide policy: convert at coupon-creation rate or apply percentage equivalents (10% off works in any currency). Percentage discounts handle multi-currency cleanly; flat-amount discounts need conversion logic.

For my system:

  • Refund flow tested in non-home currency
  • Renewal logic with FX-drift handling
  • Discount system that handles multi-currency
  • Audit log capturing all 3 currencies on disputes

Output:

  1. The edge-case test matrix
  2. The policy decisions (renewal, switch, discount)
  3. The audit-log fields
  4. The 5 scenarios I''ll test in staging before launching

The biggest edge-case mistake: **treating a foreign-currency refund as "approximately the USD-equivalent."** Stripe will refund in the original currency; your bank will deposit / withdraw in your settlement currency at the day''s rate; the math will not match what you intuitively expected. Trust the system; reconcile from the bank, not from your head.

## Reconciliation, Reporting, and the Finance-Team Handoff

Everything above feeds into accurate finance reporting. Build the bridge.

Help me make multi-currency clean for finance.

The reconciliation flow:

Daily / weekly:

  1. Pull Stripe (or Paddle) transactions for the period
  2. For each transaction:
    • Original currency / amount
    • Stripe FX rate used (if converted)
    • Settlement currency / amount
    • Stripe fees (in transaction currency)
  3. Cross-check against your invoice / subscription system
  4. Flag mismatches (rare but happen)

Month-end:

  1. Sum revenue by transaction currency
  2. Convert each currency total to home currency using:
    • Settlement (actual deposit) for cash basis
    • Month-end rate for accrual / GAAP
  3. Compare to bank deposits
  4. Reconcile differences (timing, fees, FX gain/loss)

Reports finance needs:

Report Purpose Cadence
Revenue by currency See where revenue comes from Monthly
FX gain / loss Statutory accounting Monthly
ARR (constant currency) Internal trend without FX noise Monthly
ARR (current rate) Reportable to board / investors Monthly
Settlement reconciliation Verify bank matches accounting Weekly
Tax-by-jurisdiction Compliance Quarterly

Tools:

  • QuickBooks / Xero multi-currency mode: native handling for SMBs
  • Stripe Sigma: query Stripe data directly in SQL
  • Manual spreadsheet: works at <100 transactions/month; breaks at scale
  • NetSuite / SAP: enterprise

Common reporting traps:

  • Summing across currencies (always invalid; convert first)
  • Ignoring FX gain/loss (it shows up at year-end as a surprise)
  • Reporting board-facing ARR without disclosing FX impact
  • Not separating settlement timing from underlying revenue

The "month-close" checklist:

  • All transactions imported and categorized
  • FX rates applied consistently per the policy
  • Settlement reconciled to bank
  • FX gain/loss booked
  • ARR calculated in both constant and current currency
  • Variance to forecast explained (separate FX from underlying)

Audit-trail discipline:

Every revenue figure should be traceable to:

  • Source transaction
  • Currency
  • Rate used
  • Source of rate
  • Home-currency amount

This is mandatory for SOC 2 / external audit; useful even if you''re not there yet.

For my finance flow:

  • Tools currently in use
  • The handoff to accountant / CFO
  • The monthly reconciliation cadence
  • The audit-trail completeness

Output:

  1. The reconciliation runbook
  2. The monthly close checklist
  3. The reports template
  4. The accountant onboarding doc (so they can take over without 3 hours of explanation)

The biggest finance handoff mistake: **giving the accountant a CSV of revenue with no currency or rate metadata.** They''ll fill in plausible numbers; the books will be wrong; the audit will catch it. Always pass currency + rate + source as columns; let the accountant do the converting (or verify your conversions). Transparency wins.

## Quarterly Currency Review

Currency policies aren''t set-and-forget. Build a quarterly review.

The quarterly currency review:

1. Exposure

  • % revenue per currency (this quarter vs last)
  • New currencies coming in (sign of expansion or accidental)

2. Pricing drift

  • Each non-home currency price: still aligned with home-currency target?
  • If drift >5%: discuss adjustment (raise local; lower; accept)

3. FX P&L

  • Total FX gain / loss this quarter
  • Material? (>2% of revenue → discuss)

4. Operational issues

  • Refund mishaps in foreign currency
  • Customer complaints about pricing display
  • Reconciliation gaps

5. Tier escalation

  • Are we ready to move from Tier 1 to Tier 2?
  • From Tier 2 to Tier 3?
  • Does revenue justify multi-currency banking?

6. Tooling

  • FX-rate API working / sufficient?
  • Reporting tooling sufficient?
  • Anything to upgrade?

Decision log:

Document each quarter:

  • Currencies supported
  • Pricing per currency
  • Rates used (sources + cadence)
  • FX P&L for the quarter
  • Any policy changes

Future-you and your accountant will thank you.

Output:

  1. The QBR (quarterly business review) template for currency
  2. The owner (founder for tier 1; CFO at scale)
  3. The decision log location

The biggest review-cadence mistake: **never reviewing pricing once it''s set.** A €49 price set in 2024 at $1.10/€ is "really" $49 USD. By 2026 at $1.05/€, it''s $51 USD. By 2027 at $1.15/€, it''s $44 USD. You''re either over- or under-charging EU customers without realizing. A 30-minute quarterly check is enough; the alternative is silent drift compounding for years.

---

## What "Done" Looks Like

A working currency / FX system in 2026 has:

- A clear tier (USD-only / display-local-settle-USD / fully-local) appropriate for current scale
- Database stores amount + currency + rate + rate-source for every transaction
- Pricing page shows local currency only when you actually charge in that currency (no fake conversions)
- Refunds happen in transaction currency; FX gain/loss tracked
- Monthly close reconciles transaction → settlement → home-currency revenue
- ARR reported in both constant-currency (internal) and current-rate (board)
- Quarterly review of currencies, prices, FX exposure, and tier-escalation triggers
- Accountant has full audit trail: currency + rate + source per row

The hidden cost of weak currency handling: **finance numbers nobody trusts.** A founder who reports "$120K MRR" but can''t answer "in what currencies, at what rates?" loses credibility with the first sophisticated investor or auditor. The cost is rebuilding trust + redoing books, often during a fundraise. The discipline of explicit-currency-everywhere takes 2x effort up front and pays off forever.

## See Also

- [Tax & VAT Handling](tax-vat-handling-chat.md) — closely related; tax engine consumes currency
- [Refunds & Chargebacks](refunds-chargebacks-chat.md) — refund flow with currency edges
- [Dunning & Failed Payments](dunning-failed-payments-chat.md) — retries across rate moves
- [Pricing Page](pricing-page-chat.md) — pricing-page UX with currency
- [Public API](public-api-chat.md) — APIs that return amounts must include currency
- [Audit Logs](audit-logs-chat.md) — currency / rate decisions are auditable
- [Customer Analytics Dashboards](customer-analytics-dashboards-chat.md) — currency-aware reporting
- [Database Migrations](database-migrations-chat.md) — adding currency columns to existing tables
- [VibeReference: Payment Providers](https://www.vibereference.com/auth-and-payments/payment-providers) — Stripe / Paddle / Polar comparison
- [VibeReference: Subscription Billing Providers](https://www.vibereference.com/auth-and-payments/subscription-billing-providers) — billing engines
- [VibeReference: Tax Compliance Tools](https://www.vibereference.com/auth-and-payments/tax-compliance-tools) — tax tools for multi-currency
- [VibeReference: BI Analytics Tools](https://www.vibereference.com/devops-and-tools/bi-analytics-tools) — finance reporting tools
- [LaunchWeek: Pricing Strategy](https://www.launchweek.com/1-position/pricing-strategy) — pricing strategy with currency considerations
- [LaunchWeek: Annual Contract Negotiation](https://www.launchweek.com/4-convert/annual-contract-negotiation) — annual deals with FX implications

[⬅️ Day 6: Grow Overview](README.md)