A Tier-1 financial institution needed general ledger data from multiple legal entities consolidated into a single, governed analytics platform — without loosening a single control.

At a glance

The challenge

Finance teams at multi-entity organizations spend the first week of every month answering the same question: do these numbers agree?

Our client’s general ledger data lived in operational systems built for transaction processing, not analysis. Consolidating across legal entities meant manual reconciliation, spreadsheet-based assembly, and a month-end close where the analysis could not start until the data wrangling finished.

They did not need a faster report. They needed a governed layer between the ledger and the analyst — one the finance organization could trust without re-deriving every figure by hand.

The constraint that shaped everything

This is the part most data modernization stories leave out.

The work happened inside a regulated bank. That meant a formal vendor security review before a single production credential was issued. It meant every change moving through a documented change-request process with test evidence and independent approval. It meant no customer records and no personally identifiable information were ever available to us during the build.

Most consultancies treat that period as dead time and bill for waiting. We didn’t.

While the security review ran, we built and validated the entire migration approach in an isolated lab environment using only technical metadata and synthetic data. When final clearance came through, we weren’t starting. We were deploying something already proven.

That decision is the single reason this project delivered on the timeline it did — roughly a 50% reduction in development cycle time.

What we built

A layered Snowflake data hub — five distinct schemas, each with one job, each a real deployment and permissions boundary:

• Raw — change-data-capture landing zone, fed continuously from the client’s Azure SQL source systems via enterprise replication tooling.
• Staging — change streams that isolate what actually moved since the last run, so downstream processing handles deltas rather than reprocessing history. The pipeline runs as micro-batches: a ledger change posted in the source systems reaches the hub in two to four minutes under controlled load testing, and two to eight minutes in production.
• Data hub — the consumption layer. A dimensional star schema modeled around how finance actually asks questions: by entity, by period, by account.
• Security — row-level security enforced in the platform itself, not bolted onto a reporting tool. Entity-level data separation is a property of the data, not a setting someone can forget.
• Governance — automated validation and alerting. Independent checks reconcile the hub against source counts and balances on every load and raise an alert when they disagree.

That last layer is the one we’d argue matters most. Reconciliation isn’t a project phase that ends. It’s a standing control that runs on every load, forever.

The platform runs to more than 250 managed database objects. Finance users reach it through governed reporting; the operations team monitors load health through a dashboard running natively inside Snowflake.

The part that isn’t the pipeline

The data pipeline is the plumbing. The hard problem was accounting.

Getting general ledger data into a warehouse is a solved problem. Modeling it so that entity consolidation, period logic, and account hierarchies behave the way a controller expects — that requires someone who understands the ledger, not just the loader.

Every design decision in the star schema traces back to a mechanic of how the business actually closes its books. That domain fluency is what separated this engagement from a generic lift-and-shift, and it’s what we’d tell any finance organization to screen for before hiring a data partner.

How we worked

We put the schema under version control. The platform arrived as a sequence of hand-maintained deployment scripts, versioned by filename, with no history between versions. We migrated the entire schema into a proper repository — one file per database object, generated deployment scripts, and automated drift detection that compares what’s actually running against what’s supposed to be. Nobody has to remember what changed. The system can prove it.

We built for the bank’s process, not around it. Change requests ship with generated implementation plans and test-evidence workbooks. Approval gates are part of the delivery pipeline, not friction applied to it.

We used Gen AI where it was safe and useful. Accelerating schema migration and validation work in an isolated environment — never on customer data, never as a substitute for review. We wrote about that approach in The Long Game.

Results

• Phase 1 in production, serving governed general ledger analytics across multiple legal entities.
• Automated reconciliation running on every load, replacing manual spot-checks with standing controls.
• Full deployment traceability — every object versioned, every change attributable, drift detectable automatically.
• A finance team that starts the month analyzing instead of assembling.

What’s next

Phase 2 is underway: additional operational reporting, and a design engagement to map financial reporting onto the hub.

Is your month-end close a data problem?

If your finance organization is reconciling entities by hand, or your analysts spend the first week of the month assembling data instead of interpreting it, that’s an architecture problem — and it’s fixable.