← All guides

How to Plan a Financial Data Governance Project

Plan a financial data governance project with a timeline covering data ownership, definitions, quality rules, lineage documentation, and access controls.

How to Plan a Financial Data Governance Project

Nobody Argues About Revenue Until Finance and Sales Have Different Numbers

The tell that a company has a data governance problem is the meeting where the CFO presents revenue as $12.4M and the VP Sales presents it as $13.1M, and twenty minutes are spent figuring out which one is right instead of discussing what to do about it.

The difference is almost never about data corruption or system errors. It's about definitions. Sales counts a deal as revenue when it's signed. Finance counts it when it's invoiced. Or Sales counts the full contract value; Finance counts only the recognized portion. The data is accurate — the definition is different.

Financial data governance solves this at the definition layer. Once the company agrees on exactly what "revenue" means, measured how, from which source, including and excluding what — the number stops being a debate and starts being a tool.

Phase 1: Scope and Stakeholder Alignment (Weeks 1–3)

Define scope:

Financial data governance is not all data governance. Start with the data domains that cause the most conflict and the most business impact:

  • Revenue: ARR, MRR, bookings, recognized revenue
  • Customer: active customers, churned customers, customer count definitions
  • Cost: headcount costs, operating expenses, COGS
  • Cash: cash position, cash flow
  • Pipeline: total pipeline, weighted pipeline, qualified pipeline

Identify data consumers:

  • Finance: actuals, variance analysis, board reporting
  • FP&A: budget vs. actuals, forecasting
  • Sales: pipeline, bookings, quota attainment
  • Customer Success: retention, expansion, churn
  • Executive team: KPI dashboard, investor reporting

Identify source systems:

  • ERP: recognized revenue, cash, expenses, payroll
  • CRM: pipeline, bookings, customer records
  • HRIS: headcount data
  • Data warehouse: consolidated, transformed data
  • Reporting tools: BI tools consuming from warehouse or direct from source

Establish governance structure:

  • Data Governance Steering Committee: CFO, VP Sales, CTO, or delegates — meets quarterly
  • Executive Sponsor: CFO (for financial data, the CFO must own it)
  • Working Group: Controller, FP&A Lead, RevOps Lead, Data Engineering Lead — meets monthly

Phase 2: Data Inventory and Classification (Weeks 3–6)

Data asset catalog:

  • List all financial data assets: tables in the data warehouse, reports in BI tools, dashboards, recurring spreadsheet exports, financial models
  • For each asset: name, owner, consumers, source systems, update frequency
  • Identify orphaned assets: reports or spreadsheets that exist but nobody knows who owns them or whether they're accurate

Critical Data Elements (CDEs):

CDEs are the specific fields or metrics that matter most for business decisions. Identify them explicitly.

Examples:

  • ARR (Annual Recurring Revenue)
  • MRR (Monthly Recurring Revenue)
  • Net Dollar Retention
  • Gross Margin %
  • Headcount (full-time equivalent)
  • Cash and cash equivalents

For each CDE: document its current definition (as used by each team that calculates it), identify conflicts in definitions across teams, and flag for reconciliation in Phase 4.

Data classification by sensitivity:

  • Public: can be shared externally
  • Internal: for employees only
  • Confidential: limited to specific teams (e.g., board reporting data, M&A analysis)
  • Restricted: highly sensitive (individual compensation, investor data)

Classification drives access control decisions in Phase 7.

Phase 3: Data Ownership Assignment (Weeks 5–8)

Financial data governance fails when there's no clear ownership. Assign three roles for each CDE:

Data Owner:

The business leader accountable for the quality, accuracy, and appropriate use of the data domain. Data owners set the definition, resolve disputes, and are ultimately responsible.

  • Revenue domain owner: CFO
  • Customer domain owner: VP Customer Success or VP Sales (depends on org)
  • Headcount domain owner: CHRO or CFO

Data Steward:

The practitioner responsible for day-to-day data quality and definition maintenance.

  • Revenue steward: Controller or Revenue Accounting Manager
  • Customer steward: RevOps Manager
  • Headcount steward: Finance BP or HR Operations

Data Custodian:

The technical team responsible for storage, security, and access to the data.

  • Data Engineering or IT for warehouse tables
  • System Admin for source systems (Salesforce, NetSuite, HRIS)

Document owner and steward assignments in writing. Circulate and get acknowledgment from each named individual.

Phase 4: Business Glossary and Metric Definitions (Weeks 6–12)

This is the core deliverable of the project: precise, agreed-upon definitions for every CDE.

Definition standard:

Each definition must include:

  • Metric name: as it appears in reporting
  • Definition: what the metric measures
  • Formula: the calculation
  • Source system: where the underlying data lives
  • Inclusion and exclusion rules: what's counted, what's not
  • Update frequency: when does the number change?
  • Owner and steward: who maintains this definition?

Example definition:

ARR (Annual Recurring Revenue)

Annualized value of all active subscription contracts as of period end date.

Formula: sum of (monthly recurring revenue × 12) for all active subscriptions as of the last day of the reporting period.

Source: NetSuite subscription records.

Inclusions: all recurring subscription revenue lines with status = Active.

Exclusions: one-time professional services fees, overages, expired trials, paused subscriptions.

Updated: daily, reported as of month-end.

Owner: CFO. Steward: Controller.

Sign-off process:

Draft definitions → circulate to all consuming teams → hold definition review meeting → resolve conflicts → publish final definitions → obtain written acknowledgment from all consuming teams.

The definition review meeting will surface conflicts. Resolve each conflict by having the Data Owner make the final call. Document the decision and the rationale.

Phase 5: Data Quality Rules (Weeks 10–14)

A definition is useless if the underlying data is wrong. Define quality rules for each CDE.

Quality dimensions:

  • Completeness: required fields are populated
  • Validity: values conform to expected formats and ranges
  • Accuracy: values correctly represent the real-world state
  • Timeliness: data is updated within the expected frequency

Example quality rules for ARR:

  • Every active subscription has a non-null MRR value
  • MRR values are positive (no negative MRR on active subscriptions)
  • No subscriptions with status = Active have past renewal dates without a corresponding renewal event
  • ARR as of month-end reconciles to ARR rollforward: beginning balance + new business + expansion − contraction − churn = ending balance

Implementation:

  • Implement automated data quality checks in the data pipeline
  • Run checks on each pipeline execution; alert on failures
  • Build a data quality dashboard: current pass rate by CDE and quality rule
  • Escalation path: quality failures route to the data steward for investigation and resolution

Phase 6: Data Lineage Documentation (Weeks 12–16)

For each CDE, document the complete data flow from source to final report.

  • Source system: where the raw data originates
  • Transformation: what transformations occur at each step (filters, joins, calculations)
  • Intermediate storage: staging tables, warehouse tables
  • Final consumption: which reports, dashboards, or models consume the data

Lineage documentation serves two purposes: it enables root-cause investigation when numbers don't match ("where in the pipeline did the error occur?"), and it creates audit evidence that financial reporting data is traceable to authoritative sources.

Phase 7: Access Controls and Certification (Weeks 14–18)

Access audit:

Pull current access rights to financial data systems and warehouse tables. Identify:

  • Users with access beyond their role requirements
  • Departed employees with active access
  • Service accounts with broader access than necessary

Role-based access model:

Define roles and associated data access rights aligned to job function. Examples:

  • Finance Analyst: read access to finance warehouse tables; no raw CRM data access
  • RevOps: read/write to CRM; read to revenue tables in warehouse; no payroll data
  • Executive: read access to all executive dashboard data; no individual compensation data

Quarterly access certification:

Managers certify that their team members' access remains appropriate. Revoke access not certified. This is a recurring process, not a one-time exercise.

Track the financial data governance project in gantt-chart.io with Phase 4 (business glossary) as the critical path milestone. Everything after — quality rules, lineage, access controls — builds on the definitions. The glossary review meeting where definitions are aligned and signed off is the most important milestone in the project: mark it explicitly in the timeline and protect it from schedule pressure.