The account decides the currencyThe account decides the currency

In the summer of 2025 Tigg Accounting needed to handle more than one currency properly. Most Nepali businesses keep their books only in rupees, but some pay foreign suppliers, bill clients in dollars, or hold a foreign-currency bank account. For them, every payment, receipt and bank line carries two facts: a currency, and a rate to NPR.

Walking through the money forms, I found the failure that worried me most. A form opened in NPR, where the exchange rate is 1 and the field is disabled. If the user then switched the currency to USD, the 1 stayed. Saving worked, because 1 is a present and positive number. The ledger then recorded a USD 1,250.00 payment as NPR 1,250.00 instead of roughly NPR 1,66,750.

An empty field gets noticed; a wrong number that looks right does not. That idea shaped the rest of the work: a default is a claim, and the form should only make claims that are true in the current context.

I was the only UI/UX designer at Tigg, and at that point I was moving from my internship into a frontend role. The trigger was the product's move to real multi-currency support. I didn't find a Figma file for these surfaces because I designed them directly in code. I changed the live forms, tested each rule against the forms that used it, and the senior frontend engineer reviewed every change before it was merged.

My research was a surface audit. I went through every place in the accounting app where an amount or a currency control appears and noted what it showed and what it let people do:

• the dashboard bank cards, the bank overview and its charts;
• bank statements, the reconciliation report and the matching drawers;
• customer and supplier payments, quick receipt, quick payment, cash transfer;
• the sales documents (quotation, sales order, invoice, credit note);
• the journal voucher used for forex adjustments.

Some context applied everywhere. NPR is the base currency, so every rate is written "to NPR" and NPR is listed first. A revaluation gain or loss is booked in NPR. Many businesses run more than one branch, and a branch changes which documents apply.

The audit came down to three rules. Each one answers a question the forms had left open.

1. An amount always carries its currency

Dashboard balances, charts, statements and the reconciliation drawers now show the currency code or symbol next to the number, with the minus sign in the right place. The code is smaller and lighter than the amount: it gives context without adding clutter.

2. The account decides the currency

A payment from a USD bank account can only move USD. When someone picks a foreign-currency account in a payment, receipt or transfer, the form sets the currency to match and locks the selector. The rate stays editable, because the rate is still the user's decision.

My first version locked the currency for every account, NPR accounts included. Two days later I limited the lock to foreign accounts. Looking back, locking an NPR account added friction without preventing any real mistake. The risky case was always a foreign account posted in the wrong currency.

3. Leaving NPR clears the rate

Choosing NPR sets the rate to 1 and disables the field. Leaving NPR for a foreign currency empties the field and makes it required, so saving is blocked with "Exchange Rate is required" until someone types a rate. The forex-adjustment journal always opens in NPR with the currency fixed, because revaluation is recorded in the base currency.

The same principle carried over to bank reconciliation. Before this work, every unmatched bank line needed "Find Match" or a full drawer to create a receipt or payment, even when the answer was obvious: a monthly fee, or a regular customer paying again. The backend could already suggest an account for a line, but the table didn't use the suggestions.

I designed and built a suggested account and an approve tick on every pending row, in the Bank Statement tab and in the bank overview's list of recent unmatched transactions. The first suggestion is filled in. If it's wrong, the user can search for any account, or clear the field. A cleared row stays empty, because clearing a suggestion is a decision and the table shouldn't quietly fill it again.

The hard question was when the tick is allowed to post straight away. A one-click post can't guess an exchange rate or a branch. So the tick checks three things in order: whether the organisation uses billing locations (branches), whether the line is in a foreign currency, and whether the bank account is. If any answer is yes, nothing is posted. The full drawer opens with the chosen account already filled in, and it asks only for what's missing.

I also removed the match percentage from the suggestion label. The score behind it came on different scales in different responses, so any number I showed would look more precise than the data really was. Now the label shows only the account name.

The work ran from late June to early September 2025 in three stages, each merged to production after review:

1. Jun – Jul 2025Currency visible and bound to the accountCurrency on every money surface, the account lock, and the rate that clears when leaving NPR. Merged to production in July.
2. Jul 2025Currency in the reconciliation drawerThe add-payment drawer follows the bank's currency, and it still works when multi-currency is switched off.
3. Aug – Sep 2025Suggestions and quick approveSuggested accounts, search, clearing, the guard, and links from a reconciled line to its records. Merged to production in early September.

Quick approve is used in the product today. Measured outcome: none. I have no figures for error reduction, reconciliation time or how often suggestions are accepted, so I don't claim any.

A small sign that the rule held up: in March 2026 another engineer built a new document form and reused the same "clear the rate when leaving NPR" behaviour.

If I were measuring this, I'd track four things: how often the tick is used, how often people change or clear the suggestion, how often the guard sends a line to the full form and for which reason, and how many one-click posts are reversed within a week. That last number is the real safety signal.

A default is a claim. "1" is only true for NPR. A pre-filled number is more dangerous than an empty field because it passes validation. I learned this twice: two weeks after fixing the forms, I briefly let the reconciliation drawer fill an empty rate with 1 for convenience, and replaced it with an empty, required field the same day.

Constrain only what can go wrong. Locking NPR accounts protected nobody. A constraint should match a real risk, not just look careful.

Speed should depend on context. One click promises that nothing else is needed. When a branch or a rate is involved, the honest response is the full form, already filled in, rather than a guess or an error.