How do you apply intercompany and multi-currency payments?

Key Takeaways

• Every ERP keeps an invoice in its issuing entity; cash received by another entity becomes a due-to and due-from balance.
• In Microsoft’s Dynamics 365 example, a EUR 600.00 invoice paid at a later rate posts a USD 12.90 realized gain (Microsoft Learn, 2026).
• Among end users of the cash application software The Hackett Group assessed, the median auto-match rate is 70% (The Hackett Group, 2025).
• Seven policy decisions make cross-entity payments repeatable.
• ClearMatch from Transformance reaches a 95% auto-match rate, and nothing posts without a person’s sign-off (Transformance customer data, 2026).

In This Article

• Key Takeaways
• How does cash application handle intercompany and multi-currency payments?
• What happens when a customer pays one entity for another entity’s invoice?
• How do you apply one wire that pays invoices of several entities?
• What happens when the payment currency differs from the invoice currency?
• Where does the exchange rate difference go, and which entity books it?
• How do netting and intercompany reconciliation follow cash application?
• What should your intercompany and currency policy define?
• How does Transformance work with intercompany and multi-currency payments?

How does cash application handle intercompany and multi-currency payments?

Every ERP clears each invoice in the entity that issued it, books an intercompany balance when another entity holds the cash, and posts rate changes as realized gains or losses.

Intercompany and multi-currency payments: what each ERP does and what you decide

Behaviour depends on configuration and release; confirm with your ERP team.

An intercompany payment is a payment that moves between two entities of one group, or a customer payment that one entity receives for another entity’s invoice. A multi-currency payment is one where the invoice currency, the payment currency and the entity’s local currency are not all the same.

All three ERPs share one rule. In SAP S/4HANA, “one document is assigned to exactly one company code” (SAP Learning, S/4HANA course). In NetSuite, “Each transaction in NetSuite OneWorld, except advanced intercompany journal entries, is tied to one subsidiary” (Oracle NetSuite Help Center). Dynamics 365 settlement across legal entities “generates the applicable due-to and due-from transactions” (Microsoft Learn, 2026).

Among end users of the cash application software assessed by The Hackett Group (2025), the median auto-match rate is 70%, and some carry “up to 6% of unapplied cash”. Cross-entity and currency cases are typical members of that unmatched remainder; that is our reading, not Hackett’s.

A wrong-entity posting looks cleared at group level while one entity dunns the invoice; see how external systems clear open items.

What happens when a customer pays one entity for another entity’s invoice?

The receiving entity posts the cash, the invoicing entity clears its invoice, and the ERP books an intercompany balance between them; your policy decides whether the cash then moves.

In case 1, the customer pays your entity A for entity B’s invoice. In case 2, the customer’s parent pays; the posting stays inside one entity of yours.

• SAP S/4HANA and ECC. SAP’s example of a cross-company code transaction is central payment: “One company code pays the invoices for other company codes.” The system “automatically generates line items and posts them to clearing accounts, for payables or receivables”, and “A common cross-company code transaction number links all the documents” (SAP Learning). SAP’s example is payables; every company code needs a clearing account first.
• Dynamics 365 F&O. With centralized payments, “A single legal entity receives payments for all the operating legal entities.” In Microsoft’s first example, Fabrikam receives 600.00 for a Fabrikam East invoice; Fabrikam posts “Due to Fabrikam East”, Fabrikam East posts “Due from Fabrikam” (Microsoft Learn, 2026).
• NetSuite OneWorld. For a shared customer, “you can choose any subsidiary assigned to the selected customer” (Oracle NetSuite Help Center). Cash collected in the wrong subsidiary is typically moved with an intercompany journal entry, since “Intercompany journal entries post to two subsidiaries” (Oracle NetSuite Help Center). “Typically” is our inference from these rules.
• Case 2. SAP lets you enter an alternative payer “at the client and company code level” (SAP Learning); NetSuite’s Consolidated Payments let you “accept payments either through a subcustomer or its top-level parent customer” (Oracle NetSuite Help Center). Unknown payer: how to match a payment with no reference.

Your policy: which entities may collect for which others, whether the receiving entity settles through the ERP’s intercompany mechanism or returns the cash, who owns unapplied amounts, and when the balance is settled. Group view: running AR across 40 legal entities.

How do you apply one wire that pays invoices of several entities?

Identify the owning entity for every invoice on the remittance, then post one clearing per entity, either in one cross-entity transaction or as separate payments plus an intercompany step.

• SAP. SAP’s R/3 4.6C documentation (an older release) describes cross-company code clearing: with the items selected in company code 0001, “The system automatically chooses the open items from company code 0002 for processing as well”, and “the company code-specific documents balance to zero” (SAP Help Portal). It needs configuration; check your release.
• Dynamics 365 F&O. In Microsoft’s example 5, Fabrikam receives 75.00 and settles a Fabrikam West invoice of 100.00 with a Fabrikam East credit note of 25.00, the payment “selected as the primary payment on the Settle transactions page” (Microsoft Learn, 2026).
• NetSuite. A wire for three subsidiaries’ invoices is typically recorded as three customer payments plus your intercompany step (our inference; see the NetSuite integration guide).

Illustrative example (fictional figures). Entities A, B and C keep their books in USD; C invoices some customers in EUR. A customer wires USD 59,700 to entity A, and the remittance advice lists:

A clears its own USD 25,000. USD 20,000 belongs to B and USD 14,700 to C: clearing-account lines in SAP, due to B and C in Dynamics 365, typically separate payments plus intercompany journal entries in NetSuite. The USD 50 gap on C’s invoice is an exchange rate difference, not a short pay.

‍

‍

What breaks it: overlapping invoice numbers, a remittance without entity names, a short pay on one entity’s invoice, a customer missing in B. In SAP, “Any company that wishes to do business with a specific business partner has to create a company code segment” (SAP Learning); without it, nothing posts there (our reading).

Your policy: the identification order (invoice number range per entity, remittance line, the bank account the customer usually pays) and what happens when one entity’s part does not reconcile: clear the rest, or hold the wire. See how AI reads remittance advice.

What happens when the payment currency differs from the invoice currency?

The ERP converts between the invoice currency and the payment currency at a rate, and the rate chosen decides whether the invoice clears in full or leaves a difference.

• Dynamics 365 F&O. “You can use a cross rate when you settle a payment with an invoice and the payment and invoice lines are in different currencies”, at the rate “as of the settlement date” (Microsoft Learn training, 2026).
• NetSuite. The payment’s currency “filters the list of invoices, credit memos, and deposits available under the Apply subtab” (Oracle NetSuite Help Center); a customer’s primary currency is the default for sales transactions (Oracle NetSuite Help Center). A payment in a currency the invoice does not carry needs a rule first.
• SAP. When foreign-currency open items are cleared, “exchange rate differences may occur” (SAP Learning). Entering a payment in another currency depends on your release: confirm with your SAP team.

For entity C, USD 14,700 equals EUR 12,500 at 1.1760. Apply it at the invoice-date rate of 1.1800 instead and it covers only EUR 12,457.63: the invoice looks EUR 42.37 short and lands in the deduction queue.

Bank charges look like FX too: keep charges, FX and deductions as separate reasons (how bank statement files feed cash application).

Your policy: which currencies each customer may pay in; which rate counts (the bank’s conversion, the ERP’s daily rate or an agreed cross rate); who absorbs bank charges.

Where does the exchange rate difference go, and which entity books it?

The ERP posts a realized exchange rate gain or loss to accounts set up in configuration; with cross-entity payments, a setting or your policy decides which entity books it.

• SAP. S/4HANA “automatically posts these exchange rate differences to the revenue or expense account as realized gains or losses” and “stores the realized difference in the cleared line item” (SAP Learning).
• Dynamics 365 F&O. The Intercompany accounting page’s “Post currency exchange gain or loss” field names the legal entity of the payment or of the invoice. In Microsoft’s example 3, a EUR 600.00 invoice booked at 1.2062 (USD 723.72) is paid at 1.2277 (USD 736.62): the USD 12.90 gain posts in Fabrikam, the legal entity of the payment, and the due-to and due-from net to USD 723.72 (Microsoft Learn, 2026).
• NetSuite. “When the exchange rates on the source and payment transactions are different, a realized gain or loss is posted”: (payment FX rate minus source FX rate) x payment, “for each transaction” when one payment covers several (Oracle NetSuite Help Center).

In the example, EUR 12,500 x (1.1760 minus 1.1800) is a USD 50 realized loss, and who carries it changes the intercompany balance. If A books it, as Fabrikam does in Microsoft’s example (our worked logic, not a documented rule), A owes C the invoice value of USD 14,750 and keeps the loss. If C books it, A owes C what it received: USD 14,700.

Small differences can stop a posting: in SAP S/4HANA Cloud Public Edition, a “Minor difference … cannot be allocated across company codes” error can occur in cross-company clearing of a foreign-currency down payment (SAP Knowledge Base Article 3782126). Test one in the pilot.

Your policy: which entity books the gain or loss, the amount below which a difference counts as FX rather than a short pay, and gain and loss accounts in every entity before go-live. Real short pays go to the deductions workflow.

How do netting and intercompany reconciliation follow cash application?

Netting offsets what group entities owe each other so only the net amount moves, and intercompany reconciliation checks each due-to against its due-from; both run outside the customer cash queue.

• SAP. Where a partner is both customer and vendor, “you can have the payment program and the dunning program clear the vendor and customer open items against each other”, and “each company code can decide separately” (SAP Learning).
• Dynamics 365 F&O. Customer and vendor netting offsets open customer and vendor balances: “Instead, netting journals are created” (Microsoft Learn, release notes 10.0.40, 2024).
• NetSuite. “The netting statement automatically generates four netting settlements (two for each subsidiary)”, and the IC Netting Clearing Account returns “to zero after each netting” (Oracle NetSuite Help Center).

In the example, with C booking the FX, A owes C USD 14,700 and C owes A USD 9,000 for shared services. One netting run settles both with a single transfer of USD 5,700 from A to C (14,700 minus 9,000); had A booked the FX, USD 5,750.

Intercompany reconciliation then checks that A’s due to C equals C’s due from A; FX booked on one side only breaks the pair. Keep intercompany partners out of customer dunning, and net intercompany flows before adding entities up in the forecast.

What should your intercompany and currency policy define?

Seven decisions make cross-entity and currency payments repeatable: who may collect for whom, how the entity is found, where cash posts, which rate counts, who books FX, netting and approvals.

1. Collection rights: which entity may receive cash for which others, in which bank accounts.
2. Identification order: how the owning entity of each invoice is found (number range, remittance line, bank account).
3. Posting entity: settle in the receiving entity, or return the cash.
4. Rate source: the bank’s conversion, the ERP’s daily rate or an agreed cross rate.
5. FX booking: which entity books the realized gain or loss, and the limit between FX, bank charges and a short pay.
6. Netting: calendar, eligible balances, netting rate, and intercompany partners excluded from dunning.
7. Approvals: who signs off cross-entity postings and FX differences above which amount.

The group controller signs it with treasury; the AR lead owns identification. Thresholds by amount, entity and customer decide who approves what.

The usual failure: a policy in one clerk’s head. When that clerk is out, cross-entity cash sits unapplied.

How does Transformance work with intercompany and multi-currency payments?

Transformance reads open items, remittances and bank statements for all entities of your ERP in one environment, and nothing posts without a person’s sign-off.

ClearMatch reaches a 95% auto-match rate and runs end to end in under 8 minutes, with 100% posting validation (Transformance customer data, 2026). DocSense reads remittance advice with over 97% extraction accuracy across 100+ document types and 170+ languages, with no template setup (Transformance platform data, 2026).

For exceptions, Vero, the Transformance agent, investigates from Customer 360, fetches internal and external information to find more matches and proposes with the evidence; a person approves. Your intercompany and currency rules are written down in scoping, and each posting follows the approval thresholds.

• Write-back: clearing postings and journal entries, including reversals, after approval (what AR automation reads from and writes to the ERP).
• Control: a 4-level approval model (read, recommend, execute, post); admins configure the rules, finance approves.
• Scope: per ERP, all entities in one environment: SAP instances and company codes, NetSuite subsidiaries or Dynamics 365 legal entities. Data is hosted in your region; VPC, SSO/SAML and RBAC.
• Connection: typically 2-3 days, and your IT team may be involved; full rollout in 4-8 weeks. In SAP: no custom ABAP, no modifications.

Who Transformance is for

• ERP: groups that apply customer payments across entities and currencies in SAP S/4HANA (on-premises, private or public cloud), SAP ECC, NetSuite, Microsoft Dynamics 365 Finance & Operations or Business Central, or Odoo, all running in production with customers; Oracle and Infor are supported.
• Size: mid-market to large enterprise, 250 to 2,000+ employees, including groups with several entities and shared service centres.
• Payment volume: from under 1,000 to over 100,000 payments a month.
• Industries: manufacturing, consumer goods and food and beverage, logistics, e-commerce, agriculture, energy and professional services.
• Scope: cash application alone, or the full order-to-cash: cash application, deductions, AR collections and cash forecasting.

Conclusion: write the cross-entity rules before the first wire

Intercompany and multi-currency payments clear reliably once the group decides who collects for whom, which rate counts, who books the difference and what is netted, and a person approves. Pilot with one wire across two entities and one foreign-currency invoice; add entities once the balances reconcile.

Key terms

• Cash application: matching incoming payments to open invoices and clearing them in the ERP.
• Remittance advice: the customer’s list of invoices a payment covers.
• Wire transfer: a bank-to-bank payment, often covering several invoices.
• Foreign exchange rate: the rate between invoice, payment and local currency.
• FX risk: the exposure to rate changes between invoicing and payment.
• On-account cash: cash posted to a customer account without clearing an invoice.

Related guides

• Which ERP systems does Transformance integrate with?
• How do external systems post payments and clear open items?
• How does Transformance integrate with NetSuite and OneWorld?
• How does Transformance integrate with Dynamics 365 F&O?
• How do you run one AR process across SAP, Oracle and NetSuite?
• Multi-entity order-to-cash: running AR across 40 legal entities

Frequently Asked Questions

Can one customer payment clear invoices in two SAP company codes?

Yes: SAP posts it as a cross-company code transaction, with a separate document per company code, lines on clearing accounts and one linking transaction number, once the partner company codes are configured.

Which entity books the exchange rate difference when one entity collects for another?

In Dynamics 365 a setting on the Intercompany accounting page decides between the legal entity of the payment and that of the invoice; in SAP and NetSuite, your group policy should state which entity carries it.

Is intercompany netting part of cash application?

Not normally: netting runs as its own settlement between group entities, apart from the customer cash queue.

Which ERPs does Transformance connect to for multi-entity cash application?

Transformance connects to SAP S/4HANA (on-premises, private or public cloud), SAP ECC, NetSuite including OneWorld subsidiaries, Dynamics 365 Finance & Operations, Business Central and Odoo, all in production with customers; Oracle and Infor are supported.

Does it work for groups with many entities and high payment volumes?

Yes: Transformance is built for 250 to 2,000+ employees and from under 1,000 to over 100,000 payments a month, with all entities of one ERP in one environment.

How long does it take to go live across several entities?

The ERP connection typically takes 2-3 days, and your IT team may be involved; the full rollout takes 4-8 weeks, and a proof of value runs in 4-5 weeks on one entity.

What does multi-entity cash application cost?

The cost depends on scope (cash application alone or the full order-to-cash) and on the number of entities, so we size it with you on a call: Book a Call.