Finance Index
What is an intercompany invoice, and how should AP handle bills between our own entities?
Reference guide to intercompany invoices AP, including invoice workflow, coding, approvals, ERP impact, and AP controls.
An intercompany invoice bills one of your entities for goods, services, or cost shares provided by another of your entities. It needs double discipline: both sides must book the transaction consistently (payable in one, receivable in the other, same amount, same period) and the activity must eliminate cleanly in consolidation - which is why intercompany handling should follow fixed, documented patterns rather than ad hoc processing.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| An intercompany invoice | An intercompany invoice bills one of your entities for goods, services, or cost shares provided by another of your entities. | Helps finance decide what to do next. |
| Intercompany balances never tie out | Mismatches are manufactured upstream: one side books in a different period, amounts differ after partial credits, one entity codes to the wrong intercompany account, or one side never books at all. | Helps finance decide what to do next. |
| Workflow | Code all intercompany activity to dedicated accounts that map to elimination entries, keep both sides in the same period, and reconcile intercompany balances monthly. | Helps finance decide what to do next. |
| Related terms | Both work; pick one pattern and standardize. | Keeps vendor records and payment decisions reliable. |
| ERP alignment | ERPs with native intercompany distribution (NetSuite, Intacct, and others) auto-generate the offsetting entries when AP codes a line to another entity - AP supplies the target entity and account; the ERP builds the due-to/due-from. | Keeps vendor records and payment decisions reliable. |
Intercompany balances never tie out at close - how do invoice-level practices cause this, and how do I fix it?
Mismatches are manufactured upstream: one side books in a different period, amounts differ after partial credits, one entity codes to the wrong intercompany account, or one side never books at all. The fix is symmetry by design - intercompany charges created once and posted to both entities from the same record, coded to dedicated intercompany accounts, on a monthly settlement calendar with a reconciliation before close, not after the consolidation breaks.
How do I process and eliminate intercompany invoices so they don't distort consolidated results?
Code all intercompany activity to dedicated accounts that map to elimination entries, keep both sides in the same period, and reconcile intercompany balances monthly. Elimination is mechanical when coding is disciplined and forensic when it isn't.
Entity a pays a vendor on behalf of entity b - invoice split vs due-to/due-from entries?
Both work; pick one pattern and standardize. Splitting on the invoice (with your ERP's intercompany distribution support) keeps the trail on the source document; booking in A and pushing a due-from to B via journal entry centralizes it in accounting. The anti-pattern is deciding per invoice.
How does intercompany distribution work in my ERP, and what does AP need to code on the invoice?
ERPs with native intercompany distribution (NetSuite, Intacct, and others) auto-generate the offsetting entries when AP codes a line to another entity - AP supplies the target entity and account; the ERP builds the due-to/due-from. Without native support, AP codes the paying entity and accounting books the counterpart manually.
Should intercompany charges flow through AP at all, or stay as journal entries?
True third-party-style transactions between entities (one entity genuinely selling to another) benefit from AP processing - document, approval, trail. Pure allocations (management fees, cost shares) are usually cleaner as scheduled journal entries. The line to hold: whichever channel, the documentation and elimination treatment must be consistent.
Stampli perspective
Stampli supports intercompany coding within the invoice workflow, mirroring how the ERP structures intercompany accounts and dimensions, so charges that touch multiple entities are coded and validated against ERP intercompany logic before posting - with the allocation and approval history kept on the invoice record where reconciliation and audit can find it.