Built with purposeI get some version of this question on nearly every group consolidation project: why does adding company A's revenue to company B's revenue not equal the number everyone agrees the group actually made. The honest answer is that simple addition was never going to work, and the moment two entities trade with each other, addition starts overstating the truth.
The intercompany problem, in the simplest form
Say company A sells services to company B for 50,000 a month, and B resells that work to an external client for 80,000. If you add A's revenue and B's revenue together, the group books 130,000, but the group only ever received 80,000 from outside the group. The 50,000 A billed B is money moving from one pocket to another pocket of the same coat. Count it twice and the group looks bigger than it is, which sounds harmless until a bank or an investor prices the business off that inflated number.
Eliminating it sounds simple in principle: find every invoice one entity issued to another and subtract it from both sides. In practice it is the single most error-prone step in a manual quarterly close, because it depends on someone remembering every intercompany relationship, catching every invoice, and doing it the same way every quarter. Miss one, and the group number is quietly wrong in a way nobody notices until it is compared against something else.
Recognition dates are the second, quieter cause
Even without any intercompany trading, two entities can disagree about revenue because they recognize it at different points. One company might book revenue when it invoices a customer. Another might book it when cash is received, or when a project milestone is signed off. None of these choices is wrong on its own. The problem is comparing them as if they were the same measurement, the way you would not average a temperature in Celsius with one in Fahrenheit and call it a meaningful number.
This shows up constantly in project-based businesses working alongside a retail or subscription arm inside the same group. The project side recognizes revenue on milestones that can land weeks apart from when the invoice goes out. The other side recognizes it at the point of sale. Consolidate them without adjusting for that gap and the group's monthly trend line will show swings that have nothing to do with the business actually speeding up or slowing down.
What the consolidated number should actually look like
A working consolidation model does three things, in this order. First, it maps every entity's chart of accounts to one shared structure, so "revenue" means the same thing everywhere before anything gets added together. Second, it identifies and removes intercompany transactions, ideally by matching them systematically rather than relying on someone's memory of who sells to whom. Third, it aligns recognition timing where the gap is large enough to distort the trend, which usually means picking one convention for the group view even if individual entities keep their own for their own statutory filings.
The output most owners actually want is two views built from one model: a management view that shows real, eliminated, timing-aligned revenue, and a more conservative statutory-style view for a bank or auditor that follows accounting convention more strictly. Building both from the same source, instead of maintaining two separate spreadsheets that inevitably drift apart, is most of what makes consolidation worth doing properly rather than by hand.
Why this usually breaks quietly, not loudly
The failure mode I see most often is not a dramatic error. It is a mapping that was correct two years ago, before company C started invoicing company A for a service that did not exist when the model was first built. The elimination logic does not know about the new relationship unless someone updates it, so the group number is very slightly wrong every quarter after that, always in the same small direction, until someone finally compares it against a bank statement and asks why the numbers do not quite reconcile.
What this actually takes
For a group of four entities, this work adds real time on top of a single-entity build: mapping four charts of accounts, agreeing an elimination approach everyone can audit, and validating the new group total against whatever the existing spreadsheet already produces, so nobody has to take the model on faith on day one. The number of entities, mapping differences and elimination rules need to be visible in the agreed scope and delivery estimate.