Data Foundations for Operating Reporting

Executive summary

Data foundations for operating reporting are the unglamorous layer under every dashboard: agreed metric definitions, a named system of record for each piece of data, clean master data, and a reconciliation routine that proves the reports tie to the ledger. Without that layer, a new reporting tool only produces disagreement faster and in better colors.

The common failure is familiar. The CEO has one revenue number, the sales leader has another, and the Controller has a third. Each is defensible given its source and its definition. The meeting then spends its time on which number is right instead of what to do. Buying a business intelligence tool does not resolve this, because the tool reads whatever it is pointed at.

The fix is small in scope and strict in discipline. For a short list of metrics that run the company, write one definition each, name one source system, name one owner, and reconcile the figure to the general ledger every period. Then fix the master data that feeds those metrics, starting with customers, items, vendors, and the chart of accounts. This guide shows how, in order.

It does not require a data warehouse, a data team, or a platform decision. Those may come later. Most mid-market companies can get to trusted operating numbers with a spreadsheet of definitions, a reconciliation checklist, and one person accountable for each data domain.

When to use this

Use this guide when:

• Two reports show different values for the same metric and nobody can explain the gap in under an hour.
• Month-end reporting takes days because numbers are assembled by hand from several systems.
• A sponsor, lender, or board has asked for new metrics and the team says they "cannot get that data."
• You are considering an ERP change or a business intelligence purchase (see ERP selection for PE portfolio companies).
• You have just acquired a company and need combined reporting (see IT integration in post-merger integration).
• A buyer's diligence team will test your reporting, as described in technology due diligence for operators.

Diagnostic questions

Answer from the systems and the people who maintain them.

1. Which ten to fifteen metrics does the leadership team use to run the business, and where is each written down?
2. For each, is there a single written definition covering numerator, denominator, inclusions, exclusions, and period?
3. Which system is the system of record for each metric: ERP, CRM, billing, payroll, or a spreadsheet?
4. Who is the named owner of each metric, and who approves a change in its definition?
5. Do the reported revenue, cost, and balance figures reconcile to the general ledger every month, and is the reconciliation documented?
6. How many customer, item, and vendor records exist, and how many are duplicates, inactive, or missing required fields?
7. How many spreadsheets feed a management report, and who maintains each one?
8. If the person who builds the monthly report is out for two weeks, what happens?
9. When a number is wrong, how is the error found, who is told, and where is the fix recorded?
10. Are there manual overrides or adjustments to report figures, and are they logged with a reason and an approver?
11. Do departments use different calendars (fiscal, calendar, 4-4-5, shipping week) for the same metric?
12. What is the lag between period end and the first reliable version of the report?

If question 2 is mostly "no", start with definitions. If question 5 is "no", start with reconciliation. If question 6 shows large counts of duplicates, start with master data.

Framework: five layers of trusted reporting

Work from the bottom up. A higher layer only holds if the lower one is stable.

The reporting tool sits in layer 5. Most of the work is in layers 1 to 4.

Step-by-step process

1. Choose the metrics. Owner: CEO and CFO. Output: a list of 10 to 15 metrics. Use the financial KPIs for executives guide as a starting point and cut anything nobody acts on.
2. Write a definition for each. Owner: the metric owner. Output: a data dictionary entry (template below) with numerator, denominator, inclusions, exclusions, period, and source system. Write examples of what counts and what does not.
3. Name the system of record. Owner: process owner. Output: for each fact, one system where it is created and corrected, and a rule that other systems read it but do not overwrite it.
4. Trace each metric to its source. Owner: FP&A. Output: a lineage note showing every system, export, and spreadsheet step between the source and the report. Mark every manual step.
5. Reconcile to the ledger. Owner: Controller. Output: for each financial metric, a reconciliation of the report to the general ledger, with differences explained line by line. For non-financial metrics, a reconciliation to the source system count.
6. Audit master data. Owner: data domain owner. Output: record counts, duplicates, inactive records, missing required fields, and conflicting hierarchies, for customers, items, and vendors.
7. Fix the highest-value problems first. Owner: data domain owner. Output: a merge, clean-up, and prevention plan: required fields enforced at entry, duplicate checks on creation, and an approval for new master records.
8. Remove manual steps where they carry risk. Owner: FP&A and IT. Output: each manual step either automated, documented with a checker, or retired.
9. Run a monthly data quality review. Owner: Controller. Output: a 30-minute meeting with the quality scorecard, open issues, owners, and due dates.
10. Control definition changes. Owner: CFO. Output: a change log. A new definition gets a version, an effective date, and a restated prior period if the comparison matters.
11. Publish. Owner: FP&A. Output: the monthly pack uses only governed metrics and shows the date of the last reconciliation.

Templates

Metric data dictionary (copy into a spreadsheet)

Reconciliation checklist (monthly)

Data quality scorecard

Issue log

Metrics and KPIs

Setting targets without invented benchmarks. Do not borrow a "good" duplicate rate or completeness percentage from a vendor white paper. Set targets by method. Take your own current figure as the baseline, then set the first-year target as a share of the gap to the level at which the report stops being disputed. For unreconciled differences, the target is a rule, not a number: every difference is explained and approved by the Controller, and any single unexplained item above a materiality threshold the CFO sets blocks publication. For time to first reliable report, compare to your own best trailing close.

Common mistakes

1. Starting with the tool. A new dashboard on top of undefined metrics multiplies versions of the truth.
2. Defining metrics in a slide. Definitions need to live in a controlled document with an owner and a version, not on a presentation that gets copied.
3. No system of record. If two systems can both edit a customer address, they will disagree.
4. Cleaning data once. A one-time clean-up decays. Add required fields, duplicate checks, and approval for new master records, or the problem returns.
5. Reconciling only at year-end. Errors found a year later are expensive and hard to trace. Reconcile monthly.
6. Treating spreadsheets as the enemy. Spreadsheets are fine when they have an owner, a documented source, and a check. The risk is the undocumented one.
7. Overriding numbers without a log. A manual adjustment with no reason and approver cannot be defended in diligence.
8. Changing definitions silently. If "active customer" changes from 12 months to 6 months of activity, the trend breaks. Version it and restate.
9. Building a warehouse before the basics. A warehouse stores whatever you load. Fix definitions and masters first.
10. No owner for data. Data quality assigned to "IT" is data quality assigned to nobody. The business owns what the data means.

Worked example

Illustrative. The figures are invented to show the method. They are not benchmarks.

A distributor's leadership team sees three revenue figures for the same month. The Controller reconciles them.

The ERP-to-ledger difference is $4,120,000 - $4,085,000 = $35,000. Explaining it:

$22,000 + $13,000 = $35,000, so the difference is fully explained. The dashboard-to-ERP gap is $4,150,000 - $4,120,000 = $30,000, which comes from using ship date rather than invoice date. No error is present; the definitions differ. The fix is a governed definition: revenue is invoiced revenue net of credits, recognized per policy, and the dashboard is relabeled "shipped value."

Master data audit for the same company:

Completeness = 1,656 / 1,840 = 90.0%. Duplicate rate = 92 / 1,840 = 5.0%.

What this tells the operator:

• The three revenue numbers were all correct for their definitions. The problem was undefined naming, not bad data.
• A 10.0% gap in industry code (184 records) limits any report by industry. Fix that field before building an industry view.
• Merging 92 duplicates will move revenue between customer lines. Tell the sales leader before the next customer ranking is published, or the change will look like a loss of business.

AI prompt assistance

AI can draft definitions and compare extracts, but it can only work on the data you give it, and it can be confidently wrong. Always verify with the ledger or the system count.

1. Draft definitions from a report.

Here is a monthly management report and a description of how each figure is produced. For each metric, draft a data dictionary entry with numerator, denominator, inclusions, exclusions, period, and source system. If the description does not say, write "unknown" rather than guessing.

Check: each metric owner reviews and corrects their entry, and every "unknown" gets an answer from someone who knows.

2. Find likely duplicate records.

I will paste 200 customer records (name, address, tax ID, phone). Group records that are likely duplicates and explain the matching evidence for each group. Do not merge anything; just list the groups and your confidence.

Check: a person with customer knowledge confirms every group before any merge, and the group list is kept for audit.

3. Compare two extracts.

Here are two tables of revenue by customer from two systems. List customers present in one but not the other, customers with different totals, and the sum of the differences. Show your arithmetic.

Check: recompute the sum of differences in a spreadsheet and confirm it equals the total difference between the extracts.

4. Draft a data issue summary.

Given this issue log, write a half-page summary for the CFO: issues opened and closed this month, the oldest open issues, metrics affected, and decisions needed.

Check: confirm every count against the log.

Implementation guide

Governance: the CFO owns definitions, the Controller owns reconciliation, each data domain has a named business owner, and IT supports the controls. Report the quality scorecard and reconciliation coverage monthly, alongside the main operating pack.

What to expect: the definition and reconciliation work often surfaces disputes that were hidden. Treat that as progress. Expect the first reconciliations to take longer than later ones as the explanations are documented.

Downloadable assets

The data dictionary, reconciliation checklist, data quality scorecard, and issue log above are designed to be copied into a spreadsheet. There is no calculator for this topic.

Related resources

• Technology guides hub: all technology and systems guides.
• ERP selection for PE portfolio companies: why data readiness belongs in the selection.
• Build vs buy for internal tools: choosing how to produce reports and workflows.
• SaaS and vendor renewal calendar: keep track of the systems that hold your data.
• Financial KPIs for executives: a starting list of metrics to define.
• AI use case prioritization framework: data readiness decides which AI projects can start.
• IT integration in post-merger integration: combining reporting after an acquisition.

Frequently asked questions

What are data foundations for operating reporting?

Data foundations are the controls under a report: agreed metric definitions, a named system of record, clean master data, and a routine that reconciles reports to the ledger. They determine whether two people looking at the same metric see the same number. A dashboard tool only displays the result of those controls.

How do you fix conflicting numbers in management reports?

Start by writing a definition for each metric with its numerator, denominator, inclusions, exclusions, and period. Then trace each figure to its source and reconcile it to the ledger, explaining every difference line by line. Most conflicts turn out to be different definitions, such as ship date against invoice date, not errors.

Do we need a data warehouse for reliable reporting?

No, a data warehouse is not required to get reliable operating reporting. Many mid-market companies can reach trusted numbers with written definitions, a named system of record, reconciliation, and clean master data. A warehouse becomes worthwhile later, when volume or the number of sources makes manual assembly the bottleneck.

Who should own data quality?

The business should own data quality, with IT supporting the controls. Each data domain, such as customers, items, or vendors, needs a named business owner who approves new records, resolves duplicates, and answers for completeness. The Controller owns reconciliation of reports to the ledger, and the CFO approves metric definitions.

How often should reports be reconciled to the general ledger?

Reconcile every period the report is published, which for most operating reports means monthly. A documented reconciliation with explained differences makes the report defensible to the board, lenders, and buyers. Reconciling only at year-end lets errors compound and makes them harder to trace.

How this works in a System of Performance

Definitions and reconciliations only stay trusted if changes and exceptions are recorded as they happen. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see where your own numbers disagree, bring it to us as a launch partner.