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
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.
Good question. In my experience, it's almost always reconciliation/accounting alignment.
The scenario that comes up constantly: user's bank shows a transfer of £412.37 on Monday, but the bank's actual FX rate that day was slightly different from the API rate, so the transaction in your system shows £411.95. Now the books don't match the bank statement, and someone has to manually hunt down that £0.42 difference.
That's why I ended up building reconciliation tooling (ReconcileIQ at bankreconciler.app) - FX discrepancies are one of the most common pain points. When you're comparing thousands of transactions across systems, even tiny rate differences compound into hours of detective work.
User-visible balances and refunds tend to be more forgiving because customers generally accept "approximately £X" - but accounting teams need exact matches. The override matters most at the point where your data feeds into their reconciliation process.