Consolidated financials for a group of related companies are only correct if the transactions between those companies cancel out. Sell inventory from Branch A to Branch B within the same legal group and, from the group's outside perspective, nothing happened — no revenue was earned, no cost was incurred, it's the same box of goods moved from one internal shelf to another. Acumatica gives you the mechanics for inter-branch and inter-company transactions; getting the elimination right at consolidation is where the actual work is, and it is not automatic just because you set up multiple branches.
Inter-branch (same tenant) vs inter-company (separate legal entities) — different problems
Acumatica distinguishes two setups that people often conflate. Multi-branch within one company uses Branch as an organizational dimension inside a single set of books, and inter-branch transactions (a due-to/due-from pair) are generated automatically by the framework when a document crosses branches, because the branches share a company-level chart of accounts. Multi-company (or true inter-company) means genuinely separate legal entities, potentially with separate charts of accounts and separate base currencies, connected through Acumatica's Inter-Company Journal Entries functionality that mirrors a transaction from one company's books into another's using a mapping you configure.
Elimination only becomes a real accounting exercise at consolidation time, and it looks different depending on which of these two setups you're in. Inter-branch due-to/due-from balances within one company net to zero automatically if your branch mapping was configured correctly from day one, because they're just balanced GL entries within the same ledger. True inter-company transactions between separate companies do not net automatically; they require deliberate elimination entries at the point you consolidate.
PXSelect<GLTran,
Where<GLTran.accountID, Equal<Required<GLTran.accountID>>,
And<GLTran.branchID, Equal<Required<GLTran.branchID>>,
And<GLTran.finPeriodID, Equal<Required<GLTran.finPeriodID>>>>
.Select(Base, dueToFromAccountID, branchID, periodID);
// Sum(DebitAmt) - Sum(CreditAmt) across the paired due-to/due-from accounts
// for the same period should equal zero. A nonzero residual usually means
// a manual journal entry touched the intercompany account directly,
// bypassing the automatic pairing.
The automatic inter-branch mechanism only balances correctly when every transaction touching a due-to/due-from account goes through the framework's own inter-branch posting logic. The moment someone posts a manual GL entry directly against one of those accounts, correcting what they believe is an error, the automatic pairing breaks and the accounts stop netting to zero. On a client audit I traced a multi-month reconciliation gap to exactly this: a controller manually adjusting a due-from balance every period instead of finding the actual source transaction, compounding the imbalance instead of fixing it.
The harder problem: eliminating intercompany profit, not just balances
Balance elimination (making due-to and due-from net to zero) is the easy half. The harder half, and the one that actually matters for a correct consolidated income statement, is eliminating unrealized intercompany profit — if Company A sells inventory to Company B at a markup, and Company B hasn't resold it externally by period end, the consolidated group still holds that inventory at A's original cost, not at the inflated intercompany price. Acumatica does not eliminate this markup for you automatically; it requires either a dedicated intercompany elimination module/add-on, or in leaner implementations, a manual consolidation adjustment each period based on a report of intercompany inventory still on hand.
PXSelectJoin<INTran,
InnerJoin<SOOrder, On<SOOrder.orderNbr, Equal<INTran.refNbr>>>,
Where<SOOrder.customerID, Equal<Required<SOOrder.customerID>>,
And<INTran.tranType, Equal<INTranType.receipt>>>>
.Select(Base, intercompanyCustomerBranchID);
// Cross-reference against the receiving branch's on-hand qty for the
// same item at period end to estimate unrealized markup still in inventory.
Building this report is genuinely custom work in most implementations because "which customer/vendor records represent an intercompany relationship" is a configuration decision your client makes, not something Acumatica infers, so the query above needs a real mapping table (which customer IDs correspond to which internal company/branch) rather than assuming every sale to a flagged customer is intercompany by default.
Consolidation timing and period alignment matter more than people expect
Elimination entries have to be posted to a period that both entities have open, and if one company's books close faster than another's (common when a newly acquired subsidiary runs a slower month-end process), you either hold the faster entity's period open longer than you'd like, or post a preliminary elimination that gets trued up the following period. Neither is elegant, but pretending timing misalignment doesn't happen and posting elimination entries against a period one entity has already closed is how consolidated numbers quietly stop matching either entity's own trial balance.
Wrapping up
Inter-branch due-to/due-from balances net automatically as long as nobody posts manual entries directly against those accounts, which is worth protecting with a security role restriction, not just a policy. Eliminating intercompany profit sitting in unsold inventory is a genuinely separate, harder problem that Acumatica's base functionality does not solve for you, and building that reporting requires an explicit mapping of which trading partners are actually internal. Get the branch and account mapping right at setup, because retrofitting it after a few years of transactions is a much bigger project than getting it right on day one.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.