Multi-entity corporate cards explained

Your card programme may work well for one entity. Add a second legal entity and it can start creating extra work at month-end: allocation decisions, intercompany recharges, and journal entries that did not exist before.

The problem usually appears when one entity pays for a cost that belongs to another. If a parent company's card pays for a subsidiary's software, for example, finance may need to allocate or recharge that cost before the accounts are complete.

This guide compares eight multi-entity corporate card and spend-management providers against five operational capabilities that can reduce that work. It also looks at funding structures, entity mapping, ERP integrations, foreign-currency spend, supporting documentation, and cost considerations for a multi-entity group.

Key takeaways

• A multi-entity card programme is most useful when cards, settlement, permissions, accounting connections, and currencies can be associated with the correct legal entity.

• Funding models differ between providers and can affect repayment responsibility, onboarding, and how quickly a new entity can begin spending.

• Mapping spend to the correct entity before or at the point of purchase can reduce the allocation and intercompany work finance has to resolve later.

• ERP support varies significantly, so subsidiary or entity-level posting should be tested rather than assumed from an integration logo.

• International groups should compare card currencies, FX costs, local product availability, and supporting-document requirements for each entity.

• Pricing can scale by users, entities, modules, transactions, integrations, or foreign-currency spend, so model the total cost against your actual group structure.

• Provider functionality changes over time, so material requirements should be confirmed against current product documentation before you commit.

What makes a corporate card multi-entity?

A multi-entity corporate card programme lets finance manage cards and transactions across several legal entities while keeping the relevant spending, permissions, settlement, and accounting workflows separated by entity.

That sounds simple, but “multi-entity” can describe very different levels of functionality. A provider may offer a consolidated group dashboard without supporting separate entity settlement. Another may support different legal entities but require separate accounting connections or administrator accounts.

For each entity and market, confirm which legal entity provides the service, which entity issues or supports the cards where relevant, and which contractual arrangements apply. Do not assume the same setup applies across every country in which a provider operates.

Where regulatory or payment-service arrangements matter to your decision, check the provider's current contractual documentation and the relevant regulatory register for the entity and market concerned.

This guide assesses each provider against five operational capabilities:

Entity-level card management: Can the administrator associate cards and transactions with a specific legal entity?

Per-entity settlement or funding: Can each entity manage or settle its own card spend rather than relying entirely on another group company?

Scoped permissions: Can local finance teams access only the entities they manage while group finance retains wider visibility?

Multi-entity ERP sync: Can transactions reach the appropriate subsidiary or entity ledger using the relevant accounting structure?

Currency and market support: Can the provider support the currencies and markets required by the group's legal entities?

Together, these capabilities indicate how much of the entity structure remains intact between payment and accounting.

The exact behaviour depends on the provider, plan, entity, jurisdiction, funding model, integration, and customer configuration.

Multi-entity providers compared

The comparison below reflects provider information reviewed for this article as of September 2026. Product capabilities, plan requirements, integrations, and market availability can change, so confirm any material requirement directly with the provider before making a purchasing decision.

Documented means the provider materials reviewed describe the capability for at least one relevant product or setup.

Partial means the capability appears to be available with restrictions, plan requirements, market limitations, or incomplete coverage.

Not confirmed means the materials reviewed did not give us enough evidence to state that the capability is available for the use case described.

Spendesk's multi-entity functionality is designed to give group finance consolidated visibility while allowing legal entities to maintain their own policies, approvals, and accounting structures.

That makes it relevant to finance teams looking to manage several entities within one wider spend-management environment. The exact behaviour of cards, funding, currencies, integrations, permissions, and entity availability depends on the customer setup, so those details should be confirmed for your organisation.

The other providers use different operating models rather than forming a simple best-to-worst ranking.

Ramp, Brex, Payhawk, and Airwallex all offer forms of multi-entity functionality, but plan, market, funding, and integration requirements differ.

American Express, BILL, and Navan also support aspects of complex or multi-entity finance structures. Buyers should confirm how far those capabilities extend into card ownership, settlement, permissions, and accounting for their specific organisation.

How funding works across a multi-entity group

Funding structure affects how card spending is financed, who is responsible for repayment, and what onboarding or assessment may apply to a new legal entity.

The exact legal and commercial structure varies by provider, but buyers may encounter three broad approaches: a shared or parent-supported facility, entity-specific arrangements, or pre-funded balances.

Shared parent facilities or guarantees

Some corporate-card programmes allow several subsidiaries or card accounts to sit within a wider group structure.

Depending on the agreement, the parent may support the wider arrangement through a guarantee, central facility, or another contractual mechanism.

American Express, for example, offers corporate account structures that can support complex organisations. The exact liability, limits, guarantee provisions, and termination terms depend on the programme and agreement.

Brex also supports group structures covering multiple entities. How limits, liability, repayment, and underwriting work depends on the customer's configuration and approval.

A central arrangement may simplify group administration, but finance should understand whether several entities depend on the same wider facility and what happens if one entity's activity affects that arrangement.

Entity-level assessment

Other providers use separate accounts or financial arrangements for individual legal entities.

Payhawk, for example, supports separate legal-entity structures, while Ramp offers entity-level payment functionality in selected multi-entity configurations.

Eligibility criteria vary by provider, product, jurisdiction, and customer. Some providers publish turnover, trading-history, or other eligibility requirements, while others assess applicants individually.

Do not assume approval for a parent company automatically means a new subsidiary will qualify on the same terms.

Ask each provider:

• Whether every legal entity is assessed separately.

• What company and financial information is required.

• Whether guarantees apply.

• Whether the funding model changes by jurisdiction.

• Whether activity in one group entity can affect the wider programme.

These questions give finance a clearer view of how easily the programme can scale as the organisation adds entities.

Pre-funded subsidiary balances

Under a pre-funded model, the company makes funds available before employees spend rather than relying on a traditional revolving credit facility.

The contractual and regulatory treatment of those funds varies according to the provider, product, entity, and jurisdiction.

Finance teams should review the provider's current terms and applicable regulatory information rather than assuming every prepaid or debit-based programme operates under the same structure.

Spendesk supports prepaid or debit-based card arrangements in relevant customer setups. The applicable issuer, funding structure, contractual arrangements, and market availability vary by customer and jurisdiction, so confirm the details directly with Spendesk.

Entity-to-card mapping and what happens at month-end

The same €1,200 purchase can create very different finance work depending on which legal entity owns the card and which entity actually incurs the expense.

The exact accounting treatment depends on the group's policies, systems, entities, and transaction.

ERP systems can automate parts of intercompany accounting, but they do not remove the need to configure entity ownership correctly. Providers also handle entity mismatches in different ways.

Spendesk's multi-entity functionality is designed to keep entity-level policies, approvals, and accounting structures within a consolidated group environment. Exact card-to-entity and ledger behaviour depends on configuration.

Ramp, Payhawk, and Brex also offer different forms of entity attribution, separate entity structures, or intercompany accounting support.

Test the exact scenario your organisation expects to encounter rather than assuming an “intercompany” or “multi-entity” feature removes every manual step.

Multi-entity ERP syncs: NetSuite OneWorld, Sage Intacct, QuickBooks and Xero

“Multi-entity integration” can mean very different things depending on the provider and ERP.

One platform may send transactions directly to the correct subsidiary. Another may ask finance to choose the entity before export. Another may require a separate connection or account for each ledger.

The key question is not simply whether an integration exists. It is whether the integration can send the transaction, supporting document, and required accounting fields to the correct entity using the workflow finance needs.

The integration method determines how much work remains after a transaction is approved.

A genuinely entity-aware sync can reduce manual routing by carrying the relevant entity and accounting mapping into the ledger.

If finance has to select the subsidiary on each expense, that becomes a recurring manual step. If every legal entity requires its own account and connection, the number of configurations and reconciliations can grow with the group.

A data extract may also leave finance responsible for an import, validation, and troubleshooting process. These differences become most visible at month-end, so test the close workflow rather than only the provider demo.

Spendesk offers accounting integrations across several common finance systems. Connector availability, supported fields, entity behaviour, and sync direction vary by system and configuration, so confirm the specific route required for each entity.

Foreign subsidiaries: Currency support, FX costs and documentation

International groups should evaluate currency support and documentation separately.

A card or account denominated in a different currency from the underlying purchase may create additional foreign-exchange costs.

Those costs can include:

• Card-network conversion.

• Provider or issuer FX fees.

• Wallet conversion.

• Account conversion.

• Other transaction or plan-specific charges.

FX terms vary by provider, card type, market, plan, customer agreement, currency pair, and whether the relevant account already holds the transaction currency.

For that reason, avoid comparing providers solely on a headline FX percentage. Confirm the current commercial terms for the exact entities and currencies your organisation expects to use.

Finance teams should check:

Do not assume that a card statement alone provides all the evidence a business requires for accounting, tax, or audit purposes.

Requirements differ between jurisdictions and can change.

For VAT, Making Tax Digital, overseas VAT-recovery schemes, record-retention rules, e-invoicing, or equivalent obligations elsewhere, use current official guidance and seek qualified tax advice where necessary.

For a buyer, the practical product question is:

Can the platform capture, associate, export, and retain the supporting information each legal entity needs?

Corporate cards vs business credit cards for a group structure

The labels “corporate card” and “business credit card” do not by themselves tell you who is liable, whether a guarantee applies, or how the programme is funded.

Those terms depend on the provider and agreement.

Some business-card products may involve personal guarantees. Corporate programmes may use different liability or repayment structures.

Finance teams should therefore review the agreement itself instead of assuming the liability model from the product name.

The main card models include:

Credit card: A card linked to a credit facility that may allow balances to be carried according to the terms of the agreement.

Charge card: A card where balances are generally payable according to the programme's statement terms rather than revolving in the same way as a conventional credit card.

Debit card: A card that draws against funds held in the relevant account or balance.

Prepaid card: A card that uses funds made available before spending.

Virtual card: A digital card number that can be configured for specific suppliers, subscriptions, projects, teams, or purchases depending on the provider.

Purchasing card: A business card designed primarily for supplier and procurement spending and which may provide additional transaction or invoicing data.

The card type alone does not create multi-entity control.

Finance still needs to make sure the card, account, approval rules, supporting documents, and accounting workflow belong to the correct legal entity.

What a multi-entity card programme costs

Multi-entity pricing can include:

• Platform fees.

• User or active-user charges.

• Entity fees.

• Card charges.

• Transaction charges.

• FX costs.

• Paid integrations.

• Modules.

• Implementation.

• Other negotiated commercial terms.

Pricing changes frequently and may differ by country, customer, and contract.

For that reason, the most useful comparison is not a headline monthly price but the total cost of the configuration your group actually needs.

Model the total cost against your actual:

• Legal entities.

• Employees and cardholders.

• Domestic and foreign spend.

• Currencies.

• Transaction volume.

• Accounting integrations.

• Required modules.

• Implementation requirements.

• Negotiated commercial terms.

FX can materially affect the total for groups with significant cross-currency spend, so model foreign-currency costs separately rather than relying on the platform subscription alone.

Rebates and rewards should also be treated carefully.

Eligibility may depend on currency, merchant, spend category, entity, utilisation, or payment behaviour. A headline reward rate only matters if your group's real spending pattern qualifies for it.

Implementation checklist for rolling cards out across entities

The most useful implementation work happens before cards are issued.

Finance teams should:

1. Map each entity's chart of accounts, cost centres, tax codes, and reporting structure.

2. Confirm the relevant provider, card arrangement, and contractual setup for each market.

3. Define approval workflows by entity while preserving the required group-level visibility.

4. Set card limits and merchant rules by entity and team.

5. Create a group card policy with entity-specific requirements where necessary.

6. Configure receipt and supporting-document rules before finance has to chase missing evidence.

7. Route each entity into the appropriate ledger and test the required accounting fields.

8. Define responsibility for card freezing, alerts, anomaly review, and employee offboarding.

9. Run one entity through a complete month-end close before scaling.

The pilot should use real or representative transactions rather than testing card issuance alone.

Confirm that:

• The correct entity owns the transaction.

• The approval goes to the right person.

• The relevant receipt or invoice follows the transaction.

• The expected GL, tax, and dimensional fields are available.

• Permissions work as intended.

• Currencies behave as expected.

• The transaction reaches the correct ledger.

Providers document multi-entity capabilities differently, so gaps in published information should become procurement questions rather than assumptions.

If you are considering Spendesk, ask for the exact configuration available for your entities, markets, accounting systems, currencies, and card requirements.

Choose the structure that keeps spend in the right entity

The core goal of a multi-entity card programme is to keep the payment, ownership, approval, supporting documentation, and accounting record aligned with the correct legal entity.

When one group company pays another entity's costs, finance may need additional allocation or intercompany work.

A consolidated dashboard can improve visibility, but it does not automatically fix an underlying entity-ownership problem.

The programme worth testing is therefore the one that keeps the entity relationship intact throughout the workflow:

• Which entity owns the account.

• Which entity's employee or budget owns the card.

• Who approves the purchase.

• How the transaction is funded or settled.

• Which supporting documents are attached.

• Which ledger ultimately receives the transaction.

When those elements line up, adding another legal entity can become an extension of an existing finance process rather than the creation of another manual workaround.

Frequently asked questions

Should group finance use one login across entities or a separate account per entity?

It depends on the provider's account and permission model.

A consolidated environment with entity-scoped roles can give group finance visibility across the organisation while limiting local users to the entities they manage. Separate accounts may create stronger operational separation but can also require additional logins, configurations, integrations, and reconciliations. During a demo, test exactly what group administrators, local accountants, managers, approvers, and cardholders can see and change.

Can a group keep a travel and entertainment card alongside a spend-management platform?

Yes.

The important question is how those transactions enter the wider finance workflow. If the organisation keeps a separate travel-and-entertainment card, finance should decide how statements, receipts, approvals, entity information, and accounting data reach the appropriate ledger. A second card programme may be perfectly workable, but if its transactions need a separate manual reconciliation every month, it can recreate some of the work the wider spend-management system is intended to reduce.

Can different entities use different accounting systems in one card programme?

Potentially. It depends on the provider's integration and account model.

Some platforms support several accounting systems but place limits on the number or type of connectors used within one organisation. Others require separate entity accounts, separate integrations, or exports. Before rolling cards out across the group, test the full accounting route for every legal entity and confirm which fields, documents, tax codes, dimensions, and entity mappings each integration supports.

How should finance compare multi-entity corporate card providers?

Start with your entity structure rather than the feature list.

Map:

• Every legal entity.

• Operating country.

• Card and settlement currency.

• Accounting system.

• Required approvals.

• Funding preference.

• Monthly card spend.

• Local finance responsibilities.

Then ask each provider to demonstrate the same scenarios using equivalent products, plans, markets, and customer conditions. A useful test should include a domestic transaction, cross-currency purchase, missing receipt, entity-specific approval, employee offboarding, accounting export, and a purchase made for the wrong entity. That gives finance a more reliable comparison than judging providers by feature names alone.

Disclaimer: The information above is general guidance rather than legal, regulatory, accounting, or tax advice. Product availability, issuer and payment-service arrangements, funding structures, tax treatment, integrations, pricing, and entity eligibility can vary by provider, jurisdiction, plan, and customer. Confirm material requirements directly with each provider and, where appropriate, your legal, compliance, accounting, or tax advisers.