Multi-entity AR: managing receivables across subsidiaries and currencies

Multi-entity AR is managing receivables across several legal entities that keep separate books but share customers, systems, or a parent company. Each entity issues its own invoices, collects on its own terms, and reconciles its own ledger. The group then has to consolidate all of it into one number that auditors and the board can trust.

It sounds like single-entity AR repeated a few times. It is not. The moment two of your entities sell to the same customer, or invoice in different currencies, or lend each other money, the work stops adding up and starts multiplying. This guide covers where the complexity actually lives and how to keep it under control.

What makes multi-entity AR hard

The difficulty is rarely the volume of invoices. It is the relationships between entities that a single-entity team never has to think about.

Each entity has its own chart of accounts, its own customer master, and often its own ERP instance. A customer set up as "ACME-001" in one entity might be "ACME Corp Ltd" in another, with no shared ID linking them. So you cannot see, in one place, what a customer owes the whole group. You also cannot apply a payment that covers invoices from two entities without splitting it manually and posting to each ledger separately.

Terms drift too. One subsidiary sells net 30, another net 60, a third grants a local distributor net 90 by habit. When the group sets a DSO target, those differences hide inside the average and nobody can tell which entity is actually slow.

Intercompany and shared-customer complexity

Two problems get conflated here, so separate them.

Intercompany receivables are when your entities owe each other. Entity A ships goods to Entity B and raises an invoice. On A's books it is a receivable; on B's books it is a payable. At the group level the two net to zero, so they must be eliminated in consolidation. If they do not match to the cent, often because of timing, FX, or a missed posting, you get an intercompany mismatch that holds up the close.

Shared-customer complexity is different. A single external customer buys from three of your entities. That customer is a real receivable to the group, not eliminated, but it shows up as three separate balances on three ledgers. Chasing it well means knowing the customer's total exposure while still collecting each invoice on the entity that issued it, because that is the entity with the legal claim.

Get these two backward and you either eliminate real external revenue or leave intercompany noise in the group number. Both are audit findings.

The shared-customer case also creates a collections trap. If three entities chase the same customer independently, that customer gets three separate reminders, on three cadences, often contradicting each other. The customer's AP team sees a group that cannot get its own house in order, and uses the confusion as a reason to delay. Coordinating the outreach, while still collecting on the entity that holds the legal claim, is the difference between looking like one company and looking like three.

Currency and localization challenges

Cross-border entities invoice in local currency, but the group reports in one. That gap creates work at every step.

• Translation. Each entity's AR balance gets translated to the reporting currency at period-end rates. Move the rate, move the consolidated receivable, with no change in what any customer actually owes.
• FX gains and losses. An invoice raised in EUR and paid 45 days later settles at a different rate. The difference is a realized FX gain or loss that has to be booked, not buried in the AR balance.
• Local invoicing rules. Many countries mandate specific invoice formats, tax fields, or government e-invoicing clearance before an invoice is even valid. An invoice that fails local rules will not get paid, and the delay looks like a collections problem when it is really a compliance one.
• Language and channel. A reminder that lands well in one market reads as rude in another. Local customers expect local language, local payment methods, and often a local portal.

Consolidated AR reporting

The group wants one aging report, one DSO, one bad-debt picture. Producing it cleanly depends on the data underneath being right before you roll it up.

A trustworthy consolidated AR report does three things. It translates every entity to the reporting currency on a consistent basis. It eliminates intercompany balances so they do not inflate the total. And it preserves the ability to drill from the group number back down to the entity, the customer, and the invoice, because a board number nobody can trace is a number nobody trusts.

The common failure is consolidating in a spreadsheet after the fact. By the time the numbers are keyed in by hand, the entities have moved on, the cutoffs no longer match, and the rollup is stale the day it is finished. Worse, a manual rollup hides errors. A balance translated at the wrong rate, an intercompany item eliminated twice, a customer counted in two entities under different IDs, none of these announce themselves in a spreadsheet. They surface during the audit, when they are most expensive to explain.

Automating AR across entities

The fix is to do the cross-entity work where the data lives, continuously, instead of reassembling it at period-end. A system that works across entities can match a payment to invoices on more than one ledger and post to each correctly. It can recognize that "ACME-001" and "ACME Corp Ltd" are the same customer and show their combined exposure while still collecting per entity. It can flag intercompany balances that do not match before they reach the close.

The goal is not to merge the entities. They stay legally and financially distinct for good reasons. The goal is to remove the manual reconciliation between them, so the group sees one accurate picture without anyone exporting six ledgers and stitching them together by hand.

Standardizing process without losing local control

The tension in multi-entity AR is always central consistency against local autonomy. The parent wants standard terms, standard cadence, and standard reporting. The local entity knows its customers, its language, and its regulations, and resents a process designed for headquarters.

Resolve it by standardizing the layer that should be common and localizing the layer that should not. Definitions, metrics, escalation rules, and the consolidated report belong at the group, so everyone counts DSO the same way and a "90 days past due" account means the same thing everywhere. Tone, language, channel, payment method, and local compliance belong to the entity, because that is where the customer relationship actually sits. A good operating model lets the center see and steer without forcing every subsidiary to collect like the one next door.

How Rex runs AR across your entities

Rex works the receivables ledger of every entity at once, as one agent rather than a copy per subsidiary. It collects each invoice on the entity that issued it, on that entity's terms and in that entity's currency, while reading a shared customer's total exposure across the group so its outreach reflects the whole relationship. It applies payments that span ledgers, posts to each correctly, and surfaces intercompany balances that fail to match before they stall the close. Group-level DSO, aging, and unapplied cash stay current without anyone rebuilding them in a spreadsheet.

Local control stays intact. Rex follows each entity's terms, language, and compliance rules, and escalates the judgment calls, a disputed intercompany charge or a strategic shared customer, to the right person at the right entity.

See how Rex runs collections across every entity on one ledger.