Why Multi-Currency and Multi-Entity Payments Are a Struggle in Dynamics 365 Business Central

A finance director we talked to recently inherited three subsidiaries in eighteen months, one through acquisition, two through international expansion. Each ran its own currency inside Business Central. Each closed cleanly at month end. And each, it turned out, was collecting customer payments through a completely different setup: one on a legacy gateway nobody remembered configuring, one on a personal PayPal-adjacent account someone set up to get the entity live faster, and one still invoicing by check because nobody had gotten around to it.

The general ledger told a unified story. The payment side told three separate ones.

This is a strange and specific kind of pain, because Business Central actually does multi-currency and multi-company well. Its native multicurrency functionality lets organizations process sales and purchases in whatever currency they need, using the most recent exchange rate or one updated manually per document. Set up your companies, assign your currencies, and the accounting logic holds together the way it's supposed to. That's a real strength. The platform was not the problem for this finance director. Payments were.

The Gap Between Ledger and Gateway for Multi-Entity Payments

Here's the disconnect: Multi-currency accounting is about how transactions are recorded and reported once money has moved. Multi-entity payment processing is about how that money actually gets collected in the first place, from a customer, in their currency, attributed to the correct legal entity, without someone reconciling three different systems by hand every week. Business Central was built to do the first part exceptionally well. It was never built to do the second part at all. Payment acceptance was always meant to live outside the ERP core, handled by a connector or gateway layered on top.

The trouble is what most organizations layer on top. The default pattern, especially for businesses that added entities through acquisition rather than by design, is one gateway account per entity. Each subsidiary gets its own merchant ID, its own dashboard, its own settlement schedule. This isn't a workaround some IT team invented out of laziness. Documented gateway compatibility requirements show that many gateways only support multi-entity setups if each entity authenticates through its own unique merchant ID, with a single merchant ID serving multiple entities in one environment rarely on the table. The constraint is coming from the gateway side, not from anyone's poor planning.

Multiply that constraint across three, five, or a dozen entities, and the operational cost becomes obvious pretty quickly. A customer who pays two subsidiaries under the same parent company has to enter their card twice, into two systems that don't talk to each other. A treasury team reconciling deposits across entities is stitching together settlement reports from gateways that may not even use the same reporting format. And if leadership decides to switch processors for cost or service reasons, that decision now has to be executed three, five, or a dozen separate times, because the card data lives inside each gateway's own vault rather than somewhere independent of it.

Why Multi-Entity Payments Get Worse, Not Better, With Growth

The instinct is to assume this smooths itself out as a company matures and its systems get more sophisticated. Usually the opposite happens. An acquisition means inheriting whatever payment setup the acquired entity already had, on whatever timeline the integration team can manage, and that timeline is rarely payments-first. Geographic expansion is its own animal entirely: new currencies, new local payment preferences, sometimes a regulatory reason a domestic gateway account simply can't serve a given market at all.

Juniper Research projects the value of B2B payments will grow 40% by 2028, up from 89 trillion dollars in 2024, driven substantially by digital payment adoption in developing markets. That growth is disproportionately cross-border and cross-currency, which means more organizations are going to hit this exact wall, not fewer.

Some of the broader ERP ecosystem has responded to the accounting side of multi-entity complexity directly. Binary Stream's Multi-Entity Management add-on, for instance, exists precisely to consolidate intercompany transactions and multi-currency reporting across legal entities inside Business Central. That's genuinely useful work, and it solves a real problem: the general ledger side of multi-entity complexity. It doesn't touch the payment acceptance side. A business can have flawless intercompany consolidation and still be running five disconnected gateway relationships underneath it.

What a Connector-First Approach Actually Changes

The more durable fix isn't adding another layer of reconciliation software. It's decoupling payment acceptance from the entity-and-gateway pairing altogether, so that adding a new subsidiary or a new currency doesn't mean standing up a whole new payment relationship from scratch. A gateway-agnostic connector sitting across 120+ payment gateways means an organization isn't locked into whichever processor happened to come bundled with a given entity. If one subsidiary's existing merchant account is worth keeping, bring it forward instead of replacing it. If a new entity needs a different gateway for regional coverage, add it without rebuilding the payment infrastructure for every other entity in the group.

Card vaulting matters here too, more than people expect going in. When tokenized card data sits in an independent vault rather than inside any single gateway's system, a customer's payment method can follow them across entities and currencies without re-entering anything, and switching processors later doesn't mean losing that data or asking every customer to re-key their card. For associations and membership organizations running multiple chapters or regions under one umbrella, this same logic applies almost identically to how dues and event payments get collected across those units.

What This Means for Teams Evaluating Their Multi-Entity Payments Setup Now

If your organization runs more than one company or currency inside Business Central, the ledger being clean is not evidence that payments are handled well. It's worth asking a narrower question: if we added a fourth entity tomorrow, would payment acceptance take a day to configure or a quarter? For most multi-entity businesses today, honestly, it's closer to a quarter, and that gap tends to stay invisible until someone tries to move fast and can't.

The practical starting point isn't a full platform migration. It's an inventory: how many gateway relationships currently exist across your entities, where the card data for each actually lives, and whether adding the next entity or currency would mean repeating that setup work or simply extending what's already there. For teams that see USTPay's overview for Business Central as a useful reference point in that evaluation, the same question applies regardless of which solution they land on: does the payment layer scale the way the ledger already does, or does every new entity mean starting over.