What a Data Dictionary Actually Is, and Why Most BI Projects Skip It
I watched two people argue about how many customers a business had. Both were senior. Both were looking at the same Power BI report, on the same screen, in a quarterly review. One said the company had 4,200 active customers. The other said 3,600. Same report. Same source system. Same afternoon.
Neither of them was wrong. That is the part people miss.
The first person counted any account with a contract on file. The second counted any account that had bought something in the last ninety days. The report had a card labelled "Active Customers." Nobody had ever written down what "active" meant. So the report showed one number, and each person mapped it to the definition in their own head. The argument was not about data. It was about a word.
If this sounds familiar, you do not have a reporting problem. You have a missing agreement. And the thing that captures that agreement has a name nobody likes to say out loud, because it sounds boring: a data dictionary.
Here is what a data dictionary actually is. It is not documentation written after the fact. It is not a technical file that lives in the BI team's folder. It is a plain-language record of what each term in your business means, how it is calculated, where the data comes from, and who decided. "Active customer" gets one row. The row says: an account that has placed at least one order in the trailing ninety days, sourced from the orders table, owned by the Head of Sales. That is it. One line of agreement that ends a hundred future arguments.
Most people assume this already exists somewhere. It usually does not. What exists is a tangle of tribal knowledge. Finance knows how finance counts revenue. Operations knows how operations counts a completed job. Each team is internally consistent and invisible to the others. The knowledge lives in people's heads and in formulas buried inside spreadsheets that three employees understand and nobody wrote down.
So why do BI projects skip the dictionary? Because it is the least glamorous part of the work and the easiest to defer. The visual is exciting. The dictionary is a meeting. When a project is racing toward a deadline, the dictionary is the first thing cut, on the assumption that everyone already agrees. That assumption is almost never tested until the report goes live and two senior people read the same card differently.
There is also a quieter reason. Writing the dictionary forces decisions some people would rather leave fuzzy. The moment you write down a single definition of "active customer," somebody loses. The number on their spreadsheet stops being official. Ambiguity protects everyone's version. A dictionary removes that protection, which is exactly why it is valuable and exactly why it gets avoided.
I want to be clear that this is not a technical document. The worst data dictionaries are the ones the BI team writes alone. They end up precise and organisationally meaningless, because the BI team can describe how a number is calculated but cannot decide which calculation the business should trust. That decision is not theirs to make. The dictionary has to be built with the people who own the terms in the room. The developer holds the pen. The business makes the call.
What goes in it is less than people fear. For each term that matters, you record the plain definition, the calculation logic, the source system, the owner, and any known edge cases. Edge cases are where the real disagreements hide. Does a refunded order still count as a sale? Does an internal transfer count as revenue? Does a customer who churned and came back count as new or returning? You do not need a hundred terms. You need the twenty or thirty that show up on the reports people actually use to make decisions.
The payoff is not tidiness. It is that the next argument never happens. When someone questions a number, you do not relitigate the definition. You point at the row. The conversation moves from "that number looks wrong" to "do we want to change how we count this," which is a real business decision instead of a misunderstanding. You turn noise back into signal.
Every report you build before the organisation agrees on what its terms mean is built on borrowed time. The disagreement is already there, sitting quietly inside everyone's separate spreadsheets. The report does not create it. The report exposes it, usually in front of the people you least want to expose it to.
So if you are about to start a BI project, ask one question before anyone opens Power BI: do we have a written, owned definition for the terms on this report? If the answer is no, that is your first deliverable. Not the dashboard. The dictionary.
Every report built before the organisation agrees on what its terms mean will eventually produce conflicting numbers. That is not a technical failure. It is a missing agreement that surfaces at the worst possible moment: in a board meeting, in a close cycle, in an audit. One structured session produces a Data Dictionary your teams actually sign off on. If you do not have one yet, every report you build is built on borrowed time. → Build the Data Dictionary
Agree on the words first.
Every report built before the business agrees on what its terms mean is built on borrowed time. One structured session captures the definitions, the owners, and the edge cases your teams actually sign off on.
Book a 30-Minute Discovery CallFrequently asked questions
Is a data dictionary the same as data documentation?
No, and the difference matters. Documentation describes how something was built. A data dictionary records what a term means and who decided. You can have perfect documentation of a calculation the business never agreed to. The dictionary is the agreement, written in plain language, not the technical description of the code.
Who should own the data dictionary?
The business owns it. Each term has a named owner who is accountable for its definition, usually the person who runs the function that uses it. The BI team maintains the document and implements the definitions, but it does not decide them. A dictionary written and owned by the BI team alone tends to be technically correct and organisationally ignored.
How many terms does a data dictionary need?
Fewer than most people expect. You do not document every field in every table. You document the terms that appear on the reports people use to make decisions, plus the ones that have caused arguments before. For most organisations that is twenty to forty terms. The edge cases inside those terms are where the real work is.
We already have reports. Is it too late to write one?
No. It is often the best time, because you now have concrete examples of where definitions collide. Pull the terms off your existing reports, find the ones where two teams would answer differently, and start there. Writing the dictionary after the fact is harder than doing it first, but it is far cheaper than living with conflicting numbers indefinitely.