The month your lender asks for consolidated numbers
The request usually lands in a month that’s already tight: renewal season, a covenant test, or the first time you’re asking for a larger line. Someone forwards an email from the bank with a simple ask—“consolidated P&L and balance sheet”—and a short deadline that doesn’t match your close calendar. If you run two or five entities, you can feel the gap immediately: each set of books is “done,” yet none of it answers the lender’s question about the whole business.
That’s when the real constraints show up. Intercompany activity that was harmless day-to-day suddenly threatens ratios, cash look-through, and debt service coverage. A foreign entity that looked fine locally now swings because the reporting currency moved. And if the lender wants comparatives, the scramble isn’t just to add columns—it’s to decide what rules you’re willing to defend when the next question arrives.
Three consolidation approaches small teams tend to choose
With the deadline staring at you, the first decision is rarely philosophical—it’s whatever gets to a single set of numbers before the next email from the bank. Most small teams default to a spreadsheet consolidation: export each entity’s trial balance, map accounts into a common layout, and plug eliminations into a separate tab. It’s fast and cheap, but it quietly assumes stable charts of accounts and consistent cutoffs; one late AP batch or a miscoded intercompany entry can push the “consolidated” result around without leaving a clear trail of why.
The next step up is consolidating inside the accounting system using classes, locations, or a “consolidation entity.” It feels controlled because the reports are native, but it often creates friction in the close: everyone has to follow the same posting rules, and historical clean-up becomes a project. The third approach is a dedicated consolidation layer (lightweight consolidation software or BI model) that ingests each ledger, enforces mapping, and stores elimination logic. It costs more and takes longer to set up, yet it’s usually the first time the team can repeat the process without reinventing it every month.
Intercompany eliminations: same goal, very different pain
Once you pick an approach, intercompany eliminations are where the “same goal” starts to feel like different work entirely. In a spreadsheet, eliminations tend to become a set of plug entries: clear the intercompany AR/AP, back out intercompany revenue/expense, and move on. The pain shows up when the entities don’t agree—one side posted the invoice, the other side hasn’t booked it, or it hit a different period. With a lender deadline, teams often eliminate to the larger number and promise themselves they’ll “true it up next month,” which is how small mismatches turn into rolling noise in EBITDA and working capital.
Inside the accounting system, the friction shifts to discipline. You get fewer plugs, but only if intercompany is tagged consistently and you’re strict about cutoffs; otherwise you’re chasing reclasses across entities with limited visibility into who changed what and when. In a consolidation layer, eliminations can be rules-based and repeatable, but the hardest part is deciding what’s “in scope” (intercompany loans, management fees, inventory profit, dividends) and then maintaining that logic as new intercompany paths appear mid-year.
Currency translation behavior that changes your results
After eliminations stop moving around, currency starts doing it for them. The same local books can produce very different consolidated outcomes depending on which rates are used and where the FX impact lands. If you translate a foreign subsidiary’s income statement at an average rate but its balance sheet at the period-end rate, the “plug” goes to a cumulative translation adjustment; EBITDA may look steady while equity and leverage ratios drift. If you remeasure because the functional currency is really the parent’s currency, the FX swings typically hit earnings, and a month with stable local margins can suddenly miss a covenant.
The practical constraint is rate hygiene under deadline. Teams grab month-end spot rates for everything, then discover later that fixed assets should have stayed at historical rates, or that intercompany balances were translated inconsistently across entities. When the lender asks why cash or debt moved, “FX” isn’t enough—you need to show which method you used, and that you used it the same way every close.
Audit trail and controls: what breaks under scrutiny
When the first follow-up arrives, it’s rarely about the total—it’s about whether the path to the total is repeatable. A lender (or your CPA) may ask for the bridge from each entity trial balance to the consolidated statements, plus the exact elimination and FX entries. If the consolidation lives in a spreadsheet, the weak spot is usually provenance: which export was used, whether it was refreshed after late postings, and whether the elimination tab is a controlled journal entry or a set of overwritten cells. Under time pressure, versioning turns into “Final_v7,” and the ability to prove completeness quietly disappears.
System-based consolidation avoids some of that, but scrutiny moves to posting rights and cutoff controls. If anyone can reclass intercompany or change mappings after close, your consolidated numbers become a moving target. Consolidation layers tend to document mapping and eliminations better, yet they break when the close checklist isn’t enforced: missing rate tables, manual one-off adjustments without memo support, or an elimination rule that changed mid-year and wasn’t applied to comparatives. The control you want is boring but specific: locked periods, documented rate sources, and an approvals trail that survives the next question.
The hidden cost curve: time, people, and rework
The surprising cost isn’t the tool license—it’s how many minutes get burned re-proving the same numbers. Spreadsheet consolidations start cheap, then swell as soon as one entity adds accounts, changes revenue recognition timing, or posts late accruals after the export. The mapping table turns into a second chart of accounts that only one person understands, and every lender request for “last twelve months” becomes a rebuild because prior periods weren’t locked in a way that survives edits.
System-based consolidation shifts cost into behavior: training, stricter cutoff discipline, and cleanup when someone posts intercompany to the wrong dimension. A consolidation layer reduces monthly heroics, but you pay up front in setup, data connections, and keeping rules current when entities change. Either way, rework spikes when you discover—after the deadline—that FX or eliminations weren’t applied consistently to comparatives, and now you’re explaining a variance you accidentally created.
How to land on a fit-for-purpose consolidation workflow
At this point the “best” workflow is the one that survives your next close without a new round of rework. Start by sizing the requirement in plain terms: how many entities, how often you report (monthly vs quarterly), whether intercompany is routine or messy, and whether FX can hit covenants. Then decide what must be locked: a frozen trial balance export date, a single mapping table owner, a rate source, and an approvals step that happens before the lender deadline, not after.
If you’re consolidating only a few times a year, a controlled spreadsheet can be enough—until the person who knows it is out, or comparatives need restating. If you’re doing this monthly, or the business is adding entities, a consolidation layer usually pays for itself by making eliminations and translation rules repeatable. The goal isn’t perfect automation; it’s fewer “why did this change?” emails.
