Conflicting Revenue Definitions at a Regional Distributor

The first two weeks are discovery and decision, not development. I would (1) interview the CFO, sales VP, and two branch managers to capture how each defines revenue and what decision the dashboard must support; (2) inventory the ERP invoice table, CRM order tables, and the two existing extracts, documenting grain, filters, and refresh; (3) run a 90-minute definition workshop to agree one metric contract: net revenue recognized at invoice, returns and rebates applied at the invoice date, excluding intercompany and tax; (4) prototype a single monthly trend plus branch table from one source to expose gaps. I would explicitly defer branch-level rebate allocation, daily granularity, forecasting, and open self-service filters. The six-week plan becomes two weeks discovery, two weeks thin-slice build, and two weeks validation and rollout. Deferring is a scope decision that protects the one number; building all 14 branches first would reproduce the conflict at higher cost.

The canonical definition needs an owner and a contract. The CFO owns revenue; sales owns bookings. They are different metrics and should both be labeled, not merged. I would define net revenue with an explicit grain (one row per invoice line), population (posted invoices), timing (invoice date), inclusions (product and freight), exclusions (tax, intercompany, unapplied credits), returns (matched credit memo date), and rebates (accrual per finance policy). Then reconcile to the GL by month and branch, document variance tolerances, and publish the definition in a data dictionary with version history. Sign-off: the CFO and sales VP sign a one-page metric contract; any change goes through a lightweight change board. I would also publish a bookings-versus-revenue reconciliation page so the two numbers stop competing. This is governance, not bureaucracy: without decision rights the dashboard just moves the argument from the meeting into the tool.

First reproduce the branch manager's spreadsheet with them, line by line, rather than defending the dashboard. Most discrepancies come from grain or timing: their sheet may include orders not yet invoiced, exclude returns, or use a local rebate estimate. I would compare a small sample of invoice IDs, show the lineage from ERP to dashboard, and quantify the difference. If their number is right for a local decision, I would add a clearly labeled orders-shipped view rather than forcing one number. If the dashboard is wrong, log it as a defect with severity and fix it in the next refresh. Then publish a monthly reconciliation showing dashboard-to-GL variance and a short note on known timing differences. The goal is trust through transparency, not winning the argument. I would also retire custom extracts by giving branch managers a governed branch view.