Financial Analytics

One Ledger for 324 Entities: How a Professional Services Group Closes Four Days Faster

This case study shows how a global professional services group put one governed ledger on BigQuery between its Maconomy project-accounting ERP and its OneStream group planning platform. First release in 90 days, full production in six months. The monthly close now runs four days faster, reconciliation runs on every load, and the platform became the working base for a receivables and work-in-progress programme that released $57M of cash.

Case study card: one ledger for 324 entities. Maconomy, OneStream and four more sources feed BigQuery on Google Cloud with dbt, Airflow and Terraform, consumed in Power BI, Microsoft Fabric and an AI layer on LangGraph. Four days faster close, first release in 90 days, 500+ tables from six systems.

Executive Summary

A global professional services group now closes its books four days faster: one governed ledger on BigQuery reconciles its Maconomy ERP and its OneStream group planning platform across 324 legal entities on every load. A team of seven, six of them full time, took the first release live in 90 days and the full platform to production in six months, in fixed-price stages with a two-week acceptance window for every deliverable. The ledger then became the working base for a receivables and work-in-progress programme that released $57M of cash.

Client: a global professional services group

Service line: Financial Analytics

Duration: first release in 90 days, full production in six months

Team: seven specialists, about 6.25 FTE: a data solution architect, an infrastructure engineer, a data engineer, a delivery leader and two BI consultants full time, and a data advisor at 0.25 FTE

The Situation: Two Systems, Two Sets of Numbers

The professional services group runs its business through 324 active legal entities, 207 of them billing through Maconomy, inside a ten-level hierarchy built up through acquisitions. Maconomy and OneStream, which produces the group financial statements, reported two different sets of numbers, and finance reconciled them by hand every month in spreadsheets. Ordinary questions, such as which ten clients generate the most revenue or how much cash is locked up and where, took weeks of schedules from the regions. Every team kept its own extract of both systems, audit evidence was assembled by hand for each audit, and the quarterly variance commentary tied up hundreds of people every quarter.

What We Did: One Governed Ledger on BigQuery

  • One general ledger for the whole group. Maconomy and OneStream share a single entity key and reconcile on every load to a one-dollar tolerance. Every difference returns to the ledger as a flagged adjustment with its source, and intercompany eliminations are computed up the full hierarchy.
Architecture: Maconomy, OneStream and four more source systems load into a governed ledger on BigQuery, built with dbt and orchestrated by Airflow, with raw, staging, curated and presentation layers, reconciled on every load, feeding Power BI, Microsoft Fabric and an AI layer on LangGraph
  • The revenue bridge, leg by leg. The gap between Maconomy revenue and consolidated revenue is broken into named legs: close timing, entries that exist only at group level, top-side adjustments and intercompany eliminations. Each leg is a reconciling difference with a source, which is what a controller needs before signing.
Waterfall with illustrative figures from ERP gross revenue to consolidated revenue, through close timing, consolidation-only entries, top-side adjustments and intercompany eliminations
  • Governed layers on BigQuery. Loads from six source systems land as posted and move through raw, staging, curated and presentation layers on a metadata-driven framework, with dbt building the models, Airflow on Cloud Composer orchestrating the loads and automated checks running every day. The figure in Power BI, in Microsoft Fabric, in the signed report and in Excel is one figure.
  • Infrastructure and deployment defined in code. The Google Cloud infrastructure is defined in Terraform, every change moves through development, test and production on one deployment pipeline, access is federated with no stored secrets, and the build generates the data catalogue and column-level lineage.
  • An AI layer on a trusted ledger. Codified variance playbooks orchestrated with LangGraph retrieve the data, translate the numbers into business context and write the quarterly variance commentary, and every model call and rule decision is logged for the SOX audit trail.
  • Scope that started where the numbers are. The build began with the source tables that carry the reported figures and grew to more than 500 tables across six systems.

How We Worked: Fixed-Price Stages, Acceptance per Deliverable

The ledger was built in fixed-price stages and three-week sprints, opened by on-site discovery workshops. Every deliverable, from each fact and dimension to logging and row-level security, went through its own two-week UAT window, and a deliverable with no feedback at the end of that window counted as accepted. A data advisory team worked alongside on time and materials, with priorities set by the client.

The Result: A Close Four Days Faster and $57M of Cash Released

The monthly close runs four days faster. The reporting pack leaves finance earlier every month, because the numbers arrive already reconciled.

$57M of cash released. The ledger became the working base for an accounts receivable and work-in-progress programme, which used it to find the invoices worth chasing and released $57M of cash. The $57M is that programme's delivered outcome, counted the way the client's finance team counts it.

An estimated 13,400 hours a year handed back. The AI layer now writes the quarterly variance commentary that hundreds of people used to assemble by hand, about 1,670 person-days a year.

The monthly full load fell from about 50 hours to about 12, and "which ten clients generate the most revenue?" now takes minutes.

Key metrics before and after the governed ledger

A client-specific catalogue of 26 finance use cases, from intercompany matching to a 13-week cash flow view, now sits on the governed ledger, each with its own business case.

The Honest Lesson: Proving OneStream Data for SOX

SOX required proof that the data retrieved from OneStream was the same data OneStream held, and OneStream's limitations meant that proof had to be statistical, built to a standard that satisfied the SOX criteria. The sequence mattered as much: the cash programme and the AI layer both depended on a ledger finance would defend, so reconciliation came before reporting.

If your ERP and your group planning platform tell two different stories, see how the bridge maps to your landscape.

We are here to answer your questions

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.