[Idea] Allow inserting both domestic and foreign currencies in transactions as absolute values

[tjmills-dev]

Affected area

Expenses and reimbursements

Problem or opportunity

At the moment when entering a transaction in a foreign currency, you can only enter either the Frankfurter rate or a custom rate of conversion. This means that if your card provider charges fees or displays an inaccurate exchange rate, you have to trial-and-error finding a conversion rate that outputs an amount matching what you paid.

Desired outcome

Allow people to enter both the initial foreign currency amount and the output domestic currency amount. Spliit could then calculate the rate of conversion from that.
The feature could be taken further to have a conversion fee entry, to keep the rate of conversion accurate while still showing a correct final domestic currency.

Alternatives or workarounds

The main workaround is just to fiddle with the conversion until the domestic currency matches what you paid.

Alternatively, you can avoid using the foreign currency and enter everything in the domestic currency, but then receipts don't match up. Additionally, if splitting by amount (for instance, having eaten at a restaurant), you have to calculate the proportions in the foreign currency and then use those to calculate domestic currency amounts. This is cumbersome.

Additional context

No response

Before submitting

• I searched existing issues for similar ideas.
• I removed personal, financial, and secret information from this public proposal.

[pullfrog]

Triage of this issue for a maintainer — no implementation planned.

Summary

The author asks for a third way to handle foreign-currency expenses: instead of entering a foreign amount plus a conversion rate (provider rate or custom), they want to enter the foreign amount and the final domestic (group-currency) amount as two absolute values, with Spliit deriving the rate from the pair. Today the converted amount is a read-only preview, so card-provider fees or inaccurate provider rates force trial-and-error tuning of the custom rate until the preview matches the real charge. The fallback — recording everything in the domestic currency — breaks receipt matching and makes split-by-amount math cumbersome. The "conversion fee" field mentioned in the issue is optional; entering both amounts already absorbs fees implicitly.

Feasibility

Feasible, and mostly a workflow change rather than a systems change. The data model already stores the original amount, original currency, and conversion rate, and a "custom rate" conversion path already exists — this feature is simply a new way to arrive at that rate (domestic ÷ foreign), not new storage. One subtlety worth knowing before committing to it: conversion is server-authoritative, so the derived rate must round-trip exactly in integer minor units — including 3- and 0-decimal currencies, where naive rate math shifts digits — so the server-computed total always equals exactly what the user typed. The existing scale-aware conversion helpers are designed for this class of problem, but it needs deliberate handling and tests.

Scope

Medium, at the small end. Work concentrates on the expense form's conversion flow — making the converted amount editable, defining how the two inputs drive each other, and deriving/storing the resulting rate. No database migration or API contract change is expected, and balances, splits, reports, and import/export are unaffected. The fee-entry extension would add extra UX and rate-math decisions, but it is not needed for the core request.

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using openai-compatible/omen-alpha ｜ 𝕏}

[antonio-ivanovski]

Yes! Will be implementing this soon