Multi-company, multi-currency accounting: ledgers, intercompany, FX

Every legal entity keeps its own complete ledger, in its own country's rules and its own functional currency; there is no such thing as one set of books for a group. Money and services that move between your companies are invoiced like any other sale, with VAT decided as if the counterparty were a stranger. Foreign-currency invoices are converted once at the invoice date, and the difference to the rate at which cash actually arrives is an exchange gain or loss booked on its own. Those three rules cover most of what a founder with two companies or three currencies needs; consolidation and transfer pricing are where a professional takes over.

One legal entity, one ledger — always

A German GmbH and its French SAS are two taxpayers with two balance sheets, two VAT numbers and two sets of national rules. Their books must be separable at any moment, because each will be audited, taxed and possibly sold on its own. Sharing one ledger with a "company" column looks convenient and fails the first time an auditor asks for one entity's trial balance.

Separate ledgers mean: a separate chart of accounts (or at least a separate instance of one), separate invoice numbering — a sequence that is gapless within the entity —, separate bank accounts and separate closing dates. The people can overlap; the records cannot. A holding company with no operations is still an entity with a ledger, even if it has ten transactions a year.

What can be shared is above the ledgers: one login, one customer directory copied into each entity, one reporting view that reads all of them. The reporting view is a convenience for the owner; it is not a consolidation and it is not what gets filed.

Intercompany transactions are real transactions

When the holding pays the subsidiary's software bill, or the German company lends engineers to the Belgian one, something taxable has happened between two taxpayers. It is recorded twice: as a bill in one ledger and as an invoice in the other, with matching amounts and dates, and the two balances must agree at every close.

The VAT follows the ordinary place-of-supply rules. For B2B services "the place of taxation is the place where the customer is established", so a service from the German entity to the Belgian entity is a cross-border B2B supply: no German VAT, the Belgian entity self-assesses under the reverse charge, and both VAT numbers appear on the invoice. Because the counterparty is your own company, it is tempting to skip the VIES check; do not. VIES "enables companies to obtain rapidly confirmation of the VAT numbers of their trading partners" and a stored check result is the evidence an auditor asks for, related party or not.

Intercompany invoice

A normal invoice from one entity to another, at a price that would hold between unrelated parties. The price question — transfer pricing — is a tax matter and requires professional confirmation above trivial amounts.

Intercompany loan

A receivable in one ledger, a liability in the other, with interest at a defensible rate. Interest-free loans between related companies are often re-characterised by tax authorities.

Recharge / cost allocation

A shared cost paid by one entity and partly re-invoiced to another. Still an invoice, still VAT-relevant, still reconciled.

Capital contribution / dividend

Equity movements, not sales. They bypass the P&L but need their own documentation (shareholder resolutions) in both ledgers.

At month end, the intercompany receivable in entity A must equal the intercompany payable in entity B. A difference means a missed invoice, a currency mismatch or a timing gap — and it is far cheaper to find in the month it occurs than at the annual close.

Currency conversion: the rate on the day, once

Each entity has one functional currency — under IAS 21 "the currency of the primary economic environment in which the entity operates" — and every foreign-currency transaction is translated into it at the exchange rate on the transaction date. A USD invoice issued by a EUR company is therefore booked in EUR, at the rate of the invoice date, and stays at that amount as a sale forever.

Which rate? For euro-area companies the ECB's euro foreign exchange reference rates are the common source; they are "usually updated at around 16:00 CET every working day" and, the ECB stresses, are "published for information purposes only". National tax authorities also publish rates for VAT purposes, and some countries prescribe which one to use for the VAT amount on an invoice — a national detail that requires professional confirmation. Whatever source you use, use it consistently and record which rate was applied on each document.

Two things people get wrong: converting the invoice at the payment-date rate (that hides the exchange difference inside revenue), and re-converting a paid invoice when the rate moves later (a paid invoice is closed; the rate no longer matters to it).

Realised and unrealised exchange differences

A realised difference is the gap between the amount you booked at the invoice date and the amount you actually received or paid, in your functional currency. An unrealised difference is the same gap, computed on an open item at the closing date, before any cash has moved. Both go to the profit and loss under most frameworks, but they are booked separately and the unrealised one is reversed or re-measured at the next close.

Only monetary items — receivables, payables, cash, loans — are restated at the closing rate. Revenue, expenses and fixed assets keep their historical rate. Whether unrealised gains may be recognised at all, or only losses, differs between national GAAP and IFRS and between countries; Germany's HGB, for example, is more restrictive than IFRS on unrealised gains. Which rule applies to your entity requires professional confirmation.

Bank feeds in several currencies

A foreign-currency bank account is a monetary item in that currency: its balance is restated at each close, and every movement is converted at the rate of the day. A EUR account that receives a USD payment shows only the EUR the bank credited — the bank's conversion is the realised rate, and the bank's FX fee is an expense.

Practical rules that keep this from becoming a mess:

1. Give each entity its own bank accounts. Paying one company's supplier from another company's account creates an intercompany loan you now have to document.
2. Connect every account to its entity's ledger through a bank feed, so that the conversion the bank actually applied is what gets booked, not a rate looked up later.
3. Match payments to invoices by reference and amount in the invoice currency; let the ledger compute the difference in the functional currency.
4. Restate foreign-currency balances at the closing rate as one journal entry per currency per close, and reverse it at the start of the next period if your framework works that way.

How KRONENWERK handles this

KRONENWERK is built around the entity: each company has its own ledger, its own settings and its own country rules, and one login can hold several companies in Germany, France, Belgium, Poland (limited), Canada and the United States. SUPPORTED WITH LIMITATIONS

• Multi-company. Separate ledgers, invoice sequences, bank connections and e-invoice formats per company; switching between companies in the same account. See several companies.
• Multi-currency. Invoices and bills in foreign currencies, converted into the company's ledger currency and recorded with the rate applied; payments matched in the invoice currency with the difference booked as an exchange difference. See the ledger.
• Intercompany invoices are ordinary invoices from one company to another, with the tax verdict decided from the two countries and both VAT IDs checked against VIES at issuance — the reverse charge is recorded on the invoice, not assumed.
• Bank feeds through Enable Banking for European banks and Plaid for Canadian and US banks, per company.
• One company per API key. A key issued in one company can only read and write that company; a group with three entities uses three keys, and GET /me tells you which company a key belongs to. Group reporting across entities is done by your own code reading each company's reports (GET /reports/outstanding, or the MCP tools get_profit_and_loss and get_balance_sheet) with the matching key.

For the invoicing side of a cross-border group, see cross-border e-invoicing; for the founding-stage questions, accounting for startups in Europe.