Intercompany Journal Entries
Meridian's US entity pays a group insurance premium; a slice of it belongs on the UK entity's books. One economic event, two companies — the classic intercompany problem. A single journal entry in REDA Financials can carry lines for both entities, because the entity lives on the line, not just the header. What the system asks in return is bookkeeping honesty: every entity's books must balance on their own.
Access you'll need. Creating and posting intercompany journal entries requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view entries but not create or post them.
The one rule: each entity balances
When an entry's lines span more than one entity, posting checks the balance per entity — not just overall. An entity whose debits and credits don't match is refused: "Intercompany posting is out of balance for Entity …: Debits … != Credits …". This means you write the intercompany offset lines yourself, using each entity's intercompany accounts:
| Line (entity) | Account | Debit | Credit |
|---|---|---|---|
| US paid a $12,000 group premium; $3,000 belongs to the UK | |||
| US | Insurance Expense | $9,000 | |
| US | IC Receivable (from UK) | $3,000 | |
| US | Cash and Cash Equivalents | $12,000 | |
| UK | Insurance Expense | $3,000 | |
| UK | IC Payable (to US) | $3,000 | |
Check it entity by entity: US debits 12,000 = credits 12,000 ✓; UK debits 3,000 = credits 3,000 ✓. Each company's trial balance stands alone, and the IC Receivable/Payable pair records who owes whom — exactly the position the group settles or nets later.
Practical mechanics
- Set the Type to Intercompany — informational, but it makes review and filtering honest.
- Each line's Entity field defaults from the header; override it on the lines that belong to the other company. GL accounts and cost centers must fit their line's entity (global accounts work everywhere).
- Ledger rows are flagged — postings from a multi-entity journal are marked as intercompany in the ledger, so group eliminations can find them at consolidation time.
- Different functional currencies are supported — each line converts the document currency into its own entity's currency at the entry date's rate (the standard multi-currency treatment).
Building the premium entry, line by line
Header: the entity that owns the event
Meridian's US entity paid, so the header entity is Meridian Properties US LLC — three of the five lines will inherit it untouched. Type: Intercompany. Description: the testimony ("Group insurance premium — UK share recharged").
The US lines: expense, receivable, cash
Insurance Expense debit $9,000 (the US share), IC Receivable debit $3,000 (what the UK now owes), Cash credit $12,000 (what left the bank). Leave Entity blank on all three — the header fills it.
The UK lines: expense and the mirror payable
Two more lines with Entity switched to the UK company: Insurance Expense debit $3,000 and IC Payable credit $3,000. Each account must be global or belong to the UK's chart — the line validation checks against its own entity.
Balance twice, then post
The form's Difference shows the overall balance ($12,000 = $12,000); the per-entity check runs at posting. If you missed the payable line, the message names the offender: "Intercompany posting is out of balance for Entity …: Debits 3,000 != Credits 0." Add the missing mirror and post again.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Forgetting the IC Receivable/Payable pair | Posting refuses the entry — each entity's slice must balance alone | Write the offset lines as part of the entry, every time; the message tells you which entity is short |
| Using one entity's scoped GL account on the other's line | The line is refused ("This GL Account belongs to a different entity…") | Each line's account must be global or belong to that line's entity |
| Mirroring with mismatched IC accounts | The two sides won't eliminate cleanly at consolidation — someone reconciles the residue by hand | Agree the IC account pair per counterparty once, and reuse it religiously |
| Changing a line's Entity by accident | An ordinary journal quietly becomes intercompany and fails per-entity balance at posting | Leave line Entity blank unless you mean it; review the Entity column before posting |
| Recharging the same cost by journal and by allocation | The expense lands twice on the receiving entity | Pick one instrument per cost — see the toolbox below |
Journals aren't the only intercompany tool
Reach for the right instrument: a customer payment collected by the wrong entity is Cross-Entity AR Settlement; a shared vendor bill split across entities is Expense Allocation — both create their intercompany bookkeeping automatically. The intercompany journal is for everything those flows don't cover: management fees, cost recharges, interest on intercompany loans.
Where to go next
- JE Lines (Debit & Credit) — the per-line entity mechanics.
- Understanding Expense Allocation — automated cost sharing.
- Understanding Entities — the multi-company foundation.
Frequently asked questions
The entity that "owns" the event — usually the one that paid or initiated it (Meridian uses the US entity for the premium above). Lines default to the header entity, so pick the one that minimizes overrides.
Your group's designated intercompany receivable/payable accounts — ask your controller; many groups keep one pair per counterparty entity. Consistency matters more than the exact naming: the two sides must mirror so they eliminate cleanly at consolidation.
The entry has one document currency; each line lands in its own entity's books converted at the entry date's rate. Agree the document currency (usually the paying entity's) and let the conversion do its work.
Like any intercompany position: a real transfer between the entities' banks, periodic netting, or offset against other IC balances — group policy decides. The IC accounts should reconcile to zero across the group at all times.
On journal entries, deliberately not: a journal is the precision instrument, and the system won't guess which of your group's IC accounts a recharge should route through. The automated flows that do create their own IC bookkeeping — cross-entity AR settlement, expense allocation — work from configured default accounts; the journal works from your lines.
Yes — template lines carry their own Entity override, so a monthly management-fee recharge can run on autopilot. Build it once with the full offset structure, and every generated entry inherits it. See Recurring Journal Entries.
Two handles: filter journal entries on Type = Intercompany for the documents, and use the intercompany flag on the ledger rows for the accounting — the flag is set from the lines, so it catches cross-entity postings even where the Type label was forgotten.
Was this article helpful?