Custom ERP With Multi-Currency and Multi-Entity Accounting: Feasibility, Cost, and What Actually Breaks

What this looks like once real books run on it

It is day four of the December close. Both subsidiaries' trial balances are in balance. Every local report ties. The consolidated balance sheet is out by 419.47 USD, and nobody can find it.

Here is what happened. The US parent, functional currency USD, lent 100,000 USD to the UK subsidiary, functional currency GBP. The UK entity recorded the payable at the day's rate of 0.7900 and stored 79,000 GBP. That is the whole bug: it stored 79,000 GBP and threw away the fact that this is a debt denominated in USD. At month end the closing rate is 0.7867. A correct system revalues that USD-denominated monetary liability and books a 330 GBP gain. This one did not, because it had nothing left to revalue against. So consolidation translates 79,000 GBP back at the closing rate, gets 100,419.47 USD, and the intercompany elimination against the parent's 100,000 USD leaves 419.47 sitting in the void.

Both sets of books balance. The consolidation does not. That residue grows every month and every rate move, and someone plugs it by hand until they leave the company. The naive version of this capability is not "we added a currency column." It is a schema that cannot answer the question "in what currency was this obligation actually incurred," and everything downstream inherits that.

Every amount is three amounts

IAS 21 and ASC 830 both draw the same three lines, and a competent ledger stores all three on every posted line. Transaction currency is what the document was written in. Functional currency is the entity's own operating currency, and it is a determination, not a preference: you have to argue it and document it. Presentation currency is whatever the consolidated report is rendered in. One journal line therefore carries an amount, a currency, a functional amount, and the rate and rate date used to get there. Not derivable at read time. Stored, because the rate that applied on 3 March is a fact, and facts do not get recomputed.

Storage: never a float. Use Postgres NUMERIC or DECIMAL(19,4), or integer minor units with an explicit exponent table. And the exponent is not always 2. ISO 4217 gives JPY zero decimals, KWD, BHD, JOD, TND and OMR three, and CLF four. A system that hardcodes two decimals will silently round a Kuwaiti dinar invoice and produce a rounding difference in a jurisdiction that audits rounding differences.

Then allocation rounding. A 100.00 invoice split across three cost centres is 33.33, 33.33, 33.34. Pick a method, largest remainder is the usual one, apply it in one place, and make the residual land on a designated line rather than scattering. If three modules each round independently, the trial balance drifts by cents, and cents are what makes a controller stop trusting the system.

Rates are a versioned dataset, not a lookup

You do not have "the EUR rate." You have spot, daily close, monthly average, historical, and budget rate, and each is used for a different purpose. Balance sheet monetary items translate at closing rate. Income statement lines translate at the period average. Equity translates at historical rate. The difference is not an error: it is the cumulative translation adjustment, and it belongs in other comprehensive income, not in a suspense account.

Sources matter. ECB reference rates publish once per TARGET business day around 16:00 CET, which means no weekend rates and no rate on Good Friday, so your rate table needs an explicit carry-forward rule an auditor can read. If you buy from OANDA, Xignite or Open Exchange Rates, decide bid, ask or mid and write it down. Store rates directionally with the quoted pair, because 1 divided by a rounded rate is not the rate the bank used, and that mismatch surfaces on bank reconciliation.

The hard one: rate corrections. A provider republishes a bad rate three days after 400 documents posted against it. A competent build makes rates effective-dated and versioned, refuses to silently re-translate posted transactions, and instead offers a re-run of the revaluation with a reversing entry. Realized FX, the difference between invoice rate and payment rate, hits P&L on settlement. Unrealized FX comes from the period end revaluation run and only touches monetary items. Inventory, prepaid expenses and fixed assets are non-monetary and stay at historical rate. Teams that revalue everything produce beautiful, wrong numbers.

The ledger must be append-only and gapless at the same time

Posted journal lines are never updated. Corrections are reversing entries. That is not a style choice, it is what makes the audit trail defensible under SOX, German GoBD, and French FEC rules. Enforce the double-entry invariant in the database with a deferred constraint that sums debits and credits to zero per journal, per entity, per currency, so no application bug can write an unbalanced batch.

Now the tension. Several jurisdictions require gapless sequential document numbering, France and Italy among them, and a Postgres SEQUENCE is explicitly not gapless: it burns numbers on rollback. So you need a counter table with SELECT FOR UPDATE or an advisory lock, which serializes posting per sequence and puts a hard ceiling on throughput. That ceiling is a design decision the buyer needs to make consciously: partition sequences per entity, per document type and per fiscal year, and know your posts-per-second number before you sign anything. Nobody quotes for this, and it is the thing that pages you at 3am on the last day of the quarter when 90,000 invoices try to post through one row lock.

Intercompany and consolidation: where the plug lives

Intercompany means every cross-entity transaction generates automatic due-to and due-from balancing entries in both books, tagged with the counterparty entity, so elimination at consolidation is mechanical rather than a spreadsheet. Add an intercompany matching run that reports unmatched pairs before close, because the one that always breaks is a transaction posted in one entity and never mirrored.

Consolidation itself needs ownership percentages, non-controlling interest, sub-consolidation for multi-level group structures, and a decision on equity method versus full consolidation per holding. It also needs a chart of accounts strategy: a global COA with a mapping layer to local statutory charts, or parallel books. If you run US GAAP and a local GAAP in parallel, that is multi-book, and multi-book roughly doubles both the posting layer and the reporting layer. Ask early, because retrofitting a second book later means every posting rule gets rewritten.

Close, calendars, and the backdated entry

Each entity has its own fiscal calendar. India and Japan run April to March. Retail clients want 4-4-5 periods. Period locks are per entity, per module, not global, so AP can be closed while GL is still open. And then someone posts backdated into a closed period.

Answer that question before you write code, because there are only three honest answers: reject it, reopen the period under a named approval with an audit record, or route it to a catch-up period. Whichever you pick, backdated entries invalidate your balance snapshots. You cannot compute a trial balance across 40 entities and five years by scanning raw journal lines: you need a materialized balances table keyed by account, entity, period and currency, which means you also need cache invalidation that knows a March entry landing in July dirties every period from March forward.

The statutory output is where scope quietly doubles. Each country is its own project: SAF-T for Portugal, Poland, Norway and Romania, FEC for France, GoBD exports for Germany, CFDI clearance for Mexico, SdI and FatturaPA for Italy, IRN and GST e-invoicing for India, Peppol BIS Billing 3.0 across the EU with ViDA mandates landing behind it. Plus US sales tax nexus, which realistically means integrating Avalara or Vertex rather than building rate tables. None of this is configuration. All of it is delivery.

Cost and timeline, honestly

Across Digital Heroes projects, the bands are consistent. A focused build of multi-currency and multi-entity accounting inside a product that already exists runs $15,000 to $60,000. Delivered as part of a first release it is $50,000 to $130,000 over 10 to 16 weeks. A full platform with consolidation, statutory books and per-country compliance is $150,000 to $350,000 over 6 to 12 months.

What moves this specific number: retrofitting onto a single-currency schema, where every historical row has to be backfilled with a transaction currency and a rate and every existing report rewritten, reliably eats 3 to 5 weeks of the estimate before a single new feature ships. Each additional statutory jurisdiction with an e-invoicing mandate adds roughly $8,000 to $25,000, and that cost repeats forever as mandates change. Multi-book roughly doubles the reporting layer. Consolidation with partial ownership and non-controlling interest adds 2 to 4 weeks. Opening balance migration, including establishing an opening cumulative translation adjustment your auditor will accept, is usually underestimated by half. Entity count barely matters. Distinct functional currencies and distinct jurisdictions are what you are paying for.

When you should NOT build this

If you are an operating company that sells things and needs books, buy NetSuite OneWorld, Sage Intacct, or Microsoft Dynamics 365 Business Central, and spend the money on a good implementation partner instead. They already have automatic intercompany, consolidation with non-controlling interest, revaluation, localizations and statutory exports, all maintained by people whose full time job is tracking when Italy changes its schema. Rebuilding that is a decade of accumulated regulatory trivia you will pay for twice.

Build custom in exactly two cases. First, the ledger is the product: marketplaces paying out in 30 currencies, fintech, embedded wallets, anything where accounting is the thing customers buy. Second, your volume or model breaks the SaaS envelope, at which point look at Modern Treasury Ledgers, Formance, or TigerBeetle before writing your own. Know the tradeoff going in: TigerBeetle transfers cannot cross ledgers, so multi-currency means one ledger per currency plus linked transfers for the FX leg, which is a real architecture decision, not a footnote. And even then, most teams that build a custom ledger still keep an off-the-shelf GL for statutory filing. That is the correct answer more often than vendors admit.

How to brief and vet a developer for this

Five questions separate people who have shipped this from people who have read about it.

One: name the three currencies on a journal line and what each one is used for. If you do not hear transaction, functional, presentation, stop.

Two: how do you store an amount, and what do you do with JPY and KWD. Correct answers are NUMERIC or integer minor units with an ISO 4217 exponent table. "Float" or "two decimals" ends the interview.

Three: two entities with different functional currencies, one intercompany loan. At close, why might the elimination not net to zero, and where does the difference go. Someone who has shipped this will say cumulative translation adjustment and other comprehensive income without pausing.

Four: how do you produce gapless document numbers under concurrent posting, and what is the throughput ceiling. If they say "a database sequence," they have not read the requirement.

Five: an entry lands backdated into a closed period. Walk me through it. Listen for period reopening controls and balance snapshot invalidation, not just "we allow it."

Then a sixth, softer one: which statutory export have you actually produced, and for which country. FEC, SAF-T and CFDI leave scars. People who have them will tell you a story. People who have not will describe a plan.