Difference between Intra and Inter Company

 

Difference between Intra and Inter Company

Intercompany versus Intracompany in Oracle Fusion Financials

 Two words that look almost identical and cause endless confusion

 Let me start with the single sentence that clears up about eighty percent of the confusion before we even get into

  setup: intracompany is balancing within a single legal entity, and intercompany is transacting between two different

  legal entities. That's the whole distinction in a nutshell. Everything else — the setup screens, the balancing rules,

  the reconciliation headaches — flows from that one difference. "Intra" means inside. "Inter" means between. Hold onto

  those two prepositions and you'll never mix them up again.

 

  But of course it's never quite that tidy on a real project, because Oracle's structure layers legal entities, ledgers,

  and balancing segments in a way that makes "inside" and "between" depend on how you've built your enterprise

  structure. So let me build this up properly, the way it actually has to be understood to configure it correctly.

 

  The foundation: balancing segments, legal entities, and why they matter here

 

  You cannot understand intra versus inter without first being crystal clear about the primary balancing segment value

  (BSV). In Oracle Fusion, your chart of accounts has a segment designated as the primary balancing segment — almost

  always the "Company" segment, the one that represents your legal or operating entities. The defining property of a

  balancing segment is right there in the name: the system enforces that debits equal credits for every distinct value

  of that segment. Not just for the journal as a whole — for each company value within the journal.

 

  This is the mechanical heart of the entire topic. Imagine you post a journal that debits an account in company 01 and

  credits an account in company 02. The journal as a whole balances — total debits equal total credits. But company 01

  is now out of balance (it has a debit with no offsetting credit) and company 02 is out of balance the other way.

  Oracle will not let that journal post as-is, because the balancing segment rule has been violated for each individual

  company. Something has to make each company balance on its own. That "something" is the balancing line the system

  generates automatically — and whether that line is an intracompany balancing line or an intercompany

  receivable/payable line depends entirely on whether the two company values belong to the same legal entity or

  different legal entities.

 

  So here's the structural picture you need in your head:

 

  - A ledger can contain multiple balancing segment values (multiple companies).

  - A legal entity is mapped to one or more balancing segment values.

  - When a transaction crosses balancing segment values that map to the same legal entity, that's intracompany.

  - When it crosses balancing segment values that map to different legal entities, that's intercompany.

 

  That mapping — which BSVs belong to which legal entity — is what the system uses to decide which path to take. This is

  why two journals that look almost identical on screen (a debit to company A, a credit to company B) can behave

  completely differently: in one case A and B are divisions of the same legal entity, in the other they're separate

  legal entities, and Oracle treats those two situations very differently because the legal and accounting consequences

  are genuinely different.

 

  Why the law cares, and why that drives the whole design

 

  Let me step away from the screens for a moment and talk about why Oracle bothers to distinguish these at all, because

  once the business logic clicks, the configuration stops feeling arbitrary.

 

  A legal entity is a real thing in the eyes of governments, tax authorities, and courts. It files its own statutory

  accounts. It has its own tax registration. It can sue and be sued. When one legal entity does something for another —

  Entity A pays a supplier invoice on behalf of Entity B, or Entity A sells goods to Entity B — a genuine obligation is

  created between two distinct legal persons. Entity B now owes Entity A. That's a real receivable on A's books and a

  real payable on B's books, and at some point money may actually have to move between their separate bank accounts. Tax

  authorities care intensely about these transactions because transfer pricing, VAT, and withholding can all apply when

  value moves between legal entities, even related ones.

 

  Now contrast that with two cost centers, divisions, or departments within the same legal entity. If your manufacturing

  division incurs a cost that really belongs to your sales division, and both are part of the same legal company, then

  moving that cost between them doesn't create any obligation between separate legal persons. It's the same legal entity

  moving money from its left pocket to its right pocket. There's no real debt created, no inter-party invoice required

  by law, no transfer-pricing implication. It's purely an internal management-accounting reclassification. The company

  as a whole is unaffected; you're just getting the internal attribution right.

 

  That difference — real obligation between legal persons versus internal reclassification within one legal person — is

  the entire reason Oracle splits intercompany from intracompany. The system needs to produce true receivable and

  payable balances for the inter case (because they're real assets and liabilities that have to reconcile, eliminate in

  consolidation, and potentially settle in cash), while the intra case just needs clean due-to/due-from balancing lines

  that keep each company segment in balance internally without pretending a legal debt exists.

 

  Intracompany: balancing within a single legal entity

 

  Let me take intracompany first because it's the simpler of the two, conceptually and in setup.

 

  Intracompany balancing kicks in when a transaction spans multiple balancing segment values that all belong to the same

  legal entity within the same ledger. The classic example: a payroll cost is recorded centrally against company value

  01, but part of it really belongs to company value 02 — where both 01 and 02 are just internal divisions of the same

  legal entity. When you record the journal, company 01 ends up with an imbalance and company 02 ends up with the

  opposite imbalance. The intracompany balancing rules tell the system which accounts to use to plug each side so that

  each company value balances on its own.

 

  The setup object you care about here is Intracompany Balancing Rules, which you configure in the Setup and Maintenance

  work area (Functional Setup Manager) under the General Ledger or Financials functional areas — the task is "Manage

  Intracompany Balancing Rules." In these rules you define, for a given combination of a source balancing segment and a

  destination balancing segment, which due-to and due-from accounts the system should use to generate the balancing

  lines. "Due to" and "due from" is the language that matters: company 01 records an amount due from company 02 (an

  internal receivable), and company 02 records an amount due to company 01 (an internal payable). These aren't legal

  receivables and payables; they're internal balancing accounts, but the terminology mirrors the real thing.

 

  You can set these rules up at varying levels of specificity. You can define a rule for a specific pair of balancing

  segment values (from 01 to 02, use these exact accounts), or more general rules covering many combinations, and you

  establish a hierarchy of how specific rules override general ones. There's also the concept of defining how detailed

  the balancing should be — whether you summarize the balancing lines or generate them at a more granular level. And

  critically, you set up these rules per ledger (or per ledger context), because the balancing happens within a ledger.

 

  The output of intracompany balancing is purely within General Ledger. There's no subledger invoice, no Receivables

  transaction, no Payables transaction. It's GL-to-GL balancing lines, generated automatically when you post a journal

  that crosses balancing segments inside one legal entity. The whole point is to keep each internal company value

  balanced so that if you ever needed to produce a balance sheet by balancing segment value, each one would actually

  balance — which is a requirement if those segments represent funds, divisions, or any unit you report on

  independently.

 

  A practical note that trips people up: intracompany balancing also handles more than just plain cross-company

  journals. It steps in for things like clearing company balancing — where, say, a single journal touches three or four

  company values and the system needs a consistent way to net everything down to balance — and it interacts with how

  rounding differences get balanced. You configure a "clearing company" option in some scenarios so that all the

  due-to/due-from activity routes through one designated company value rather than creating a tangle of bilateral

  balances. Whether you use a clearing-company approach or bilateral balancing is a genuine design decision with

  reconciliation consequences, and it's worth deciding early rather than discovering it during the first close.

 

  Intercompany: transacting between separate legal entities

 

  Now the bigger, more involved topic. Intercompany handling applies when the transaction crosses balancing segment

  values that map to different legal entities. Because real obligations between real legal persons are being created,

  Oracle gives intercompany its own dedicated feature set that goes well beyond simple GL balancing lines.

 

  There are really two layers to intercompany in Fusion, and it helps to keep them separate in your mind:

 

  Layer one: Intercompany balancing rules. Just like intracompany has balancing rules, intercompany has its own

  Intercompany Balancing Rules (again configured through Functional Setup Manager — "Manage Intercompany Balancing

  Rules"). These define the intercompany receivable and intercompany payable accounts the system uses to balance

  journals that cross legal entities. The mechanism rhymes with intracompany — a from/to pairing of balancing segments,

  with designated accounts — but the accounts here are true intercompany receivables and payables, real balance-sheet

  items between the entities, not internal due-to/due-from plugs. These rules ensure that any journal crossing legal

  entities self-balances each entity using the proper IC receivable/payable accounts.

 

  Layer two: the Intercompany module proper — Intercompany Transactions. This is the dedicated functional area for

  actually transacting between entities, and it's where the topic gets rich. Oracle Fusion has an Intercompany work area

  where one legal entity (the provider, sometimes called the initiator) raises an intercompany transaction against

  another legal entity (the receiver, or recipient). Think of the provider as the entity that did something of value —

  provided a service, incurred a cost, sold goods — and the receiver as the entity that owes for it. The provider

  creates an intercompany transaction, it routes to the receiver for acceptance (or auto-acceptance, depending on

  configuration), and once accepted it generates accounting on both sides.

 

  The thing that makes the Intercompany module genuinely powerful — and genuinely different from intracompany — is that

  intercompany transactions can flow through the subledgers, not just General Ledger. When you configure intercompany

  transaction types, you decide whether a given type of intercompany transaction posts only to GL, or whether it

  generates actual Receivables invoices on the provider's side and Payables invoices on the receiver's side. That

  matters enormously, because routing through Receivables and Payables is what enables real cash settlement between the

  entities (the receiver's payable gets paid through the normal AP cycle, sending actual money to the provider), and

  it's what lets you apply tax properly (an AR invoice can carry VAT/GST, which a bare GL journal cannot handle

  cleanly). For intercompany transactions that are essentially internal cost reallocations with no cash or tax

  implication, you'd configure them to stay in GL; for transactions representing genuine sales of goods or services

  between entities that need to be invoiced, taxed, and settled in cash, you'd route them through the subledgers.

 

  So the structural objects in the Intercompany module include:

 

  - Intercompany Organizations — you define the legal entities (and optionally more granular intercompany organizations)

  that participate in intercompany trading.

  - Transaction Types — these classify the nature of the intercompany activity and, crucially, drive whether the

  transaction is GL-only or generates AR/AP invoices, plus the default routing and approval behavior.

  - Customer and Supplier assignments — because if an intercompany transaction generates an AR invoice on the provider

  side, the receiver legal entity has to exist as a customer in the provider's books; and for the AP invoice on the

  receiver side, the provider has to exist as a supplier in the receiver's books. This customer/supplier-to-legal-entity

  mapping is a setup step people frequently forget, and the result is intercompany transactions that won't complete

  because the system has no customer or supplier to invoice. You set these associations up so the system knows "when

  entity A bills entity B, use this customer record for B and this supplier record for A."

  - Intercompany System Options and Balancing Rules — the global behaviors, currency handling, the minimum transaction

  amounts for approval, whether manual approval is required, and the accounts used for balancing.

 

  The reconciliation and consolidation dimension — where the real-world stakes live

 

  Here's something that doesn't show up when you're just reading the setup steps but absolutely defines why intercompany

  is treated so seriously: intercompany balances have to eliminate in consolidation.

 

  When you roll up multiple legal entities into consolidated group financial statements, the group is not allowed to

  show profit or balances arising from trading with itself. If Entity A "sold" something to Entity B, that's internal to

  the group — from the outside world's perspective, the group sold nothing. So in consolidation, A's intercompany

  receivable must perfectly offset B's intercompany payable, and any intercompany revenue must offset the corresponding

  intercompany expense. They have to net to zero. If they don't net to zero — because someone recorded one side at a

  slightly different amount, or a transaction got booked in one entity but not yet accepted by the other, or currency

  translation introduced a difference — you get an intercompany mismatch, and those mismatches are one of the most

  tedious, time-consuming problems in any month-end close for a multi-entity group.

 

  This is the deep reason Oracle's intercompany module enforces the provider/receiver acceptance handshake and generates

  matched accounting on both sides: it's trying to guarantee that the two sides of every intercompany transaction are

  equal and opposite by construction, so they eliminate cleanly later. Intracompany balancing, by contrast, doesn't

  carry this consolidation burden, because it's all within one legal entity — there's nothing to eliminate at the group

  level since it never appeared as inter-party activity in the first place. That's a genuinely important practical

  consequence of the inter/intra distinction: intercompany feeds the consolidation elimination process and lives or dies

  by reconciliation; intracompany is invisible to consolidation.

 

  A side-by-side walk through the differences

 

  Let me lay the contrasts out plainly, because seeing them next to each other is what makes the distinction stick.

 

  Scope. Intracompany operates within a single legal entity, balancing across that entity's internal balancing segment

  values. Intercompany operates across separate legal entities.

 

  What gets created. Intracompany generates internal due-to / due-from balancing lines, purely in General Ledger.

  Intercompany generates true intercompany receivable / intercompany payable balances, and can optionally generate real

  AR and AP invoices in the subledgers.

 

  Legal and tax reality. Intracompany carries no legal obligation between parties and no transfer-pricing or inter-party

  tax implication — it's internal reclassification. Intercompany creates genuine obligations between distinct legal

  persons and can carry tax (VAT/GST), transfer-pricing, and withholding implications.

 

  Cash settlement. Intracompany never settles in cash — there's no separate party to pay. Intercompany can settle in

  actual cash between the entities' bank accounts when routed through Payables.

 

  The module that owns it. Intracompany is handled by Intracompany Balancing Rules within General Ledger. Intercompany

  has both Intercompany Balancing Rules and a full dedicated Intercompany Transactions module with providers, receivers,

  transaction types, and approval workflow.

 

  Approval and workflow. Intracompany balancing is automatic and silent — it happens at posting with no human in the

  loop. Intercompany transactions can involve a provider raising the transaction, routing for receiver acceptance, and

  an approval hierarchy, because a real obligation is being imposed on another legal entity and that entity gets a say.

 

  Consolidation. Intracompany is invisible to consolidation. Intercompany balances must be eliminated in consolidation

  and are a primary reconciliation focus.

 

  Setup objects. Intracompany: Manage Intracompany Balancing Rules. Intercompany: Manage Intercompany Balancing Rules,

  plus Manage Intercompany Organizations, Manage Intercompany Transaction Types, Manage Intercompany System Options, and

  the customer/supplier associations to legal entities.

 

  How the system actually decides which path to take

 

  This is worth being precise about because it's the mechanism, and understanding it removes the mystery. When a journal

  or transaction touches more than one balancing segment value and needs balancing, Fusion looks at the legal entity

  assignment of each balancing segment value involved. If the BSVs in conflict all roll up to the same legal entity, the

  system invokes the intracompany balancing rules and generates due-to/due-from lines. If the BSVs roll up to different

  legal entities, the system invokes the intercompany balancing rules and generates the intercompany receivable/payable

  lines.

 

  So the legal-entity-to-balancing-segment-value mapping you define when you set up your enterprise structure isn't just

  bookkeeping metadata — it's the switch that routes every cross-segment transaction down the intra path or the inter

  path. Get that mapping wrong and you'll get the wrong balancing behavior: transactions that should create real

  intercompany receivables instead get quietly netted as internal due-to/due-from, or vice versa, and you won't notice

  until reconciliation or a statutory report exposes it. This is why I push so hard on validating the LE-to-BSV mapping

  during design. It's foundational, and fixing it after transactions have posted is genuinely painful.

 

  Worked examples to make it concrete

 

  Let me put real numbers and entities against this, because abstractions only get you so far.

 

  Intracompany example. Suppose "Vision Corporation" is a single legal entity, and within it you track two divisions

  using balancing segment values: 01 (Manufacturing) and 02 (Sales). The shared facilities team books a 10,000 utility

  bill entirely against Manufacturing (company 01), but 4,000 of it really belongs to Sales (company 02). You enter a

  journal: debit Sales utility expense (02) 4,000, credit Manufacturing utility expense (01) 4,000. As entered, company

  01 has a credit with no offsetting debit and company 02 has a debit with no offsetting credit — each is out of balance

  even though the journal totals tie. Intracompany balancing rules kick in: they generate a due-from line in company 02

  and a due-to line in company 01 (or however your rule directs), so each company value balances internally. No

  invoice. No cash will ever move. No tax. It never appears in consolidation as inter-party activity because it's all

  Vision Corporation internally. It's pure internal cost attribution.

 

  Intercompany example. Now suppose "Vision UK Ltd" and "Vision US Inc" are two separate legal entities in the group.

  Vision UK provides IT consulting to Vision US worth 50,000. This is a real service rendered by one legal person to

  another. Vision US genuinely owes Vision UK 50,000, and depending on jurisdiction there may be VAT and

  transfer-pricing documentation involved. Here you'd use the Intercompany module: Vision UK (the provider) raises an

  intercompany transaction against Vision US (the receiver). If the transaction type is configured to route through

  subledgers, the system generates an AR invoice in Vision UK's Receivables (with Vision US set up as a customer)

  showing intercompany revenue and a receivable, and an AP invoice in Vision US's Payables (with Vision UK set up as a

  supplier) showing the consulting expense and a payable. Later, Vision US's payable can be paid through the normal AP

  payment cycle, moving real cash from US to UK. And at group consolidation, Vision UK's 50,000 intercompany receivable

  must eliminate against Vision US's 50,000 intercompany payable, and the intercompany revenue against the intercompany

  expense, so the group shows nothing — because the group didn't sell anything to the outside world.

 

  Notice how the same shape of economic event — one part of the organization doing something for another part — produces

  radically different system behavior depending solely on whether the two parts are the same legal entity or different

  ones. That's the entire lesson in one comparison.

 

  Common pitfalls I watch out for on projects

 

  A few things I've learned to check, because they bite teams repeatedly:

 

  Mis-mapped legal entities. As I said, the BSV-to-legal-entity mapping is the routing switch. I always validate it

  explicitly with the client's statutory structure before we transact, because correcting it post-go-live is ugly.

 

  Forgetting the customer/supplier associations for intercompany. If intercompany transactions are going to generate AR

  and AP invoices, every participating legal entity needs to exist as a customer and a supplier in the appropriate other

  entities' books, with the legal-entity associations defined. Skip this and intercompany transactions stall partway

  through with errors that aren't always self-explanatory. I set this up early and test an end-to-end intercompany

  transaction in a test environment before anyone relies on it.

 

  Confusing intracompany balancing with intercompany just because both use "due to / due from" language. The terminology

  overlaps, but the accounts, the legal meaning, and the consolidation treatment differ. When someone says "the

  intercompany isn't balancing," my first question is always whether they actually mean intracompany, because half the

  time they do, and the fix lives in a completely different setup screen.

 

  Currency. Intercompany transactions between entities in different currencies bring in exchange-rate handling, and any

  rounding or rate-difference between the two sides can create reconciliation mismatches. Decide your rate and rounding

  approach deliberately for cross-currency intercompany.

 

  Tax. This is the big one for getting intercompany routing right. If a transaction needs tax applied, it generally has

  to flow through the subledgers (AR/AP) where the tax engine operates properly, not stay as a bare GL journal.

  Mis-classifying a taxable intercompany transaction as GL-only is a real compliance risk.

 

  Approval and segregation of duties. Because intercompany imposes obligations across entities, the provider/receiver

  acceptance workflow exists for a reason. Don't auto-accept everything just to make the process feel faster — the

  acceptance step is part of what protects the integrity of both entities' books and their eventual elimination.

 

  A clean way to remember it all

 

  If you strip everything back, the mental model is this. Look at the two balancing segment values in tension on a

  transaction. Ask one question: do they belong to the same legal entity or different legal entities? That single

  question decides everything downstream.

 

  Same legal entity → intracompany → internal due-to/due-from balancing lines in GL only → no invoice, no cash, no tax,

  invisible to consolidation → governed by Intracompany Balancing Rules → it's the company moving money between its own

  pockets.

 

  Different legal entities → intercompany → real intercompany receivables and payables, optionally full AR and AP

  invoices → genuine obligation, possible cash settlement, possible tax and transfer pricing → must eliminate in

  consolidation → governed by Intercompany Balancing Rules plus the full Intercompany Transactions module with

  providers, receivers, transaction types, and approvals → it's two legal persons trading with each other.

 

  "Intra" is inside. "Inter" is between. The legal entity boundary is the line that separates them, and Oracle Fusion's

  entire intercompany-versus-intracompany architecture is built to respect that line — because the law, the tax

  authorities, and your consolidated financial statements all respect it too.

 

  Closing thought

 

  The reason this topic matters so much on real Fusion projects is that the distinction isn't an Oracle quirk — it

  mirrors a hard fact about how organizations and legal systems actually work. Money moving inside one legal entity is a

  private internal matter; money moving between two legal entities is a public, legally meaningful event with

  creditors, debtors, tax, and eventual cash flows. Oracle simply gives you two different toolsets that match those two

  different realities, and your job as the consultant is to map your client's real legal structure onto the system

  correctly so that each transaction takes the right path automatically. Get the legal-entity-to-balancing-segment

  mapping right, set up the balancing rules thoughtfully, wire up the customer and supplier associations for true

  intercompany trading, and the system will quietly do the right thing transaction after transaction — which, at month-end close across a dozen entities, is worth a very great deal.