Five intercompany accounting problems every controller recognizes
It's day four of the close. Due-to and due-from are off by $8,412 across three subsidiaries. Small enough that nobody wants to escalate it. Large enough that you can't sign off and pretend you didn't see anything.
Somebody, maybe that somebody is you, starts working backward. They pull the intercompany accounts, compare balances by pair, and find that Entity A booked one side of a transaction but Entity B never booked the other. Somewhere in that chain there's a shared services allocation that was calculated in a spreadsheet, applied to one subsidiary, and never turned into a matching bill on the other side. Two hours later you have your answer and you post a correcting entry. Later, you make a note to look at the process after close, but who has time for that? After all, the next close starts in just a couple of weeks.
If this sounds familiar, the problem is not your team's attention to detail. The fix lives deeper, where the allocation logic lives. That one root cause surfaces in five different ways.
What we hear from multi-entity controllers
These come up in nearly every conversation we have with controllers running multi-subsidiary NetSuite instances. See how many you recognize.
1. Manual intercompany journals and the person who owns them
Every allocation that lives outside the system becomes an intercompany journal entry someone types. At high transaction volumes across multiple subsidiaries, that translates to hours per close, repeated every close cycle.
It also concentrates risk in one person. Someone built the allocation model. When that person takes PTO during close week, the allocation either does not happen or happens incorrectly.
2. Lack of visibility into intercompany allocations
Without a central record, tracing intercompany allocations back to their source requires a manual investigation. This is most painful at consolidation, where intercompany reconciliation depends on tying elimination entries back to the transactions that created them. At volume, those entries accumulate faster than anyone can trace them.
What starts as a small error gets more expensive over time. A small unexplained balance gets rolled into next month's entry, then the month after, until the residual is large enough that someone has to unwind a year of activity to explain what's going on. Nobody budgets for a project like this. It arrives anyway, usually when you're already short on time.
3. Inefficient cross-entity coordination
Two entities, one transaction, and a person in the middle. The matching bill on the receiving side depends on someone in a different subsidiary providing context to make the numbers match. The same is true when one subsidiary pays a vendor on behalf of another and the intercompany journal entry is booked by hand.
Most of the time, things work out. When they don't, you end up with an $8,412 discrepancy that takes hours to chase down. Every manual handoff between two entities is a place where the two sides can drift apart, and every one of those handoffs is an email waiting on a reply during the week you have the least time to wait.
4. Complex compliance requirements
"Walk me through how you arrived at this split." Every controller who has been through a related party review has heard some version of this. Under PCAOB AS 2410, an auditor can't simply accept management's assertion that intercompany terms were arm's length. They must test it against evidence. Every split has to trace back to the transaction that produced it. A number you cannot source is a number your auditor cannot rely on.
5. Inconsistent reporting
Your CFO asks what the East region cost to run last quarter. If shared costs were allocated outside the system and recorded as summary journal entries, you can produce a number, but defending it is impossible without finding the origin spreadsheet. Worse yet, when two entities handle the same shared cost differently, consolidation stacks both approaches without flagging either, so East and West are not being measured the same way.
Fixing intercompany journals at the source
Most intercompany accounting errors start one layer above the transaction, in the calculation that decides how that transaction will be split.
Rent, insurance, corporate overhead, shared IT, management fees, marketing spend that benefits four business units. None of those arrive pre-allocated. Someone decides that this bill is 40 percent Entity A, 35 percent Entity B, and 25 percent Entity C, then translates that decision into entries recorded in your ERP. When that decision lives in a spreadsheet, the ERP receives an output with no record of the input. The general ledger knows what was posted, but it can't tell you why.
Cross-industry benchmarking data from APQC has the median finance organization automating just 30 percent of its journal line items. Even top performers only reach 58 percent.
At the median, seven of every ten journal line items are still typed by a person. In a single-entity company that's an efficiency problem. Across eight subsidiaries, the arithmetic works against you. One allocated bill creates separate journal entries across subsidiaries, plus the intercompany entries that balance them.
Why the fix is structural, not procedural
The instinct is to fix this with discipline. A better checklist, a tighter deadline, a second reviewer on the allocation tab. That helps at the margin, but it doesn't address the underlying issue. The calculation still lives outside the system that holds the record.
Moving allocation logic into the ERP changes what is possible. When the split is defined inside NetSuite and applied at the transaction level, the allocation and the source document stay attached permanently. The intercompany journal is generated from the rule rather than typed from a spreadsheet output. Traceability becomes a property of the system instead of a habit your team has to maintain. That is true of any well-designed intercompany accounting software, ours included.
What to look for in intercompany accounting software
There are several credible ways to handle intercompany allocations. We think ours is the best fit for NetSuite users, and here are the standards we would want you to judge it against.
Native or bolted on. Intercompany accounting software that lives inside NetSuite inherits your subsidiaries, segments, permissions, and audit trail. Software that syncs into NetSuite adds a second system to reconcile, which is the problem you started with.
One side or both. Creating an intercompany invoice should create the matching vendor bill. If it doesn't, one-sided entries stay possible, and one-sided entries are what you spend day four chasing.
Traceable or not. Every split should link back to the transaction that produced it, and every transaction forward to its split. That link should exist because the system made it, not because somebody maintains it.
How Shared Transactions handles intercompany allocations
Shared Transactions is intercompany accounting software built as a native SuiteApp, which means it inherits the subsidiaries, segments, permissions, and approval workflows you already have. It splits the general ledger impact of a single transaction line across subsidiaries, native segments, custom segments, accounts, and entities, then posts the allocation journal automatically once the source transaction is approved. Recurring splits are defined once as templates and applied at the line level, so the rent bill and the payroll allocation can carry different bases without rebuilding either one. It works across most transaction types, including Netgain journals from NetAsset, NetLease, and NetClose.
Both sides of an intercompany transaction get created without anyone having to remember. Intercompany Billing, in the Premium tier, generates the matching vendor bill in response to an intercompany invoice. Shared Payments covers the other common case, generating the Advanced Intercompany Journal Entries needed when one subsidiary pays a vendor on behalf of another, so cash and intercompany balances stay in sync instead of drifting apart until somebody reconciles them.
Traceability comes built in rather than maintained. On the source transaction, the allocation journal is linked on the Shared Transactions subtab. On the allocation journal, the source transaction is linked in the Shared Transaction Source field. So when an auditor asks how you arrived at a split, the answer is already on the record. And when an allocation behaves unexpectedly three days into close, you'll get an answer from our team of CPAs who have closed multi-entity books, not from a tier-one ticket queue.
If segment-level accuracy is part of what you are fixing, Cross-Validation Rules is worth a look alongside it. Allocating cleanly matters less if invalid subsidiary and segment combinations can still be posted upstream.
Where to start
You do not have to move everything at once. Pick one recurring intercompany allocation. The one with the most tabs, or the one only a single person understands. Move that transaction-level split into NetSuite and run it in parallel for a period. You'll quickly discover whether the traceability is worth what it costs, and you'll have a defensible answer the next time someone asks how the split was determined.
If you want a sense of the time involved before you commit to intercompany accounting software, the month-end close ROI calculator is a reasonable place to put real numbers against your current process. If you would rather just see how other multi-entity teams have handled this, request a personalized demo and we'll walk through your options together.
