Your Entities Book in Three Currencies
Here's How to Consolidate Them Into One Report
A consolidated group report can be wrong and still look finished. The German entity's invoices are right, the UK entity's are right and the US entity's are right, and somewhere in the middle a subtotal has quietly mixed EUR, GBP and USD into a figure that no one can reconcile to a single currency. The error lives in the seams between the books, not inside any one of them, which is why it survives review. This article covers how that happens when a business runs several entities in different countries, and how to build the document layer of the consolidation so currency and entity stay separated until the controller decides how to convert.
Key Takeaways
- Every entity can be right and the group total can still be nonsense, because the mistake happens in the seams where EUR, GBP and USD get added together.
- No invoice validation can flag a wrong-entity posting, because the document itself is correct and only the group-level view is wrong.
- One column for entity and one for currency turn a mixed-currency subtotal from an accident into something you would have to do on purpose.
The Failure: A Subtotal That Quietly Mixes Currencies
Name the moment a multi-entity close starts going wrong and you usually land on a number nobody double-checked: the subtotal. A group with a German GmbH, a UK Ltd and a US LLC receives EUR 4,200 of German supplier invoices, GBP 1,300 of UK invoices and USD 5,900 of US invoices, and someone adds them into a column that reads 11,400. That total is not wrong the way a transcription error is wrong: it is a value no participant in the group could interpret, because three currencies were summed as if they were one. No single ledger line is incorrect. The error was born in the act of summing.
The twin failure is a document filed under the wrong entity. In an intercompany thread on r/Accounting, one practitioner listed why they spend their month re-posting entries that landed on the wrong set of books: "Payroll happens in company A but people support company B - gotta move it via Je. Po's/invoices out of the wrong company - gotta move it." (r/Accounting, 2024). The document-layer version is the same thing one invoice at a time: the UK bookkeeper handles a German supplier's bill, the file name says nothing about which entity it belongs to, and the EUR amount gets summed under UK Ltd.
This is a different job from the multi-currency extraction covered for single accounts. Pulling one Revolut or HSBC account's statements into a spreadsheet is about a single statement archive with its own balance. Here the unit of work is the consolidation across entities, where every entity can certify its own numbers and nobody certifies the seams. The rest of this article is about making those seams something you can see and check.
What "Correct" Looks Like: A Stated FX Basis and a Per-Entity Mapping
Before any fix, the target has to be defined, and a group close has three roles that define it differently. Collapsing them into one "finance team" is how the seams stay invisible.
| Role | Responsible for | Hands the next role |
|---|---|---|
| Entity bookkeeper | Closing the local books in the local currency, keeping vendor invoices as support | Invoices and statements, in the entity's own language and currency |
| Group accountant | Collecting every entity's documents and normalizing them into one table | A spreadsheet where each row carries entity and currency tags |
| Controller | Choosing the FX basis, reviewing the tagged table, posting translation and close entries | The consolidated numbers that go out |
"Correct" for the working table means two things. First, a stated FX basis. Under IAS 21 (IFRS) and ASC 830 (US GAAP), balance sheet items translate at the closing rate on the reporting date, while revenue and expenses translate at rates closer to the transaction date, typically a period average. A spreadsheet that multiplies everything by one rate is structurally wrong under both standards. Second, a per-entity mapping: every invoice row must be tagged with its entity and its original currency, so that a group subtotal can never accidentally mix them. The raw numbers do not need to be converted yet. They need to be kept apart, cleanly and visibly.
The software reality explains why the invoice layer is usually the most manual part of this. QuickBooks and Xero record foreign-currency transactions fine, but neither consolidates across entities natively; Xero's own guidance on multi-entity accounting notes that separate company files mean logging into multiple places and manually consolidating, "which can lead to mistakes and eat up time every month" (Xero, multi-entity accounting guide). The ERP consolidation modules that groups actually use, NetSuite OneWorld, Oracle Fusion Financial Consolidation and Close Cloud and SAP S/4HANA Group Reporting, start their automation at the trial balance instead. Nobody in that stack handles raw vendor invoices arriving in German, French and English except a human with a spreadsheet.
Where It Breaks: Each Entity Is Right, So Nothing Forces the Cross-Entity Check
The reason this stays broken month after month is that the failure modes are process problems, not data problems, and each one has a plausible excuse attached. Start with the wrong-entity allocation described above: an invoice is correct in every field, it is only sitting under the wrong company. No validation rule on the document flags it, because the document itself contains no error. The posting is wrong at the group level and undetectable at the document level.
Currency cross-checks have the same shape. Two entities that transact with each other book the same intercompany deal at different rates: one side uses the spot rate on the transaction date, the other applies the monthly average its local accounting rules mandate. Both numbers are defensible. The variance that appears at month end is not a mistake to be fixed, it is an expected difference that someone has to isolate and explain. In a reply to that r/Accounting thread, a senior intercompany accountant framed the diagnostic: "Is FX or a currency difference involved? These are typical issues with intercompany, especially across borders." (r/Accounting, 2026). The most experienced teams still spend hours on single variances; a newer staffer in the same thread described spending four hours on one item and "ending up with a $1,900 difference I couldn't close."
The deepest reason is organizational: nobody is responsible for the seams. In the same intercompany discussion, a commenter summed up why a mismatch can sit unresolved for weeks: "Both sides claiming that their numbers are right." (r/Accounting, 2024). Each entity can certify its own ledger, and nothing forces the cross-entity check, so the check only happens when someone discovers that EUR and USD were counted together, or when the group number fails to tie.
The cost of that discovery is measurable. APQC's benchmarking of more than 2,300 organizations, reported in CFO.com's Metric of the Month series on financial close, puts the median monthly close at 6.4 calendar days, with the top quartile at 4.8 days and the bottom quartile at 10 days or more (APQC via CFO.com). Multi-entity, multi-currency and intercompany activity is precisely what pushes groups toward the bottom of that range. The same manual pattern shows up even at the top of the market: PwC's 2025 Global Treasury Survey found that 52% of companies with USD 1 billion to 10 billion in revenue still manually collect and consolidate forecasting data, and 38% of larger companies do the same (PwC, 2025 Global Treasury Survey).
The Fix: Normalize Currency and Entity, Then Attach Each Document
Two capabilities of the extraction tool map onto the two steps that keep failing by hand: normalizing every row to carry its entity and currency, and attaching a split-up document back to a single record. Each maps to a specific setting, not to the tool in general.
The first capability is Custom Column Extraction. Instead of drawing boxes around fields, you type the column names you want and the AI locates each value by what it means rather than where it sits on the page. The column names you type become the headers of the final spreadsheet, and the same definition works across vendors whose layouts and languages differ. For a group close, define the set once, for example Entity (options: US LLC, UK Ltd, DE GmbH), Currency (options: USD, GBP, EUR), Supplier Name, Invoice Number, Invoice Date and Total Amount. Entity and Currency are inferred columns: the invoice does not print "GBP" next to every amount or "DE GmbH" above every line, so the AI reads the document header, the registered company name, the address and the currency symbol, and fills the tag in for every row. That is the config that normalizes currency and entity. A German invoice that arrives in the UK bookkeeper's batch still extracts with Currency: EUR and Entity: DE GmbH, because the extraction reads the document, not the upload order. With a Currency column on every row, a group subtotal is structurally protected: summing by currency becomes a filter, not a memory task.
The second capability is Multi-Page Merge. In template settings you can group a batch of extracted results so that one logical document that arrived split across pages or files folds back into a single row: start a new group whenever a tracked column's value changes, match all pages that share a reference number, or group by a fixed number of uploads. Recurring information, like the entity name or invoice number, carries through to every line in the group, and when a field conflicts across pages you choose keep-first, keep-last, concatenate or split. That is the config that attaches a document to its entity. A German supplier's invoice scanned across three pages, header on page one, line items on page two, totals on page three, is one record after processing instead of three rows that a human has to glue together, and the entity and currency tags ride along from the shared reference. A multi-page monthly statement from a UK supplier likewise becomes one row per period, carrying the same GBP tag, instead of one row per page.
The workflow puts each role on the step it owns:
Here is the tool handling a batch of invoices, with the same column set ready to read across vendor formats:
Files are processed securely and not stored.
What the controller gets is a table where the consolidation assumptions are visible instead of implied. Each row carries an invoice number, a supplier, an entity and a currency, so "the German entity's spend" is a filter and "the EUR subtotal" is a filter, not a memory of which file was which. Because the currency tag is always present, a mixed-currency total can only exist if someone deliberately sums across filters. That is the property an auditor can trace and an accountant can trust. The direct route for a single supplier's set is turning one invoice into a spreadsheet row, and the commercial invoice workflow shows the same columns applied to export documents.
What This Setup Still Cannot Automate
The tool keeps currencies and entities clean; it does not choose the conversion approach, and it should not be expected to. Under IAS 21 and ASC 830, balance sheet items translate at the closing rate while income statement items use a period average, so "convert everything at one rate" is not a simplification a controller can accept. Choosing the rate basis, applying it consistently and posting the translation and cumulative translation adjustment entries stays with the controller and the group accountant. The honest division of labor: the tool makes the raw material one clean table in original currencies, and the conversion policy is the accounting judgment on top of it.
This is also not an intercompany elimination engine and not an ERP. The table feeds the ledgers, it does not replace the consolidation machinery in NetSuite OneWorld, Oracle FCCS or SAP Group Reporting, which still eliminates intercompany balances and produces statutory packs. Those modules expect trial balances; the gap this closes is the one between the entity's inbox and the trial balance, which is exactly the layer the big systems leave manual.
One more limit is worth naming: the extraction transcribes what the document says. A deliberately inflated invoice is extracted as the inflated total, and the wrong-entity tag only works if the document carries the entity's identity in its header. Verification of what was actually ordered and paid remains a bookkeeping job, which is why the entity bookkeeper still reviews before the table goes up. What changes is that the review now has something to review: a single table sorted by entity and currency, instead of a stack of files in three languages. The batch pattern for the voucher trail is the same one used for diagnosing multi-language extraction accuracy, and teams that already consolidate one account's statements will recognize the mechanics here applied across entities (single-account multi-currency statement extraction is the one-account version of this problem).
Multi-Currency, Multi-Entity Consolidation: Frequently Asked Questions
Can it convert EUR, GBP and USD into my reporting currency automatically?
No, and that is deliberate. The tool extracts and preserves the original currency in a Currency column; it does not translate numbers. Conversion stays with your team because translation is a policy decision: IAS 21 and ASC 830 require different rates for balance sheet items versus income statement items, so no single conversion factor is the "right" one. What the tool guarantees is that every row still carries its original currency, which is the precondition for any defensible conversion step.
Does the same column setup work when invoices arrive in different languages?
Yes. Because extraction locates values by meaning rather than by template position, the column names are the contract and each language is just another layout that satisfies it. A German invoice and a French invoice both satisfy "Supplier Name" and "Total Amount" even though the labels on the documents differ. That is the difference between semantic extraction and layout-based OCR, and it is why one column set replaces per-vendor templates.
How does the tool know which entity an invoice belongs to if it arrived in the wrong batch?
The Entity column is inferred from the document itself. The AI reads the registered company name, address or currency in the header and tags every row with the matching entity from your list of options, regardless of which files it was uploaded with. A German bill handled by the UK bookkeeper still extracts as Entity: DE GmbH. If a document genuinely carries no company identity, the practical fix is to keep the entity name in the file name or add it in a note at upload time.
What if a supplier's invoice was scanned across three pages?
Turn on Multi-Page Merge and group by the shared reference number: pages carrying the same invoice number fold into a single row, with fields filled from whichever page has them. Recurring values like the entity and the invoice number carry through automatically, and the keep-first conflict rule resolves the header fields that later pages repeat. The result is one invoice record instead of three page records.
Does this replace our ERP consolidation module?
No. Consolidation modules like NetSuite OneWorld, Oracle FCCS and SAP Group Reporting operate on trial balances: they eliminate intercompany balances and produce statutory statements. This tool operates one layer lower, turning the entity's raw vendor documents into the clean, entity-tagged table that feeds those systems. For a group without an ERP consolidation module, the tagged spreadsheet is a working substitute for the roll-up, with the controller still responsible for the FX basis and close entries.
Who should upload which files?
Each entity's bookkeeper uploads or forwards that entity's own invoices into the shared queue. Because the column set is shared and the Entity tag is read from the document, it does not matter whose hands a file passes through before it lands in the batch. The output is one table where every row means the same thing, which is the property a multi-entity close depends on.
Multi-entity consolidation goes wrong exactly where nobody is looking: between the books, not inside them. The shift is to make that gap a visible, checkable table where every invoice row carries its entity and its original currency, so a subtotal can no longer silently mix them. The controller still sets the FX basis and posts the close, and intercompany elimination still has its own machinery, but the raw material finally arrives clean. Try the flow with your own entities' invoices, and see whether the next close can start from a table instead of a stack of files in three languages.