Skip to main content

Case Study

Revenue Analytics Rebuilt: $84M Validated, 5 Years of Pricing Debt Resolved

Clarivant rebuilt a cloud security platform's revenue analytics — validating $84M to 0.002% accuracy, fixing 15 silent bugs, and giving Finance direct control of pricing with no engineering tickets.

Cloud Security PlatformSaaS

Clarivant migrated a cloud security platform's revenue analytics from five years of hardcoded Jinja macros to a governed Snowflake + dbt + Sigma stack. We validated $84M in revenue to 0.002% accuracy (5× better than target), uncovered 15 silent production bugs including a $472K undocumented rate anomaly, and replaced every engineering-dependent pricing update with Finance-owned Sigma input tables.

Key Results

0.002%
Variance on $84M
$1,634 total difference — 5× better than the 0.01% target
15
Silent Bugs Fixed
Production bugs discovered and corrected, including a $472K undocumented rate anomaly
Minutes
Finance Pricing Updates
From engineering tickets and code deploys (days) to Sigma row edits (minutes)

The Transformation

Before
After
Hardcoded rates in Jinja macros since 2021
Governed Sigma input tables Finance owns
$84M never validated against independent model
0.002% variance — PASS/FAIL automation running
Engineering ticket required per price change
Finance self-service — no code deploy needed
15 silent bugs running undetected in production
All discovered, corrected, version-controlled

The Challenge

This cloud security platform's revenue team carried five years of pricing debt with no validation, no audit trail, and no self-service path for Finance. The root cause was technical: pricing rates were hardcoded inside Jinja macros in the dbt codebase — every rate change required a developer to edit SQL, open a pull request, get it reviewed, and deploy. Three versioned macro variants existed with no changelog documenting when or why rates changed.

The risk was substantial. An undocumented 118% price increase had been running in production since v3.1, creating a $472K gap that was only discovered through reconciliation. Nobody could explain the 2.185x multiplier buried in the code — was it intentional? A bug? A temporary adjustment that became permanent? And $84M in revenue calculations had never been cross-checked against an independent model. Finance was reporting numbers they couldn't fully trace or verify, and every pricing update required engineering bandwidth that delayed the change by days or weeks.

Our Approach

We rebuilt the revenue foundation in three phases, each designed to reduce risk incrementally rather than attempting a big-bang migration.

Phase 1 — Pricing Extraction & Governance:

We migrated all hardcoded rates out of Jinja macros and into 5 structured seed tables with full rate history preserved via temporal lookup. Every historical rate change was documented and timestamped. We reverse-engineered the undocumented 2.185x multiplier from reconciliation data — tracing it back through 3 years of code commits to understand its origin and confirm it was intentional (it was, but had never been properly documented). We then delivered the FY27 pricing model in a 9-day sprint across 9 sequential validated batches — each batch covering a specific product line, validated against Finance's expectations before moving to the next.

Phase 2 — Revenue Validation at Scale:

We ran the legacy revenue models and the new models in parallel across all 8 product lines, comparing output row by row. The final variance was 0.002% on $84M — just $1,634 in total difference, which was 5x better than the 0.01% target we'd set with Finance. We built PASS/FAIL automation that ran daily so any drift between models would be caught immediately. During this validation phase, we discovered and fixed 15 silent production bugs — errors that had been running undetected in the legacy models, producing slightly wrong numbers that nobody had a way to catch.

Phase 3 — Finance Self-Service Handoff:

We replaced the 5 seed CSV files (which still required engineering to update) with 4 Sigma input tables that Finance edits directly through a spreadsheet-like interface. We built 7 dimension tables powering dropdown validation on every input field — so when Finance enters a new rate, the system validates the product code, effective date, and rate format before accepting it. This prevents the silent join failures that had caused bugs in the old system (a misspelled product code in a seed file would silently drop revenue instead of throwing an error).

The Outcome

The revenue rebuild delivered audit-ready accuracy across $84M and permanently removed engineering from the pricing update loop. The impact was both immediate and structural:

  • Pricing updates moved from code deployments requiring engineering tickets (days to weeks) to Sigma row edits by Finance (minutes). No PR, no deploy, no engineering bottleneck
  • 15 silent production bugs discovered and fixed — errors that had accumulated over 5 years of unvalidated revenue calculations
  • Complete audit trail from raw source data to final revenue number, satisfying both internal controls and external audit requirements
  • FY27 pricing model delivered and live in 9 days — what would have taken weeks under the old Jinja macro approach
  • The revenue rebuild became the seed for a broader platform: 161 dbt models across 7 analytical domains with 31 reusable macros, establishing the data infrastructure the company had never had

The Finance team now owns their pricing data end-to-end. When a new rate needs to be applied, it happens in minutes instead of entering an engineering backlog. And every number in the revenue pipeline can be traced from source to final output — something the organization hadn't been able to do since the product launched.

Want similar results for your organization?

Get in touch

Ready to turn data into decisions?

Let's discuss how Clarivant can help you achieve measurable ROI in months.