Intercompany Naming Conventions: How to Structure Account Codes, Labels, and Journal Descriptions Across Your Group

It was month three of a new group controller’s tenure when she sat down to do the first intercompany reconciliation properly. Six entities, fourteen intercompany flows, and a spreadsheet that had been maintained by three different people over four years. ManufactureCo called it “IC Revenue — Group.” DistributorCo called it “HQ Recharge Income.” The holding company had a line called “Management Recharge” and another called “Intercompany Service Levy,” which nobody could reliably distinguish. When she asked which account corresponded to which flow, the answer was: it depends on the month.

Three weeks later, she had a new naming convention document and a six-month remediation project. The reconciliations that had been taking four days now took four hours. The eliminations that had been producing unexplained differences every period were clean. Nothing about the underlying transactions had changed. Only the names had.

Intercompany naming is infrastructure. It is not exciting, it does not appear in any accounting standard, and no auditor has ever issued a finding specifically about it. But it is the layer underneath reconciliation, elimination, and reporting — and when it is inconsistent, every process that depends on it is harder than it needs to be. This guide sets out a naming convention system for the four layers of intercompany identification: account codes, account labels, journal descriptions, and entity identifiers.

The Four Layers of Intercompany Naming

Intercompany flows touch four distinct naming points as they move through the group’s accounting infrastructure. A consistent system requires a convention at each layer — not just at one.

Each layer serves a different consumer. The account code is read by accounting systems and consolidation software. The account label is read by finance team members and auditors reviewing trial balances. The journal description is read by the person reconciling a specific balance. The entity identifier is used across all four layers as the common thread that ties them together. A naming convention system must address all four, because gaps in any one layer create the inconsistencies that slow down reconciliation and elimination.

Layer 4 First: Build Your Entity Identifier Registry

Start with entity identifiers, because they are embedded in every other layer. An entity identifier is a short, unique, stable code that represents each group entity wherever it is referenced in the naming system. Three to five characters work best — long enough to be distinctive, short enough to fit inside account codes and journal descriptions without making them unwieldy.

The registry should be a single reference document, shared across all finance teams, that lists every group entity with its code, full legal name, functional currency, primary accounting system, and the date from which the code is active. It should be the first thing produced when a new entity joins the group, and it should be immutable once published — changing an entity code after it has been embedded across hundreds of account codes and thousands of journal descriptions creates a retroactive inconsistency problem that is difficult to resolve.

Entity Code	Full Legal Name	Functional Currency	Accounting System	Active From
HLD	HoldCo Group Limited	GBP	Xero	Jan 2019
MCO	ManufactureCo Limited	GBP	Xero	Jan 2019
DCO	DistributorCo Limited	GBP	QuickBooks	Mar 2020
SVC	ServiceCo Pty Ltd	AUD	MYOB	Jul 2022
RTL	RetailCo GmbH	EUR	Xero	Jan 2024

Resist the temptation to use entity names directly as identifiers (e.g. “ManufactureCo” rather than “MCO”). Full names break account code length limits, are awkward inside journal descriptions, and create problems if an entity is ever renamed. Short codes are stable even when the entity’s full name or trading name changes.

Layer 1: Account Code Conventions

The account code is where IC segregation is either built into the system or not. If an entity’s intercompany revenue account has the same code structure as its external revenue account — with only the name distinguishing them — automated identification of IC balances is impossible. The system cannot tell, from the code alone, whether a balance needs to be eliminated.

Option 1: Dedicated numeric range

Reserve a segment of the entity’s numeric COA specifically for IC accounts. In a COA where revenue runs from 4000–4799, reserve 4800–4899 for intercompany revenue. In a COA where balance sheet receivables run from 1100–1199, reserve 1190–1199 for IC receivables. Every account in the reserved range is, by definition, an IC account — no further tagging is needed.

This approach works well for entities with numeric COAs and enough headroom in each range to carve out a dedicated segment. Its weakness is that it requires discipline from entity finance teams to keep new accounts in the right ranges — a new IC account added outside the reserved range will not be identified as intercompany by automated systems.

Option 2: Alpha prefix

Use a consistent alphabetic prefix on all IC account codes. If the group’s standard is that all IC accounts begin with “IC-“, then any account code starting with “IC-” is treated as intercompany by default. This approach is more robust to COA expansion because it does not depend on numeric ranges: new IC accounts can be created with the IC- prefix regardless of what codes have already been used.

The recommended structure for the IC- prefix convention is:

IC-[TYPE]-[ENTITY] 
Where: IC = fixed prefix identifying the account as intercompany 
[TYPE] = transaction type code (see table below) 
[ENTITY] = counterparty entity code from the registry (optional — see shared vs specific section) 
Examples: 
IC-REV-MCO Intercompany revenue received from ManufactureCo 
IC-COGS-MCO Intercompany cost of goods purchased from ManufactureCo 
IC-LOAN-HLD Intercompany loan from HoldCo 
IC-INT-HLD Intercompany interest payable to HoldCo 
IC-MGT Intercompany management fee (no entity suffix if single counterparty) 
IC-REC Intercompany receivable (balance sheet) 
IC-PAY Intercompany payable (balance sheet)

Standard transaction type codes

Type Code	Meaning	P&L or BS	Example Full Code
REV	Intercompany revenue / sales	P&L	IC-REV-MCO
COGS	Intercompany cost of goods sold	P&L	IC-COGS-MCO
MGT	Management fee income / expense	P&L	IC-MGT-HLD
ROY	Royalty income / expense	P&L	IC-ROY-HLD
SVC	Service charge income / expense	P&L	IC-SVC-SVC
INT-INC	Intercompany interest income	P&L	IC-INT-INC-HLD
INT-EXP	Intercompany interest expense	P&L	IC-INT-EXP-HLD
DIV	Intercompany dividend received / paid	P&L / Equity	IC-DIV-MCO
LOAN-REC	Intercompany loan receivable	BS	IC-LOAN-REC-DCO
LOAN-PAY	Intercompany loan payable	BS	IC-LOAN-PAY-HLD
REC	Intercompany trade receivable	BS	IC-REC-DCO
PAY	Intercompany trade payable	BS	IC-PAY-MCO

Layer 2: Account Label Conventions

The account label is the display name — what appears in the trial balance, management accounts, and consolidation working papers. It must make two things immediately clear without any additional reference: that the account is intercompany, and what the intercompany flow is.

The recommended label format is:

Intercompany [transaction description] — [Counterparty full name or code] 
Examples: Intercompany Revenue — ManufactureCo 
Intercompany Cost of Goods — ManufactureCo 
Intercompany Management Fee Expense — HoldCo 
Intercompany Loan Payable — HoldCo Group Limited 
Intercompany Interest Expense — HoldCo 
Intercompany Trade Receivable — DistributorCo

Two formatting rules matter. First, always begin with “Intercompany” as the first word — this makes the IC nature of the account visible at a glance in any alphabetically or structurally sorted trial balance, without the reader having to interpret a code. Second, always specify the counterparty in the label, either as the full entity name or the entity code. “Intercompany Revenue” with no counterparty specified is ambiguous the moment a second intercompany trading relationship is established; “Intercompany Revenue — ManufactureCo” remains unambiguous regardless of how many IC relationships are added later.

The Shared vs. Counterparty-Specific Account Decision

The most consequential naming decision for any group is whether to maintain one IC account per transaction type (shared across all counterparties) or one IC account per counterparty per transaction type. This decision determines how much counterparty visibility exists at the COA level vs. the journal level.

Counterparty visible at COA level. More accounts but automated matching is easier.

Option A (shared accounts) keeps the COA leaner and reduces the number of accounts that need to be created and mapped when a new intercompany relationship is established. Its trade-off is that the journal description becomes the only source of counterparty information at the transaction level — if journal descriptions are inconsistent (which they often are when multiple people post IC entries), the shared account becomes a black box that requires manual investigation to reconcile.

Option B (counterparty-specific accounts) makes the counterparty visible at the COA level, which enables automated matching in reconciliation: the system knows that IC-REV-MCO must always be reconciled against IC-COGS-MCO in DistributorCo, without needing to parse journal descriptions. Its trade-off is that each new intercompany relationship requires new accounts to be created in every affected entity — and the COA grows with the number of relationships.

The practical recommendation: use Option B (counterparty-specific accounts) for balance sheet items — intercompany loans, intercompany receivables and payables — because these need to be individually matched and agreed between entities at each close. Use Option A (shared accounts) for P&L items — intercompany revenue, COGS, management fees — provided that journal description conventions (Layer 3) are enforced consistently. P&L IC positions are typically confirmed period by period from the billing schedule rather than from detailed transaction matching, so the COA-level granularity of Option B is less critical.

Layer 3: Journal Description Conventions

The journal description is the field that most groups treat as optional and most groups eventually regret treating as optional. It is the narrative written on each IC journal entry — the line that appears in the entity’s transaction list and in the reconciliation workbook when you pull every movement on an IC account. When journal descriptions are inconsistent, reconciling a shared IC account requires opening each transaction to understand what it represents. When they follow a standard, the reconciliation can be done from the transaction list alone.

The recommended journal description format is:

IC [Period] [From Entity]-[To Entity] [Transaction Type] [Amount or Reference] 
Examples (good): 
IC 26-11 MCO-DCO Product Sales 600,000 
IC 26-11 HLD-MCO Management Fee 36,000 
IC 26-11 HLD-DCO Loan Interest 12,500 
IC 26-11 HLD Loan to MCO — Opening balance carry-forward 
IC 26-11 MCO-DCO Unrealised Profit Elimination 27,692 
Examples (bad — do not use): 
Intercompany adjustment IC Nov Per group instructions Recharge Elimination entry

Six elements make a journal description searchable and self-explanatory. The “IC” prefix flags it immediately as an IC entry. The period (month and year in consistent format) identifies when the transaction was posted. The entity flow (From-To using entity codes) identifies both parties. The transaction type describes what is being recorded. An optional amount or reference anchors it to the source document. Any description that omits two or more of these elements will require investigation to interpret.

The period format matters: use a three-letter month abbreviation and a two-digit year (Nov-26, not November 2026 or 11/26), and be consistent across all entities. Inconsistent period formats prevent automated filtering by period across an entity’s transaction history.

Journal description conventions only work if they are enforced. A standard that is documented but not followed produces the worst outcome — the person reconciling the account must determine which entries follow the standard and which were posted by someone who did not know the convention, rather than being able to rely on consistent formatting throughout. Build the standard into your IC journal posting checklist and include a description format check in the monthly review.

Applying the System: ManufactureCo’s IC Accounts After Convention

Below is how ManufactureCo’s intercompany accounts look after the four-layer naming system is applied. Before the convention, ManufactureCo had “Sales — Group” (for IC revenue), “Purchases — HQ” (for IC COGS from the holding company), and “Loan — Group” (for the HoldCo facility) — none of which was identifiable as IC from the code alone, and none of which specified the counterparty unambiguously.

Account Code	Account Label	Type	BS / P&L	Counterparty
IC-REV-DCO	Intercompany Revenue — DistributorCo	IC Sales	P&L	DCO
IC-COGS	Intercompany Cost of Goods (all suppliers)	IC COGS	P&L	Shared
IC-SVC-HLD	Intercompany Service Charge Expense — HoldCo	IC Service	P&L	HLD
IC-INT-EXP-HLD	Intercompany Interest Expense — HoldCo	IC Interest	P&L	HLD
IC-LOAN-PAY-HLD	Intercompany Loan Payable — HoldCo Group Limited	IC Loan (BS)	BS	HLD
IC-REC-DCO	Intercompany Trade Receivable — DistributorCo	IC Receivable (BS)	BS	DCO
IC-PAY-HLD	Intercompany Trade Payable — HoldCo	IC Payable (BS)	BS	HLD

Every account is identifiable as IC from the code. Every label specifies the counterparty. Balance sheet items use counterparty-specific codes; P&L items use shared codes where only one counterparty exists (IC-REV-DCO, because ManufactureCo only sells intercompany to DistributorCo) and a shared account where the flow could involve multiple counterparties (IC-COGS). Each account maps cleanly to a counterparty in the entity identifier registry.

Retrofitting: How to Introduce Conventions Into an Existing Group

Most groups encounter this problem after the fact — existing entities have inconsistent naming and a remediation project is needed. The practical approach is to introduce the conventions prospectively for new accounts while migrating existing IC accounts over a defined transition period, rather than attempting a big-bang rename of all accounts simultaneously.

The migration sequence is: build the entity identifier registry first (this is a reference document only, no system changes required). Then update the group CCOA to use the IC-prefix account code structure. Then update each entity’s IC accounts, starting with balance sheet accounts (loans, receivables, payables) because these are reconciled most frequently and the naming benefit is most immediate. Then migrate P&L IC accounts in the next reporting period. Then implement and communicate the journal description standard.

The key risk during migration is the period where old and new naming coexist in the same account history. Ensure the transition date is clearly noted in the entity’s COA documentation, and that any reports or reconciliation tools that rely on filtering by account code are updated to recognise both old and new codes until the historical data has been rolled off.

For why inconsistent IC account naming creates reconciliation failures that persist even when the amounts are agreed, see why your intercompany balances never match, even when both companies agree. For the systematic reconciliation process that a clean naming convention enables, see intercompany reconciliation for multi-entity groups: how to match balances and close faster.

Consistent intercompany naming — enforced automatically

BrizoConsol identifies intercompany accounts by code prefix, enforces entity identifier conventions across your group, and auto-matches IC balances for reconciliation — without manual searching or journal description parsing. See how it works for your group. See It in Action

Practical Checklist: Implementing Intercompany Naming Conventions

1. Build the entity identifier registry — short codes (3–5 characters), unique, stable, one per entity. Document full legal name, functional currency, accounting system, and active date. Publish to all finance teams.
2. Choose your account code convention — dedicated numeric range or IC- prefix. The IC- prefix is more robust to COA expansion and easier to enforce. Apply consistently across all new IC accounts from the implementation date.
3. Choose shared vs. counterparty-specific accounts by transaction type. Use counterparty-specific codes for balance sheet IC items (loans, receivables, payables). Use shared codes for P&L items if journal description conventions are enforced; use counterparty-specific codes if they are not.
4. Set account label standards — every IC account label must begin with “Intercompany” and specify the counterparty. No ambiguous labels (e.g. “Group Account,” “HQ Recharge”).
5. Publish the journal description format — “IC [Period] [From]→[To] [Type] [Amount/Reference].” Make it a posted template on shared drives and in your consolidation process documentation.
6. Update the group CCOA elimination accounts to use the same IC- code structure. Elimination accounts in the consolidation model should mirror the entity-level IC accounts precisely.
7. Run a naming audit on each entity’s existing IC accounts against the new convention. Migrate balance sheet IC accounts first, P&L IC accounts second.
8. Include a naming check in your monthly IC reconciliation process. Any IC account balance that cannot be identified to a counterparty from the code or label alone should trigger a retroactive rename before the period closes. For the full reconciliation process, see intercompany reconciliation for multi-entity groups.
9. Include a description check in your IC journal posting workflow. Journals posted to IC accounts without a compliant description should be returned to the poster for correction before the period is closed. For the elimination workflow that follows reconciliation, see the complete guide to intercompany eliminations.
10. Review the naming convention annually alongside the entity identifier registry. Add new entity codes when entities join the group; deprecate codes (do not delete) when entities leave.

Group consolidation built on clean intercompany infrastructure

BrizoConsol connects to your entities’ accounting systems, identifies IC accounts by convention, reconciles balances automatically, and produces clean consolidated accounts — with a full audit trail. Start with a free trial. Start Free Trial