# Intercompany in ERP: Why One Wrong Pointer Can Break the Whole Flow

Intercompany is one of the hardest financial plumbing problems in ERP. A single transaction has to flow cleanly across operating units, post correctly to multiple sub-ledgers, and net to zero in consolidation. It all depends on the setup being just right.

This post is for anyone who designs, configures, or troubleshoots these flows. I'll walk through what intercompany is, the three most common types and when each applies, why it's genuinely hard, how to validate your setups, and how we cut 67% of the steps out of the most manual part using Oracle APEX. 👊🏼 🏆 💪🏼

* * *

## 3 Key Takeaways ✍️

1.  Oracle ERP supports numerous intercompany types. It's essential to choose the right one for your scenario. Else, accounting, inventory and operational problems can compound quietly for years. This is painful to undo.
    
2.  The most common intercompany GL failure is not a missing setup, but a wrong pointer. One misconfigured Transaction Type reference cascades into multiple wrong accounts across AR, AP, and the GL. You won't see it until you run the full cycle and trace back the actual entries.
    
3.  Intercompany elimination only works if Intercompany (IC) Receivable, IC Payable, IC Revenue, and IC COGS are on dedicated, segregated accounts. If you mix them with your external AR/AP and sales accounts, elimination becomes a manual exercise every month end close cycle.
    

* * *

## What Intercompany Is and Why It Exists

When two operating units (OUs) or legal entities inside the same parent company buy or sell from each other, those transactions still have to look "arm's length" on each entity's books — as if they were dealing with an outside, unrelated company.

One OU ships the product and records a receivable and revenue. The other OU receives the product and records a matching payable and inventory cost.

At consolidation, it should all zero out. IC Receivable nets against IC Payable. IC Revenue nets against IC COGS.

This is the theory at least. But here's why it is harder in practice.

* * *

## Many Types of Intercompany

This is where most implementations stumble. In Oracle ERP, both R12 and Fusion, there are over seven distinct types. Each one triggers different accounting flows, setup dependencies and operational behaviors. I highlight the most commonly used below.

**1\. Internal Requisition / Internal Sales Order (IR/ISO) (also referred to as Transfer Orders)**

This is used for inventory replenishment across operating units. For example, if one OU needs stock, the other ships it. The receiving OU creates an Internal Requisition. The ERP then converts it to an Internal Sales Order in the shipping OU. The shipping OU picks, packs, ships, and invoices the receiving OU at a transfer price through the IC invoicing programs.

This is the most common type in manufacturing and distribution environments.

**2\. External Drop Ship**

A customer-facing sales order is fulfilled directly by an external supplier who ships to the customer. The OU does not need to touch the inventory. Intercompany accounting flows through the purchase order receipt instead of the sales order shipment.

**3\. Internal Drop Ship**

A customer-facing sales order is fulfilled by another internal operating unit, which ships directly to the end customer. The selling OU books the external sale and owns the customer relationship. The fulfilling OU ships the product and invoices the selling OU at transfer price. There are two shipments and two invoices here, but also, two profit margins to watch and verify.

> ⚠️ The distinction between Type 1 and Type 3 matters more than most teams realize. In Type 1, the receiving OU is the end customer. In Type 3, there is an external customer beyond the receiving OU. The shipping network configuration, the Intercompany price list, and the revenue recognition events are all different. Careful with the configuration.

* * *

## Why Intercompany Is Genuinely Hard

**1\. It's a long, multi-step, multi-domain chain.**

Intercompany is one of the more complex cross-module configurations in ERP. It touches at least seven modules before a single transaction posts: Inventory, Costing, Order Management, Receivables, Tax, Payables and Accounting.

Intercompany accounting in Oracle ERP is driven by a sequence of interdependent setups: the Intercompany (IC) Relations configuration, the shipping network, the OM Transaction Type, Sub-ledger Accounting (SLA) rules, the AP setup in the receiving OU, and the IC price list. Each one feeds the next.

A mistake at any point in the chain shows up silently in the GL output. There is no single "intercompany setup" screen. It is spread across Inventory, Order Management, Receivables, Payables, General Ledger, etc. You have to understand all modules to trace it correctly.

**2\. The errors do not throw out error messages.**

Unlike a missing required field that throws a validation error, a wrong account configuration in intercompany does not stop the process. The IC programs run, the invoices get created and the GL entries post. You are not informed it may be to the wrong accounts until it's too late.

On a recent engagement, we ran the IC cycle end-to-end. It completed without a single error message. When we pulled Account Inquiry, we found IC revenue posting to an external sales account and IC payables hiding inside an inventory accrual account. Nothing indicated anything was broken. Everything just pointed to the wrong place.

**3\. The return leg is almost always an afterthought.**

Most teams configure the outbound IC flow and then discover at the first return that the return path uses a different network that does not trigger IC invoicing. Outbound and return shipping networks are frequently asymmetric. Consider and design the return flow before go-live.

## The Validation Checklist

The only way to know your intercompany setup is correct is to run the full IC cycle in a test environment and trace the actual GL entries. Here is what to look for:

1.  **Amounts match.** The IC AR invoice amount in the shipping OU must equal the IC AP invoice amount in the receiving OU, both at the transfer price from the IC price list. Any difference indicates a setup or perhaps a timing issue.
    
2.  **Accounts are correct.** Trace every entry in the GL Account Inquiry. Compare what actually posted against what's configured in IC Relations and the Sub-ledger Accounting (SLA). If they don't match, go back and retrace the full chain.
    
3.  **Currency and Foreighn Exchange (FX) rate.** If the IC invoice is in a different currency than the functional currency of either set of books, verify that the conversion rate matches what your IC Currency Conversion profile option specifies. FX mismatches create reconciliation differences that are hard to find.
    
4.  **Same GL period.** The AR and AP entries must post in the same accounting period. Timing differences, such as where the AR side posts in period 1 and the AP side posts in period 2, create reconciliation issues for that period.
    
5.  **Dedicated IC accounts throughout.** IC Receivable must be segregated from external AR. IC Payable must be segregated from external AP. IC Revenue must be segregated from third-party sales. IC COGS must have its own account. Mixing any of these with external accounts makes elimination at each month end a manual journal entry exercise.
    
6.  **Elimination-ready.** IC Receivable (shipping OU) + IC Payable (receiving OU) must net to zero. IC Revenue (shipping OU) + IC COGS (receiving OU) must net to zero.
    

> Any non-zero balance on that last check will surface up at time of consolidation. ⚠️ **Historical entries accumulate fast.** If your IC cycle goes live with wrong accounts, every transaction posts to the wrong GL accounts from day one. The longer it runs wrong, the larger the reclassification effort.

* * *

## What We Automated and Why It Mattered

A client's intercompany order booking process was manual and painful. The Intercompany Specialist had to log into multiple EBS responsibilities, create a PO Requisition by hand, run "Create Internal Orders," then open the Order Import Corrections form just to fix the currency. From there, it was back into the Internal Sales Order to populate a dozen header and line fields, attach three document types, and trigger an eConfirmation. With 300 to 400 transactions per year at roughly 15-20 minutes each, that's over 100 hours of repetitive, error-prone work annually. We built an APEX automation to collapse most of these steps into a single APEX session.

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/0ebdf844-68b2-486b-b7a2-dd5d43fbc8d8.png align="center")

> Before vs. After: the 9 manual steps required to create and book a single intercompany sales order: now collapsed into 3 steps with APEX. And this is just Stage 1 of a typical 15-20 step intercompany flow.

* * *

## ERP Features We Leveraged

The solution is built entirely on standard Oracle IC programs: Requisition Import, Create Internal Orders, and Order Import all run as designed. What we built on top was a PL/SQL orchestration layer that 1) populates the interface tables, 2) fires each concurrent program in its proper sequence, 3) waits for each to complete, 4) validates the output, and then moves to the next step. We stood up a single custom concurrent program, "XX Launch Intercompany Process," to control the end-to-end chain.

We came up with the concept of *'Intercompany Profiles*' to capture setups by intercompany scenario - by customer, OU, Legal Entity (LE), and/or intercompany type. Each profile stores pre-defined values such as the OU, org, subinventory, price list, currency, shipping method, FOB, and freight terms so that each new transaction starts pre-configured for the user. Two Descriptive Flexfields on the Requisition Header and Lines capture the External SO traceability IDs throughout the end to end process.

> "*Set it once, and then reference it every time.*"

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/bf973787-126f-4138-b66a-2e17b92543bb.png align="center")

* * *

## What APEX Contributed

EBS forms can't do what APEX does. The specialist has a single APEX webpage to navigate to and work with. They pick a profile, select the External Sales Order from a filtered list, and immediately, APEX displays populated fields for review before submission. For example, if there's a negative margin on the order, they can email for approval directly from the APEX app before submitting.

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/04388d26-da35-4104-bc92-0d9cd8135286.png align="center")

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/31222aa9-63df-4327-8184-d519dd3f00c4.png align="center")

Once submitted, a progress tracker shows each concurrent program firing and completing in real time.

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/ddb1c6bc-9159-43d3-a30d-b738cce87828.png align="center")

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/3d9c2a6f-00ab-4bcc-8f7d-44ba17378542.png align="center")

The log file, below, for the main controller Concurrent Program, 'Launch Intercompany Process' (shown above), includes details of each step taken during the Intercompany Automation Process. It also includes the Requisition Number and Internal Sales Order Number created by the process and status of uploaded attachments.

![](https://cdn.hashnode.com/uploads/covers/6271c8e2d64dcf11c4fb607f/376fb109-07e9-4fc8-9663-21dec94f369d.png align="center")

**And keep in mind**: everything above is just the booking stage. Fulfillment of both sales orders, warehouse receipts, IC AR and AP invoice generation, GL transfers, posting, and reconciliation all still lie ahead. Each can be a multi-step process of its own. This is how a single intercompany transaction can stretch to over 20 steps end-to-end.

* * *

## Closing Thoughts

Everything above, the three intercompany types, the chain-of-dependency failures and the validation checklist - apply whether you're on R12 or Fusion. The specific configurations, tables and SLA behavior, vary by version and deserve their own treatment. But get the concepts right first. Then you can focus on the version-specific execution. Have fun!

*As always, reach out and let me know how your intercompany design goes. I'd love to hear what you find.* 🙏