What Building a Consolidation Engine Taught Us About the Close

We implement OneStream for a living. We also built Basin, our own consolidation and month-end close platform, from the engine up: trial balance import, FX translation, intercompany eliminations, topside journals, minority interest, three consolidated statements, and a sign-off that locks the period. Configuring those mechanisms on a client platform is one thing. Writing every one of them yourself is another. Here's what it taught us, and what it changes about how we approach a OneStream build.

The order of operations is the design

Basin's engine runs one sequence, every time: translate each entity (balances at the closing rate, the year-to-date P&L at the average rate, equity at its historical rate), then remove intercompany balances, place posted journals, and carve out non-controlling interests. Written as a formula it looks almost boring: consolidated = gross − eliminations + adjustments. But the order is the design. Each step depends on data the step before it has finished shaping, and running one out of turn produces numbers that look right and aren't.

Translation is where this bites hardest. The two sides of an intercompany balance are often booked in different currencies, and after translation they don't always net to exactly zero. That difference has to land somewhere deliberate. In Basin, whatever doesn't cancel lands on its own intercompany-differences line, so eliminations never quietly move profit or net assets. If the design doesn't say where it goes, it ends up in a plug, and a plug is where trust in the close goes to die.

OneStream makes this sequence explicit in its Consolidation dimension: Local, Translated, OwnerPreAdj, Share, Elimination, OwnerPostAdj, Top. Building the same pipeline by hand makes the first diagnostic question on any OneStream project obvious: which member did this number go wrong in? If a figure is right at Translated and wrong at Elimination, you've already ruled out half the rules in the application.

Every number has to carry its own receipt

Basin follows one rule throughout: the screens never re-derive a figure. The engine returns each consolidated account together with its per-entity contributions (local amount, rate, USD amount) plus the eliminations and journal impacts applied to it. Every account line on the P&L can be expanded to show exactly where it came from.

That rule shapes everything downstream, and it's the lesson that matters most for client work. Reviewers don't trust totals; they trust drill-downs. On a OneStream build, the drill paths and the cube views a controller uses to check a number belong in the design from the first workshop, not in a reporting phase after go-live, when the data model can no longer bend to support them.

Intercompany is a workflow problem, not a math problem

The elimination itself is trivial arithmetic. The hard part is that both sides have to agree. In Basin's sample group, two intercompany relationships don't: the two sides report different amounts, and the consolidation screen flags them as differences to clear before sign-off. The group still consolidates, but it tells you, plainly, what's left to fix.

That's the behaviour worth designing for on any OneStream project: matching status that's visible early in the workflow, an owner for every open pair, and intercompany reconciliation scheduled on the close calendar before consolidation, not discovered during review.

Minority interest forces you to define "the group"

The moment an entity is less than wholly owned (the sample data includes one at 75%), you have to decide what the consolidated numbers mean. Basin consolidates the entity in full, then carves out the outside shareholders' share (of profit on the P&L and of equity on the balance sheet), so the P&L ends the statutory way: non-controlling interests, then the result attributable to the group. Holdings multiply down a chain, too: 80% of a 75%-owned company leaves the group with 60%.

The lesson isn't the calculation. It's that ownership is data with a history. It needs a proper home, an editor with the right permissions, and an audit trail, not a percentage typed into a spreadsheet cell that someone updates when they remember.

A multi-currency cash flow only ties when FX is explicit

Basin builds the cash flow statement the indirect way, entity by entity in each one's own currency, then translates it. In a multi-currency group, that only reconciles to the change in cash with an explicit effect of exchange rates on cash line, which is exactly how a real multi-currency cash flow is presented. If a group cash flow doesn't tie, look at FX first. It's almost always FX.

A lock is only a lock if the data layer enforces it

Hiding the edit buttons on a signed-off period is not a control. In Basin, the sign-off lock is enforced where the data is written, so every class of write (task updates, trial balance imports, journals, FX rate edits) refuses on a locked period, whatever screen or route it comes from. Sign-off also stores the consolidated figures with the lock, so a closed period's numbers can't drift if ownership or the entity tree changes later. Reopening a period is a separate permission, and both directions land in an append-only audit trail.

The same thinking applies to journals: lines must balance before they can be saved, the person who drafts a journal isn't the person who posts it, and a posted journal is immutable: a correction is another journal. On a OneStream project, test workflow locks and certification in UAT by actively trying to write into a locked period, not just checking that the status reads "locked."

Our Take

We didn't build Basin to replace OneStream. For enterprise finance teams, OneStream is the platform we implement and recommend; Basin is for smaller groups that haven't reached that scale yet. But building one from scratch means we've had to answer every design question ourselves: where translation differences go, what a reviewer needs to see behind a number, what a lock actually has to stop. Those are the same questions that decide whether a OneStream consolidation earns a CFO's trust.

If you'd like to see these ideas running, you can explore Basin's read-only demo: no sign-up, sample data only. And if you'd like the same discipline applied to your OneStream application, that's what an assessment is for.