ERPNext multi-currency accounting and revaluation

When ERPNext multi-currency accounting and revaluation matter for your books

Multi-currency accounting in ERPNext matters as soon as your finance team books sales invoices, supplier bills, payments or bank balances in a currency other than the company's base currency. The base currency of the company is the reporting currency for the whole ledger, while each customer, supplier and bank account can carry its own account currency and each invoice or payment its own transaction currency. Those three levels are where most configuration errors start, so the first decision is which currencies each party and bank account really needs, and whether the company wants to book in those currencies at all. Confirm with your auditors and tax advisers which functional and reporting currencies they expect to see before the chart of accounts is finalized.

Once foreign-currency documents exist, ERPNext needs exchange rates to convert them. Exchange rate entries are the source for conversion on each transaction, and the difference between the rate at booking and the rate at settlement produces realized gains and losses when an invoice is paid. Open foreign-currency balances that have not been settled are not adjusted automatically in the ledger, so they carry the rate from the date they were booked. Month-end exchange rate revaluation is the process that restates those open balances at the period-end rate and posts the difference to an unrealized exchange gain or loss account. Check the current ERPNext documentation for the exact revaluation steps, the accounts it posts to and any limits, because the mechanics have changed across major versions.

The practical risk is a period-end balance sheet that shows receivables and payables at stale rates, or realized and unrealized differences mixed into the same account. Ask your implementation team to confirm which exchange gain and loss accounts each company uses, how bank account currencies are reconciled against the statement, and who approves the revaluation journal before it posts. Test the process on a copy of the site with a few open invoices in each currency, reverse a revaluation, and compare the results with an independent calculation. Also confirm how the revaluation interacts with your period close and locking rules, since a late correction to a closed period needs a clear owner.

Which currency configuration fits which business

This table compares the four currency settings ERPNext uses (company, party, bank account and account currency) and the exchange rate source choice, with when each fits and what is hard to change later. Read each row as a decision: the setting on the left is fixed early, while the others can often be adjusted, but some changes after posting require reversing or rebuilding entries.

Setting	When it fits	What it costs to change later
Company currency	One functional currency for the legal entity's books, with all ledger balances reported in it	Changing it after transactions exist is effectively a rebuild, so confirm the reporting currency with your auditors before the chart of accounts is loaded
Party currency (customer and supplier)	Invoices and payments in a foreign currency for a specific customer or supplier, with the company currency still used for the ledger	Changing it on a party with open invoices is blocked or messy, so set it on new masters and avoid switching it mid-cycle
Bank account currency	A foreign-currency bank account that holds funds in that currency and should be revalued at period end	Reassigning an existing bank account to another currency distorts its history, so open a new account master for a new currency
Account currency	A ledger account, such as a foreign-currency receivable or bank GL account, that must hold only one currency	Locking an account to a currency after posting leaves old entries in the wrong currency, so decide per account before first use
Exchange rate source (manual or stored rates)	Small volumes or a finance team that enters rates from a fixed source each period	Rates entered by hand need a consistent rule for the revaluation date, and switching sources later does not restate past rates
Exchange rate source (automated feed)	Higher volumes or many currency pairs where a published rate must be applied consistently	Confirm with your provider which rates and dates the feed supplies, since the feed and its rules are configured per deployment and must be validated

How realized and unrealized gains and losses are posted

ERPNext treats exchange differences in two different ways: amounts that settle during the period and balances that are still open at period end. Keeping those two postings separate, and mapping each to the right account, is what makes the month-end numbers explainable to auditors and to the board.

Realized gains on settlement

When a foreign-currency invoice or bill is paid, ERPNext compares the exchange rate at settlement with the rate booked on the original invoice and posts the difference as a realized gain or loss. Confirm which income account and which expense account receive these postings in your company settings, and make sure they are not parked in a suspense or default account that nobody reviews.

Realized losses on payables

A supplier bill booked in a foreign currency that is paid after the rate has moved creates a realized loss on the payment entry. Treat this as an operating expense, not as a balance sheet item. Check that the expense account you choose is included in the profit and loss layout that management reads, so the cost does not disappear into a catch-all line.

Unrealized amounts at period end

Open receivables, payables and foreign-currency bank balances are not settled, so their value changes with each rate movement without any cash moving. ERPNext's exchange rate revaluation tool restates these open balances at the period-end rate and posts the offset. Confirm that a dedicated unrealized exchange account exists, because mixing it with realized results makes the two cannot be told apart later.

Reversal of revaluation entries

Revaluation entries are usually reversed at the start of the next period so that the next settlement is not counted twice. Ask whether your revaluation journal is set to reverse automatically, and confirm that the reversal posts to the same unrealized account. A missing reversal leaves a balance that drifts month after month.

Mapping accounts in the chart

Each posting needs an account of the correct type: income or expense for realized results, a balance sheet account for the revalued party or bank balance, and a separate account for the unrealized offset. Verify the account types and root types in your chart of accounts before the first live period, and check that the accounts are restricted to the correct company when several legal entities share a site.

Testing the postings before go-live

Run one foreign-currency invoice, one payment at a different rate, and one revaluation on a test site with known rates. Compare the ledger against a hand calculation from the rates you set. Confirm which exchange rate source your team will use at period end and who approves the rate, because the revaluation is only as reliable as the rate it reads.

How to set up multi-currency and revaluation in ERPNext

This sequence takes a company from its base currency and fiscal calendar to a tested, live multi-currency setup in which foreign-currency transactions post correctly, gains and losses land in the right accounts, and month-end revaluation has been rehearsed before it touches real books.

Confirm company currency and fiscal calendar
Before any currency record is created, the team confirms the company's default currency, the fiscal year start and end dates, and which legal entities will hold foreign-currency balances. The finance lead signs off on these values because the company currency and the accounting calendar are difficult to change once transactions exist. Check: the Company record shows the agreed default currency, and the Fiscal Year records cover every period the first go-live month will need. Ask the implementation partner to confirm in writing which of these fields can still be edited after the first posting.
Create currency and exchange rate records
An administrator enables each foreign currency that the business transacts in and enters exchange rates for the dates the sample transactions will use. Rates can be entered manually or loaded from a source your organization approves, and the finance team should decide which rate source is the system of record for each month-end. Check: each currency appears in the Currency list with the correct symbol and precision, and the Currency Exchange records return the expected rate for a test date. Confirm with your bank or treasury team which rate type (for example, buying, selling or mid) your policy requires.
Set party and bank account currencies
Customer and supplier records are assigned a default billing currency where they transact in a currency other than the company currency, and bank accounts are set to the currency the bank actually holds. Mismatches here are a common source of posting errors, so the team reviews every foreign-currency party and bank account against the contract or bank mandate. Check: a test sales invoice and a test purchase invoice for a foreign-currency party default to the expected currency, and the bank account currency matches the statement you will import.
Define gain, loss and revaluation accounts
The accounting lead maps the ledger accounts that will receive realized exchange gains and losses, and the unrealized revaluation postings, and confirms that the chart of accounts has the correct account types for each. Separate accounts for realized and unrealized differences make month-end reporting clearer and let the auditor trace each movement. Check: the company's exchange gain and loss account settings point to the intended accounts, and a trial balance or account list shows them as the correct account types under the right parent groups.
Test with sample foreign-currency transactions
The team posts a small set of illustrative transactions in a test site: a foreign-currency sales invoice, its payment received on a later date at a different rate, a purchase invoice, and a payment made from a foreign-currency bank account. Each transaction is reviewed against a manual calculation of the expected gain or loss. Check: the realized exchange difference posted by each payment matches the manual calculation, the ledger shows the difference in the designated account, and the accounts receivable and payable balances clear to zero for fully settled documents.
Run a revaluation in a non-production copy
The team copies the production data into a non-production environment and runs the month-end exchange rate revaluation for the period, using the rate set your policy requires. Revaluation postings are reviewed to confirm they reverse correctly where expected and that open foreign-currency balances in receivables, payables and bank accounts are restated. Check: the revaluation journal entries total as expected, the trial balance balances after posting, and reversing the revaluation returns the original balances. Ask the partner to document the exact steps so the production run follows the same sequence.
Go live with controlled cut-over
The finance lead approves the go-live date, freezes the configuration, and records the final currency, rate source and account mapping in the operating procedures. The first production revaluation is run with a reviewer present, and the outcome is compared against the rehearsal in the non-production copy. Check: the first live month-end revaluation reconciles to the rehearsal, the configuration record is signed off, and the team can explain each journal entry to an independent reviewer.

How deployment choice affects currency rate sourcing

Frappe Cloud runs the servers, background workers and scheduler for your site, so Frappe operates the infrastructure that executes scheduled jobs. Your team manages ERPNext settings, currencies, exchange rates and the revaluation process inside the application. Confirm with Frappe which rate sources your version can reach, because the platform controls outbound connections on your behalf.

Scheduler ownership: Frappe operates the scheduled jobs, so you check job status through the platform and the application instead of a server you manage.
Custom logic limits: Server Scripts are disabled by default from version 15 and Frappe Cloud public shared benches do not allow them, so custom rate-fetch or revaluation logic needs a different plan, such as a dedicated bench or a custom app. See the Server Script documentation.
Outbound access: confirm in writing which external hosts the site needs to reach for rate feeds and whether the plan allows those connections.
Recurring cost: Frappe Cloud shared site hosting starts at 5 US dollars per month, and servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, according to the ERPNext pricing page.

Before go-live, confirm the rate source, the scheduler status for the site, and whether your plan allows every script or connection the revaluation design needs.

The Docker Compose path uses the production images and Compose files in the frappe_docker repository. Those files define services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Your team owns the host, the network path, image updates and the firewall rules, so it also owns the outbound route that any exchange rate feed uses. The single-file demo setup is marked for short-lived evaluation only and should not hold currency balances or revaluation history. See the frappe_docker repository.

Scheduler service: the scheduler runs as its own container, so confirm it is up after every host reboot or stack restart and review its logs after scheduled runs.
Outbound network: containers reach external rate sources through the host's routing, DNS, proxy and firewall configuration, so test the connection from inside the ERPNext containers.
Image and version pairing: pull images that match the ERPNext version you are running, and check the release notes before each update.
Server Scripts: on self-hosted installs you decide whether to enable them, and from version 15 they require the server_script_enabled setting, which should be approved and recorded.

Before go-live, confirm that the scheduler container runs after restarts and that the rate source is reachable from the ERPNext containers under your firewall policy.

A bench-managed install uses the bench command line tool on a Linux server you control. Your team installs and maintains Python, Node, MariaDB, Redis and the process supervisor, and it decides how the scheduler and background workers stay running. This model gives the most control over scripts and network policy, and it also places the most operational work on your engineers. The ERPNext repository documents the supported install methods.

Scheduler process: scheduled jobs run only when the scheduler is enabled for the site, so confirm this for each site and check it after every deployment.
Process supervision: define systemd or a similar service manager entries for the web, worker and scheduler processes so they restart after reboots and failures.
Outbound access: the server needs outbound HTTPS to the chosen rate source, so agree on proxy settings, DNS and egress rules with the network team before testing.
Patching ownership: your team applies minor releases. Both supported major versions receive frequent minor releases, so set a patch cadence and a test environment.

Before go-live, confirm the scheduler status, the process supervision configuration and the egress path to the rate source, and record who approves changes to Server Scripts.

How month-end revaluation runs and what it reverses

Run revaluation as a dated journal entry at period end, after every foreign-currency invoice, payment and bank transaction for that period is posted. In ERPNext, the Exchange Rate Revaluation document selects the accounts to restate, which should include receivables, payables and bank accounts held in a currency other than the company currency. Each account is restated at the period-end rate, and the difference from its book balance is posted to the unrealized exchange gain or loss account set on the company. Confirm the document name, fields and account settings in your version, and decide the rate source before the first run so that every balance in the period uses the same approved rate.

Revaluation entries are temporary by design. The usual pattern is that the unrealized difference reverses at the start of the next period, so the gain or loss is recognized as realized only when the invoice or payment settles at its transaction rate. Confirm whether your version creates the reversal automatically on a set date or requires a manual reversal entry, and which date controls it. Check the accounts and cost centers on each reversal against the original entry. A reversal posted to the wrong period, or one that does not match its original, is a frequent source of errors, so review it before anything else posts in the new period.

Run checks both before and after posting. Before the run, confirm that every foreign-currency party and bank account is included, that the rate and date match the approved source, and that no period transactions are still in draft. After the run, compare the revaluation total with the change in each foreign-currency balance in the receivable, payable and bank reports, and confirm the entry sits in an open accounting period. Period locking matters here: if a closing date or Accounting Period lock is in place before the revaluation runs, the entry cannot post. Set the revaluation date inside the open period and sequence it before the close. Reopening a locked period to fix a revaluation should be a documented and approved exception.

Access, audit and control considerations for currency postings

Exchange rates and revaluation entries move reported balances, so they need the same access discipline as the ledger itself. The cards below cover who may enter rates, who may post revaluations, how rate edits are traced, and what your internal reviewers will ask to see.

Who may enter exchange rates

Currency Exchange records feed every foreign-currency transaction, so a wrong rate affects invoices, payments and revaluation at once. Decide which roles may create or edit these records, and whether treasury or finance operations owns them rather than the people who post invoices. Check that a user without that role cannot save a rate through the desk, the API or a data import.

Role permissions for revaluation

Running the revaluation is a posting action, and it should sit with a small group of accountants who also hold the period-close responsibility. Confirm which roles can submit Journal Entries against the unrealized exchange gain and loss account and which can cancel them. Test the permissions with a user who has accounting read access but no posting rights, because a read-only user should not be able to produce the same entry.

Audit trail for rate edits

Frappe records document versions, so changes to a saved exchange rate can be traced if version tracking is enabled for the doctype. Ask your administrator to confirm which fields are tracked and how long the version history is retained in your database backups. Compare a rate change against the bank or market source you cite, so a reviewer can follow the entry from source to ledger.

Segregation between entry and review

The person who enters a rate or posts a revaluation should not approve it. ERPNext does not enforce this split by default, so you will need role design, workflow or a documented review step to create it. Define who reviews the revaluation Journal Entry, what evidence they check, and how they record approval before the period is closed.

Controlling scripts that alter postings

Custom scripts that set exchange rates or change revaluation logic can alter posted values without an obvious change in the user interface. Since version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, so confirm whether that setting is on and who approves script changes. Keep every custom posting rule in version control with a named reviewer.

Evidence for internal review

Internal audit and external auditors will ask for the rate source, the revaluation calculation, the approver and the reversal treatment. DeployOpen can prepare these controls and the evidence they produce, but the assessment itself belongs to your internal audit function or an independent auditor. Agree the evidence list with them before the first month-end run.

Questions finance and IT leaders ask about multi-currency ERPNext

What drives the cost of implementing multi-currency ERPNext?

The cost follows the number of companies, currencies, bank accounts and historical records in scope, plus how many integrations feed foreign-currency transactions into the ledger. Discovery and design cover how exchange rates are sourced, which accounts hold realized and unrealized differences, and how month-end revaluation will be approved. Build work covers configuration, any custom reports or scripts, testing with real transaction patterns, and training for finance staff. Recurring costs include hosting, your own staff time for rate maintenance and close, and any support retainer. Ask for a quote that separates these phases, lists each integration and currency pair, and states what is excluded.

Can our in-house finance and IT team set up multi-currency ERPNext themselves?

A capable team can configure the core settings, since ERPNext is free and open source and the setup is documented, but the difficult part is the accounting design. Decisions about company currency, account currencies, exchange rate sources, and how revaluation entries post to the ledger need someone who understands both the accounting policy and the software. Deployment is a separate skill: installation through bench, Docker Compose or Frappe Cloud, backups, upgrades and access control all need ongoing ownership. Be honest about whether your team has done a period close in ERPNext before, and whether anyone will own the system after go-live.

How long does a multi-currency ERPNext setup typically take?

No fixed duration applies because the timing depends on the factors that drive it: the number of legal entities, the currencies and bank accounts involved, the volume of historical open items, the number of systems feeding transactions, and how many approval steps the revaluation process needs. Accounting policy decisions made early shorten the build, while late changes to chart of accounts structure extend it. Testing needs at least one full simulated month-end close with real data shapes. Ask any partner to show the phases, dependencies and the decisions that must be closed before build starts, and confirm which milestones require your sign-off.

What data and people does a multi-currency implementation need from us?

You need the chart of accounts, customer and supplier master data with their default currencies, bank account details, open invoices and payments, and the exchange rate history your auditors already accept. On the people side, the finance controller should own accounting decisions, a senior accountant should validate test closes, bank and treasury contacts should confirm feed formats, and IT should provide hosting access, identity integration and a test environment. Clear owners prevent delays when a rate source or bank format needs a decision. Confirm these roles and availability in writing before the scope is signed.

How should we handle historical foreign-currency balances when we migrate to ERPNext?

The usual approach is to migrate open items at their original transaction currency and exchange rate, so that later realized gains or losses can be calculated correctly, while closed history stays in the legacy system or an archive. Opening balances for foreign-currency bank accounts and payables need reconciliation to the source ledger before the first ERPNext close. The ERPNext Data Import tool handles CSV or Excel files and child table rows, but its documentation advises importing only a few thousand records at a time, so large volumes need batching and reconciliation checks after each batch. Agree on the cut-off date, the reconciliation evidence and who signs off the migrated balances.

What should a partner quote for multi-currency ERPNext include?

A useful quote lists the written scope, the currencies, companies and bank accounts covered, and each integration that moves foreign-currency data. It should name the deliverables, including configuration records, test scripts, revaluation runbook, user training and documentation, and state what the client must provide. It needs a clear acceptance process, a list of excluded items such as tax reporting or legacy archive work, and the assumptions behind the schedule. Ask whether post-go-live support is a separate retainer, how upgrades between ERPNext major versions are priced, and which version the work targets. DeployOpen plans and delivers implementations against a written scope, and quotes follow from that scope.

Which ERPNext versions should we target for a new multi-currency build?

Target a version that is still supported at the planned go-live date, and check the lifecycle before committing. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027, and version 16 until the end of 2029. Frappe's support policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Confirm the current status on the vendor page at the time you sign, and plan the upgrade path into the project budget.

How DeployOpen scopes and delivers multi-currency work

DeployOpen scopes multi-currency work as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before any configuration starts. The first step is a currency model workshop with your finance lead. It settles which currency each company uses as its base, which accounts and parties carry a fixed account currency, which bank accounts hold foreign balances, and where exchange rates will come from. Those decisions are hard to reverse once transactions post, so they belong at the start of the engagement and not after go-live. The written scope should name each of these decisions and who signs off on it.

Next, DeployOpen configures the currency model and tests revaluation with your finance team using a copy of your data. Testing covers invoices and payments in several currencies, partial settlements, a revaluation run for a closed-looking period, and a check that the unrealized and realized gain and loss postings land in the accounts your controller expects. Your team confirms the results line by line before the procedure is accepted. Confirm that your ERPNext version supports the revaluation workflow you plan to use, and check the current release notes with the vendor before you commit to a design.

DeployOpen then documents the procedure as a month-end runbook covering rate entry, the revaluation run, review of the journal entries, reversal rules and who approves the posting. Ongoing work such as rate feed maintenance, release upgrades and changes to the currency model can be covered by a retainer, which is a recurring agreement separate from the fixed-scope build. DeployOpen prepares the system, controls and evidence for your own review, but it does not issue audit opinions. Ask your external auditor which evidence they will expect to see before the design is finalized.

ERPNext multi-currency accounting and exchange rate revaluation