Who actually owns FX logic inside a product?
Curious question for SaaS and app builders.
When your product deals with multiple currencies, who owns exchange rate behavior long-term?
Do you handle FX logic inside the product because it affects UX, trust, or business logic?
Or do you push it to finance/accounting?
Or avoid it entirely by letting users enter rates / using UI-only conversions?
I’m noticing teams are very split on this, and the decision seems to have long-term consequences.
Would love to hear how you handle it and why.
Trending on Indie Hackers
Getting my first 100 users with $0: what actually worked
What's the point of AI generated comments?
Why good products are often hard to understand at first glance
Why I’m building an AI marketplace instead of another SaaS
How does everyone setup their local computers for dev work?
Building accounting tools, I've landed on: product owns the FX logic, but make it transparent and overridable.
The problem with pushing it to finance/accounting is that by the time they're involved, the rates are already baked into transaction records. And those records need to be consistent for audit trails.
What's worked for me: fetch rates from a reliable API (we use exchangeratesapi), show the rate and timestamp clearly in the UI, but always let users override if their bank gave them a different rate. Store both the system rate and the user-entered rate if different.
The long-term consequence you're noticing is real. Teams that avoid it early end up with data integrity issues when they eventually need proper multi-currency reporting. Better to own it upfront even if the initial implementation is simple.
This is super insightful, especially the point about rates being “baked into” transaction records and audit trails.
Quick follow-up: when users override rates, is that mostly for reconciliation / accounting alignment, or does it ever affect user-visible balances and refunds? I’m trying to understand where override flexibility matters most.