Currencies, exchange rates and decimal precision
Payments keeps the receipt's original transaction-currency amount and its stored base-currency equivalent. Allocation uses the receipt's saved rate for its base allocation amount.
Conversion direction
Base receipt amount = Receipt amount × Receipt exchange rate
Base allocation amount = Allocation amount × Receipt exchange rate
Available = Receipt amount − Sum of allocations
Example: foreign-currency receipt
| Field / result | Value |
|---|---|
| Transaction currency | EUR |
| Ledger base currency | GBP |
| Amount received | EUR 200.0000 |
| Exchange rate | 0.85000000 |
| Stored Base amount | GBP 170.0000 |
| Allocation to EUR invoice | EUR 150.0000 |
| Base allocation | GBP 127.5000 |
| Remaining Available | EUR 50.0000 |
The remaining 50 is EUR, not GBP. The compatible invoice's amount due falls by EUR 150. A GBP invoice is not a target merely because the receipt's base is GBP.
Same-currency receipt
For GBP transaction currency and GBP base currency, use the organisation's agreed rate, normally 1 for this direct equivalence. The form defaults the rate to 1 but still requires the actual currency choices and setup.
No live exchange-rate lookup runs when selecting currency/date. Exchange rate date records the provided date; it is optional in this form, not an automatic substitute for the receipt date.
Ledger base currency is not an editable conversion choice
The required Ledger base currency is loaded read-only from active configured settings. If it is absent, resolve the setup/access dependency described in Before you start.
LEDGER_BASE_CURRENCY_CONFLICT requires Accounts/admin review. It can occur when an existing receipt's stored base differs from active settings. Do not guess an override, change ledger settings to silence the message, or recreate historical money under a different currency.
Decimal input rules
| Value | Accepted example | Rejected/problem example |
|---|---|---|
| Amount, at least 0.0001, up to 4 decimals | 200, 200.50, 0.0001 | 0, -5, 10.12345 |
| Allocation amount, same precision | 127.6000 | 127.60001 |
| Exchange rate, at least 0.00000001, up to 8 decimals | 0.85000000, 1 | 0, 0.123456789 |
| Plain decimal format | 1234.56 | £1234.56, 1,234.56, 1e3 |
The browser also rejects values that cannot be represented safely through its numeric submission conversion. Do not assume every very large digit string that looks valid is an accepted financial input.
Amounts display four decimal places and rates eight in the detail. Multiplication/storage can round a tiny base amount to zero; posting requires the saved base amount to remain positive. Inspect saved values and involve Accounts for unusually small amounts instead of entering a false rate.
Different invoice and receipt rates
An invoice can carry one historical rate while the actual receipt carries another. The payment allocation's base value is calculated from the receipt rate, not automatically from the invoice's copied rate. This screen does not expose a realised-exchange-difference reconciliation or write-off control.
Example: invoice EUR 200 had a GBP 180 base value at 0.90, while receipt EUR 200 has GBP 170 at 0.85. Allocating EUR 200 can settle the transaction-currency invoice balance, but do not assume that the GBP 10 accounting difference is automatically explained by this page. Have Accounts reconcile the applicable accounting entries and supported treatment.
Comparing register amounts
Sorting Amount descending does not convert unlike transaction currencies. For cross-currency reconciliation, use approved base-currency accounting views and the saved rates rather than adding raw GBP/EUR/USD row values together.