Cross-Entity AR Settlement
Meridian's tenant pays their London invoice — but the money lands in the US entity's bank account. In a single-company world that's a headache; in a multi-entity group it's Tuesday. Cross-entity AR settlement lets a Cash Receipt recorded in one entity settle an invoice that belongs to another, while REDA Financials automatically keeps both companies' books whole with intercompany bookkeeping.
Access you'll need. Creating, posting, and applying Cash Receipts requires the Accounts Receivable v2 permission set (AR clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Payable v2, and Read Only v2 sets can view but not apply. Both entities must first be set up for cross-entity settlement by an administrator (the opt-in and IC accounts below).
What actually happens
Money belongs to the entity that banked it; the invoice belongs to the entity that issued it. When a receipt in Entity A is applied to an invoice in Entity B, both statements must stay true — so alongside the normal application, REDA Financials posts an intercompany pair:
| Books | Effect |
|---|---|
| Entity B (issued the invoice) | Its customer receivable is settled — and replaced by an IC Receivable: Entity A now owes B the money it collected on B's behalf. |
| Entity A (banked the money) | Holds the cash — and an IC Payable to Entity B for the same amount. |
The customer is settled everywhere, and the remaining question — A owes B — is exactly the kind of internal balance your group already reconciles and nets periodically.
In ledger terms, the intercompany pair posted alongside the ordinary application entries is:
| Account | Debit | Credit |
|---|---|---|
| Default IC Receivable — on the invoice's entity (B) | Applied amount | |
| Default IC Payable — on the receipt's entity (A) | Applied amount |
Both the application entries and the intercompany pair are created together, in the same operation — there's no window where one company's books are updated and the other's aren't. And the pair is symmetric by construction: whatever accumulates in B's IC Receivable is mirrored in A's IC Payable, which is what makes the periodic intercompany reconciliation a matching exercise rather than an investigation.
What must be in place
Both entities opt in — bilaterally
Each entity has an Allow Cross-Entity Settlement (AR) setting. BOTH the receipt's entity and the invoice's entity must have it on; otherwise the application is refused: "The Cash Receipt and Sales Invoice must belong to the same Entity." Consent is mutual by design — intercompany positions bind two sets of books.
Both entities carry IC accounts
A Default IC Receivable and Default IC Payable account on each entity give the intercompany pair somewhere to post — missing configuration blocks the application with a message naming the entity and account.
How to record one
Record the Cash Receipt normally in the entity whose bank received the money — same form, same fields (Creating a Cash Receipt). The application to the other entity's invoice is created directly (the application record referencing the cross-entity invoice); note two practical constraints:
- The standard Apply screen and auto-apply list same-entity invoices only. Cross-entity settlement is a data-level capability your accounting team drives deliberately — not something a clerk trips into from the everyday screen.
- Same currency and matching customer still apply. The receipt's customer must match the invoice's customer, and both documents must carry the same currency.
The rules, with the exact messages
| The message | What it means / what to do |
|---|---|
| "The Cash Receipt and Sales Invoice must belong to the same Entity." | One (or both) entities haven't opted in — Allow Cross-Entity Settlement (AR) must be checked on both before the application is accepted. |
| "Cannot create IC Accounting Transactions: Entity "{0}" is missing Default IC Receivable GL Account…" | The intercompany pair has nowhere to post — the named entity needs its IC accounts configured. |
| "Cash Receipt and Sales Invoice must have the same Customer." | Cross-entity never means cross-customer — the same party must be on both documents. |
| "Currency mismatch: both documents must use the same currency. The source document currency does not match the target invoice currency." | Crossing entities doesn't relax the currency rule — route the collection through a matching-currency account. |
| "Cash Receipt and Sales Invoice must be on the same Ledger. Receipt Ledger and Invoice Ledger do not match." | Both documents must live in the same set of books, even across entities. |
| "Application Date {0} falls on or before the AR book closure date ({1})." | Closed books refuse cross-entity settlements exactly like ordinary ones. |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Enabling the opt-in on every entity "to be safe" | Every application everywhere can now create intercompany positions — the reconciliation burden arrives before the policy does | Opt in only the entity pairs that genuinely collect for each other |
| Moving the money with a journal instead of a cross-entity application | The invoice never settles, the customer keeps getting statements, and the IC balance exists only in someone's head | Let the application do it — customer settled, IC pair posted, one audit trail |
| Letting IC balances accumulate unreviewed | Months of settlements pile into IC Receivable/IC Payable; when the totals disagree with expectations, the archaeology is painful | Reconcile the mirrored pair on a calendar — monthly is typical — and settle per your netting policy |
| Treating cross-entity as the fix for a mis-issued invoice | The invoice belongs to the wrong entity; settlement across entities cements the error with an IC position on top | If the invoicing entity is wrong, correct the invoice (credit and re-issue) instead |
Living with the IC balances
- The IC Receivable / IC Payable pair grows with each cross-entity settlement — review the two accounts against each other; they should always mirror.
- Settle the internal position periodically the same way real companies do: an actual transfer between the entities' banks, or per your group's netting policy (your accountant's call).
- Un-applying a cross-entity application reverses the IC pair along with the ordinary application entries — one delete, both books clean.
Where to go next
- Cross-Entity AP Settlement — the same feature, payment side.
- Applying Receipts to Invoices — the mechanics underneath.
- Understanding Entities — how multi-entity books fit together.
Frequently asked questions
When a customer genuinely pays the "wrong" company in your group — a centralized collections account, a parent collecting for subsidiaries, or a customer wiring to an old bank detail. If it happens constantly by design, also talk to your accountant about whether the invoicing entity is right.
By design — the standard pickers stay same-entity so everyday application can't create intercompany positions by accident. Cross-entity applications are created deliberately by your accounting team once both entities have opted in.
No — the receipt and the invoice must carry the same currency to apply. Route foreign-currency collections through an entity (or bank account) that operates in the invoice's currency.
They're settled like any intercompany debt: a real bank transfer from the collecting entity to the invoicing entity (recorded as ordinary banking transactions against the IC accounts), or via your group's periodic netting journal — policy, not mechanics, decides which.
Was this article helpful?