- Home
- Apps
- SaaS Tools
- Multi-Currency Revaluation & FX Gain/Loss
Illustrative previewA build-to-order ERPNext app that automates period-end exchange-rate revaluation and posts realized and
unrealized FX gain/loss entries per account and per currency.
ECOSIRE scopes, builds, installs, and supports it on your Frappe v15/v16 site.
What is Multi-Currency Revaluation & FX Gain/Loss?
A build-to-order ERPNext app that automates period-end exchange-rate revaluation and posts realized and unrealized FX gain/loss entries per account and per currency. ECOSIRE scopes, builds, installs, and supports it on your Frappe v15/v16 site. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Key Features
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your ERPNext.
- 3
Go live + support
You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Technical Specifications
- ERPNext Compatibility
- —
- License
- Licence confirmation required
- Python Requirement
- Python 3.10+
- Database
- MariaDB 10.6+
About this Product
If you run a multi-currency business, every month-end raises the same problem: foreign-currency receivables, payables, and bank balances are still carried at the exchange rates in force when each transaction posted, so your GL no longer reflects reporting-currency reality. ERPNext ships an "Exchange Rate Revaluation" DocType that handles the basics, but controllers quickly hit its edges — it revalues in one manual pass, it does not cleanly separate realized settlement differences from unrealized period-end restatement, rate fetching is limited, there is no scheduled run tied to your close calendar, and reversal handling on the first of the next period is a manual chore that gets missed under deadline pressure. The result is late closes, journal entries built in spreadsheets, and audit questions about how the FX numbers were derived.
ECOSIRE builds a proper Frappe app (its own module, not a fragile customization) that layers automated, auditable FX revaluation on top of ERPNext's accounting engine. At its core is a FX Revaluation Run DocType that captures the revaluation date, target currency, rate source, and the accounts in scope, with child tables recording per-account, per-currency balances, the applied rate, and the computed gain or loss. On submit, a server-side controller creates the corresponding Journal Entry against your configured unrealized FX gain and loss accounts, tagged back to the run for a complete audit trail. Realized differences on settlement (payment against invoice at a different rate) are posted separately from unrealized period-end restatement, so your income statement distinguishes the two the way an auditor expects.
The technical build is grounded in native Frappe primitives. Scheduler events registered in hooks.py trigger revaluation runs on your close cadence (monthly, or configurable); a whitelisted method fetches live and historical rates from exchangerate.host (or a provider of your choice) with caching and a manual-override fallback for controlled rates. Document events (on_submit, on_cancel) and server scripts drive the GL postings and guarantee that cancelling a run cleanly reverses its Journal Entry. Reversal automation posts the counter-entry on the first day of the following period so unrealized gains/losses do not double-count. Client scripts add in-form previews and validation, the Frappe REST API and custom whitelisted endpoints expose runs for integration, and role profiles plus permission rules restrict who can execute and submit a run versus who can only review it.
Because this is build-to-order, you are not downloading a generic marketplace app and hoping it fits your chart of accounts. We start with a short scoping call, confirm your currencies, GL account mappings, close calendar, and rate-source policy, then build your version, test it on a staging copy of your site, run UAT against your real balances, and deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope. You receive the full source, documentation, a training session for your finance team, and a post-go-live support window — and because it is a standard Frappe app on your bench, it upgrades cleanly with your ERPNext v15/v16 site.
What you get
- Installable source code for your version of the app, packaged as a standard Frappe app for your bench
- Installation and configuration on your site, including GL account mappings, currencies, rate source, and scheduler cadence
- Technical documentation covering DocTypes, hooks, whitelisted methods, and the revaluation/reversal logic
- User guide plus a live training session for your finance team on running and reviewing revaluations
- UAT on a staging copy of your site against real balances, with a documented rollback plan
- Post-go-live support window for defect fixes and questions after production deployment
- Git repository handover with full commit history and README for future maintenance
- Configuration record of rate-source policy, account mappings, and close-calendar settings for audit reference
Who this is for
Group Controller closing multi-currency books
Owns the month-end and quarter-end close for a business with FX receivables, payables, and bank accounts. Needs unrealized restatement and realized settlement differences posted correctly, auditable, and on the close calendar — not rebuilt in spreadsheets every period.
Finance Manager / Accountant running the close
Executes the revaluation, reviews per-account results before submitting, and reconciles the resulting Journal Entries. Wants an in-form preview, sane validations, and one-click reversal rather than manual counter-entries.
ERPNext Administrator / Frappe developer
Maintains the site and bench across v15/v16 upgrades. Needs a clean, standard Frappe app with proper hooks, whitelisted methods, permissions, and a git repo — not an untracked customization that breaks on the next migrate.
External / statutory auditor
Reviews how FX gains and losses were derived. Needs each Journal Entry traceable to a revaluation run with its rate source, timestamp, and account scope recorded.
How Multi-Currency Revaluation & FX Gain/Loss Compares
| Criterion | ECOSIRE | Custom Build | Competitor | ERPNext Native |
|---|---|---|---|---|
| Realized vs unrealized split | Posted to distinct GL accounts, clearly separated | Depends entirely on your developer's design | Often lumped together or simplistic | Basic revaluation, no clean separation |
| Scheduled runs | Scheduler events tied to your close cadence | Buildable but rarely prioritized | Usually manual-trigger only | Manual pass, no scheduling |
| Reversal automation | Auto counter-entry on first of next period | Manual to implement and test | Rarely handled automatically | Manual reversal by the accountant |
| Rate source | Live/historical fetch with caching + manual override | Whatever you wire up | Fixed provider or manual entry | Manual or single built-in feed |
| Fit to your chart of accounts | Built to your account mappings and currencies | Fully bespoke, at full build cost | Generic, you adapt to it | Generic core behavior |
| Audit trail | Every JE linked to its run, rate + timestamp recorded | Only if explicitly built | Varies, often thin | Standard JE trail, no run linkage |
| Support & upgrades | Post-go-live window; clean v15/v16 migrate | You own all maintenance | Vendor SLA varies; upgrade risk | Covered by ERPNext releases only |
| Delivery model | Build-to-order, staging UAT + rollback, one working week | Long, open-ended engagement | Instant install, fit-and-hope | Already in your site |
Frequently Asked Questions about Multi-Currency Revaluation & FX Gain/Loss
Is this an existing app I can download and install today?
No. This is build-to-order. ECOSIRE builds your version around your chart of accounts, currencies, rate-source policy, and close calendar, then installs and supports it. There is no instant download — you receive a tested app built for your ERPNext site.
How long does delivery take?
Typically one working week from confirmed scope. After a short scoping call we agree on currencies, GL account mappings, and rate source, then build, test on staging, run UAT against your real balances, and deploy. The exact timeline depends on how many currencies and account groups are in scope.
How does it differ from ERPNext's built-in Exchange Rate Revaluation?
ERPNext core gives you a single manual revaluation pass. This app adds scheduled runs on your close cadence, a clear split between realized settlement differences and unrealized period-end restatement, automated first-of-next-period reversal, live rate fetch with caching and override, per-account/per-currency granularity, and a full audit trail linking every Journal Entry to its run.
Where do exchange rates come from, and can we control them?
By default a whitelisted method fetches live and historical rates from `exchangerate.host` (or a provider you nominate), with response caching. You can override any rate manually before submitting a run when you need to use a controlled or board-approved rate, and the source is recorded on the run for audit.
What about support and upgrades to ERPNext v15/v16?
Every build includes a post-go-live support window for defect fixes and questions. Because it is a standard Frappe app with proper hooks and whitelisted methods — not a fragile customization — it migrates cleanly with your site. It targets Frappe/ERPNext v15 and v16, and we can quote ongoing maintenance or a version-upgrade pass separately.
Will it change our existing accounting data during deployment?
No. We build and test on a staging copy of your site first, run UAT against your real balances, and deploy to production with a documented rollback plan. Revaluation postings are ordinary submittable Journal Entries that can be cancelled and reversed like any other ERPNext GL entry.
Can we restrict who is allowed to run and submit a revaluation?
Yes. The app ships with role profiles and permission rules that separate execute-and-submit rights from read-only review access, so your controller can approve while accountants prepare, all enforced through Frappe's native permission system.
Related Modules

Moyasar Payment Gateway for ERPNext
A build-to-order Moyasar payment gateway for ERPNext that lets Saudi and MENA sellers accept mada, Apple Pay, STC Pay, SADAD and cards directly from ERPNext. ECOSIRE builds, installs and supports it against your v15/v16 site — request a quotation and we scope, build and hand over the source.

Multi-Outlet / Franchise POS Console for ERPNext
A build-to-order Frappe app that gives franchise and multi-outlet chains a single control tower over ERPNext POS locations — central menu and price pushes, per-outlet overrides, consolidated sales, and automated royalty billing. ECOSIRE scopes, builds, installs, and supports it for you.

MyFatoorah Payment Gateway for ERPNext
A MyFatoorah aggregator integration for ERPNext that turns GCC-local rails — KNET, mada, Benefit, Apple Pay — into a single connector with invoice-based payment links, webhook-verified settlement, and refund sync. ECOSIRE builds, installs, and supports it after a scoping call; it is not an instant download.
Multi-Currency Revaluation & FX Gain/Loss
A build-to-order ERPNext app that automates period-end exchange-rate revaluation and posts realized and unrealized FX gain/loss entries per account and per currency. ECOSIRE scopes, builds, installs, and supports it on your Frappe v15/v16 site.
- `FX Revaluation Run` DocType capturing revaluation date, target currency, rate source, and in-scope accounts with per-account/per-currency child tables
- Separate posting of realized settlement differences and unrealized period-end restatement to distinct GL accounts
- Automatic Journal Entry generation against configured unrealized FX gain and loss accounts on `on_submit`, tagged back to the originating run
- Reversal automation posts the counter-entry on the first day of the following period so unrealized amounts never double-count
