Choosing a Self-Hosted ERP for Multi-Currency Work: A Practical Evaluation Checklist

Why “supports multiple currencies” is not enough

A currency selector is not proof that an application can support your accounting workflow. You need to know where currencies apply, how amounts are converted, what gets recorded, and how the resulting figures appear in reports.

Treat product claims as prompts for testing, not as answers. Review the vendor’s official documentation for the version you plan to use, then reproduce your real workflows in a test instance. Documentation can explain intended behavior; a test can reveal whether the setup fits your organization.

ERPNext’s official multi-currency documentation is one useful example of the distinctions to investigate: it describes separate company, account, transaction, and price-list currency roles. That is an example, not a guarantee that another product uses the same model.

• Write down the currencies your business actually uses and what each one is used for.
• Name the reports and decisions that depend on converted amounts.
• Record each unresolved question as a product requirement to verify—not an assumption.

Map where each currency is used

Follow a transaction from the first customer-facing amount to its final accounting entry. A sales quote or price list may use one currency, while the invoice, company books, and payment account use others. Purchasing can follow a different path.

Test quotes or price lists, sales invoices, purchase invoices, and payments as separate workflows. Do not assume that choosing a currency in one area configures the corresponding ledger accounts or customer and supplier defaults. ERPNext’s currency documentation, for example, distinguishes currency availability from setting up foreign-currency accounts and party defaults.

For each step, note which currency the user enters, which currency the record retains, and which currency appears in the general ledger or report. Ask what happens when an account’s currency does not match the document or the company currency.

• Customer quote: What currency is shown on the quote and any price list?
• Sales invoice: What currency is entered, and what amount is posted in company currency?
• Supplier bill: Can the supplier invoice be recorded in its original currency?
• Payment: Which account and payment currencies are available, and how are they allocated?
• Reports: Can you identify both the original transaction amount and the converted amount?

Separate transaction currency from base or reporting currency

Ask the vendor to define the system’s currency terms. The organization’s base or company currency is not necessarily the same as a transaction currency, an account’s fixed currency, or a price list’s currency. A system may convert a transaction into company currency for accounting while retaining the foreign-currency amount on the document.

Use a simple scenario to check the distinction: issue an invoice in a customer’s currency, then inspect the invoice, ledger entry, customer balance, and company-level report. Verify which figures are original amounts and which are converted. Also ask whether users can tell the difference without exporting data or doing a manual calculation.

Make the expected treatment explicit in your evaluation notes. If the vendor’s terms are unclear, ask for a walkthrough using your scenario rather than relying on a general statement that the software is multi-currency.

• Document the intended organization or reporting currency.
• Identify any accounts that must hold balances in a particular currency.
• Confirm whether a transaction’s original currency and amount remain visible after posting.
• Check whether price-list currency conversion is separate from accounting conversion.

Check how exchange rates are obtained, dated, and recorded

A rate is meaningful only alongside its date, source, direction, and purpose. Find out whether rates are entered manually, imported from a configured provider, or both. Establish who can approve or change them and how users can tell which rate was applied to a transaction.

Test a transaction whose document date and entry date differ. Then enter another transaction after the rate changes. Check whether the application selects a rate based on the relevant date, permits an approved manual rate, and preserves a record of the rate used. Do not assume the application’s default matches your accounting policy.

ERPNext’s Currency Exchange documentation describes records with validity dates, source and target currencies, a rate, and buying or selling applicability. Use the selected product’s current official documentation to confirm its own fields and selection rules.

• Who may add, edit, or approve an exchange rate?
• Can a user see the rate, date, and source applied to a posted document?
• What happens if no rate exists for the transaction date?
• Can the system use a manually approved rate when an automated rate is available?
• Does changing a rate affect new transactions only, or can it alter existing records?

Test rounding, partial payments, refunds, and credit notes

Use amounts that reflect your real invoices and payment methods. Check both the precision shown to users and the amount that is ultimately posted. Displayed decimal places alone do not establish the rounding behavior of every calculation or ledger entry; ERPNext’s precision documentation treats monetary precision and rounding method as separate settings.

Next, record a partial payment at a different exchange rate from the invoice. Inspect the remaining balance, payment allocation, and any realized exchange difference. A second test should settle the rest of the invoice so you can verify the final allocation and balances.

Test a partial credit, a refund, and—if your process needs it—the use of customer credit against another invoice. Check which currency is shown on each document and how the corresponding amounts are reflected in the accounts. ERPNext’s payment and credit-note documentation describes these as distinct operations; confirm the chosen application’s own behavior.

• Create an invoice with a fractional amount and inspect both displayed and posted values.
• Pay part of the invoice using a rate different from the invoice rate; inspect the residual and realized difference.
• Complete the payment and confirm the invoice closes as expected.
• Issue a partial credit and test the refund or allocation process you actually use.
• Repeat the most important calculations with your normal currency precision and rounding settings.

Ask about period-end revaluation and historical reporting

An exchange difference on settlement is not the same as revaluing an open foreign-currency balance at period end. Revaluation adjusts the company-currency carrying value of eligible open balances while leaving their foreign-currency amounts unchanged. Ask which accounts and balances are eligible, what rate and date are used, and how the adjustment is reversed or carried forward under your process.

Test an open foreign-currency balance at two reporting dates. After revaluation, compare the foreign amount, company-currency carrying value, and original transaction record. Then run reports for both dates. Your goal is to confirm that later valuation does not silently rewrite the original invoice, payment, or historical rate record.

ERPNext’s exchange-rate revaluation documentation describes revaluation separately from payment-related realized differences and explains the use of a later carrying value and closing rate. Treat this as a product-specific example and check the chosen application’s current documentation and accounting settings.

• Can you identify open foreign-currency balances that require revaluation?
• Which rate date is used for each period-end adjustment?
• Can users distinguish unrealized revaluation from realized settlement differences?
• Do historical reports preserve the figures and rates applicable to their reporting dates?
• Can you trace a revaluation adjustment to its source balance and posting?

Verify imports, exports, integrations, and audit records

Currency behavior must survive more than manual data entry. Test the spreadsheet templates, import validation, and export fields you expect to use. Include currency codes, dates, exchange rates, amounts, and relevant account or party fields. Check how the system handles missing currencies, invalid codes, duplicate rows, and amounts that need more precision than the display format.

If another application sends or receives financial records, test a small end-to-end exchange rather than assuming that matching field names mean matching semantics. Confirm whether the integration transfers the original amount, currency, rate, rate date, and converted amount where required.

Check the audit trail for changes to exchange rates, documents, and allocations. For imports, inspect warnings and logs as well as the resulting records. ERPNext’s data-import documentation describes spreadsheet templates, validation warnings, import logs, and child-table exports; verify the corresponding behavior for your chosen product.

• Import a small file containing valid and intentionally invalid currency rows.
• Compare the imported records with the source file and review validation messages.
• Export the same records and check whether currency and rate fields are included.
• Test one representative integration in both directions, if applicable.
• Confirm who can make changes and what record of those changes is available.

Build a small test matrix before choosing

A compact matrix makes comparisons more reliable than a feature checklist. Use the same scenarios, currencies, dates, and expected outcomes in every application you evaluate. Mark results as passed, failed, or not verified, and keep screenshots or report outputs where useful.

Separate workflow fit from deployment fit. First establish whether the application handles your currency and accounting requirements. Then evaluate how it will be operated: who controls access, data, backups, upgrades, and recovery, and what hosting responsibilities remain with your team.

For a self-hosted deployment, check the production configuration and operational requirements for the specific application. Docker’s production guidance for Compose, for example, addresses production-specific configuration; that is a separate question from how an ERP calculates currency amounts. Managed deployment can handle parts of the infrastructure, but it does not remove your responsibility for data, access, and governance choices.

Airbip offers managed deployment for applications in its public catalog, including ERPNext. Its stated infrastructure capabilities include Docker-based instances, routing and TLS certificate automation, DNS checks, service lifecycle management, and configurable daily, weekly, and monthly backups. Confirm current terms on the live Airbip website and decide whether managed infrastructure suits your needs; it does not establish that an application meets your accounting requirements.

• Scenario
• Expected result
• Observed result and evidence
• Pass, fail, or not verified
• Open question, owner, and next step
• Minimum test set: foreign-currency invoice, supplier bill, rate change, partial payment, credit or refund, period-end revaluation, and import/export.