How to Build a Business Glossary Your Data Team Will Actually Use

Pull up any dashboard in your company and find the number labeled "Revenue." Now ask three people what it means. Finance says ARR — annual recognized revenue, net of refunds, in USD. Sales says bookings — signed contracts, whether or not the customer has paid. Product says MRR from active subscriptions, excluding trials and one-time charges.

All three are reasonable. All three produce different numbers. And every dashboard that says "Revenue" without specifying which one is wrong for at least two of those people.

This is the problem a business glossary solves. Not by picking a winner, but by forcing you to write down that these are three different things with three different names, three different calculations, and three different source tables. Once you do that, the arguments stop — or at least they become arguments about which definition to use, not about whether someone's number is broken.

What a glossary actually is (and isn't)

A business glossary is a structured list of terms your organization uses, each mapped to an exact definition. Not a paragraph of prose — a specification. Each entry should contain:

Term name and aliases. "MRR" and "Monthly Recurring Revenue" need to resolve to the same entry. So does "monthly rev" when someone types it into a search bar or asks an AI agent.

A plain-English definition. One sentence a new hire can read. "The sum of monthly subscription amounts from active, paying accounts, excluding trials and one-time charges." No jargon that itself needs a glossary entry to decode.

The calculation logic. Not hand-wavy — exact. Which table, which column, which filters, which grain. If two analysts can read your definition and produce different SQL, it's underspecified.

An owner. A human name, not a team. When the definition needs to change — and it will — someone specific makes the call. Unowned definitions rot fastest.

Related tables and columns. The bridge between the business term and the physical data. "MRR" maps to stripe.subscriptions.amount where status = 'active'. Without this mapping, the glossary is a wiki page. With it, it's a contract between the business and the warehouse.

This is different from a data dictionary, which documents tables and columns. A glossary sits above that: it maps business concepts to the physical schema. The dictionary tells you what stripe.subscriptions.plan_amount is. The glossary tells you that when someone says "MRR," that's the column they mean — with filters applied.

Three definitions worth getting right

Abstract advice is easy. Here are three terms that cause real fights, and what a proper glossary entry looks like for each.

MRR (Monthly Recurring Revenue). Sum of subscriptions.amount for subscriptions where status = 'active' and plan.trial = false. Currency: USD, converted at charge-time FX rate. Excludes one-time charges, usage overages, and accounts in a grace period. Owner: Head of Finance. This is the number that goes in the board deck — not bookings, not billings, not the Stripe dashboard's default "gross volume" number that includes refunded charges.

Customer Count. Count of distinct organizations (not users) where subscription.status IN ('active', 'past_due') and plan.type != 'free'. A company with 40 seats is one customer. An individual on a free plan is zero customers. This matters because if you count users, your "customer count" will be 10x your actual paying account count, and your ARPU will look terrible for no reason.

Churn Rate. Count of organizations whose subscription moved to canceled during the period, divided by the count of active organizations at the start of the period. Exclude pauses (which are reversible) and plan downgrades (which are contraction, not churn). Monthly grain. This is logo churn — distinct from revenue churn, which weights by dollar amount. Both are useful; they answer different questions. Your glossary should have separate entries for each.

Notice the pattern: the definition isn't just what the term means in English. It's the exact filter clause, the exact grain, the exact exclusions. That's what makes it useful. Anyone — human or AI agent — can read the entry and produce the right query.

Why Confluence pages fail and integrated glossaries don't

Most teams' first attempt at a glossary is a wiki page. Someone creates a Confluence doc titled "Metric Definitions," writes up ten terms, shares it in Slack, and feels good about it. Two weeks later it's stale. A month later nobody remembers it exists. Three months later a new analyst writes a query that contradicts the doc, and nobody notices because nobody reads the doc.

This happens because a wiki glossary has no connection to the data it describes. It's a static document that lives in one tab while the analyst works in another. When a column gets renamed, the glossary doesn't know. When someone builds a dashboard using the wrong definition of churn, the glossary doesn't flag it. It's a best-effort reference, and best-effort loses to inertia every time.

An integrated glossary — one that lives alongside your data catalog and semantic layer — is different in a specific, practical way: the term-to-column mapping isn't just documentation, it's a link. When the definition says MRR comes from stripe.subscriptions.amount WHERE status = 'active', that's not prose — it's a pointer to an actual column in an actual table. Which means when someone asks "where does this dashboard number come from?", you can trace it: dashboard widget references the "MRR" metric, the metric's glossary entry points to stripe.subscriptions.amount, and the catalog shows you that column's type, freshness, and lineage. The full chain, from business question to physical data.

That traceability is the difference between "I think this number is right" and "I can show you exactly how this number is calculated."

Building the glossary in practice

Start small. Catalog the terms that cause confusion — the ones where you've seen two people argue or two dashboards disagree. That's usually 15-20 terms, not 200. If you try to define every possible business term upfront, you'll burn a quarter and still won't cover the one term that actually causes a crisis in the next board meeting.

For each term, write the five fields: name (plus aliases), plain-English definition, calculation logic with specific columns and filters, owner, and related tables. Validate the logic by having two people independently write the query from the definition. If they get different SQL, the definition is ambiguous — tighten it.

Then connect the terms to your data. In Fastero, the glossary is part of the data catalog — you define a term, link it to the columns and metrics it references, and the connection is live. When an analyst searches for "churn" in the catalog, they get the glossary entry and the linked columns. When an AI agent gets asked "what's our churn rate?", it reads the glossary definition before writing SQL, so it uses logo churn with the right exclusions instead of improvising its own version. (This is the same principle behind defining metrics as a single source of truth — the glossary is the human-readable layer on top of the metric definitions.)

Glossary as governance

The real payoff comes when the glossary isn't just documentation but a governance mechanism. When a definition changes — Finance decides to start including usage overages in MRR, say — the change propagates. Every metric that references the "MRR" glossary term is now flagged for review. Every dashboard built on that metric shows that the underlying definition was updated. Instead of a silent change that makes last month's numbers incomparable to this month's, you get an audit trail: who changed the definition, when, and which downstream reports are affected.

This is where the integrated glossary diverges most sharply from the wiki page. A Confluence doc can't tell you which dashboards break when you update a definition, because it doesn't know the dashboards exist. A glossary wired into the semantic layer and catalog can, because the links are structural, not just textual. Impact analysis becomes trivial — change the definition, see the blast radius, update the downstream consumers. (We covered the drift-detection side of this in the semantic layer tools comparison.)

You don't need enterprise data governance tooling to get this. You need term definitions, column mappings, and a system that keeps them connected. That's the bar.

The operational test

Here's how you know your glossary is working: a new analyst joins, gets asked to build a retention dashboard, and never has to ask in Slack what "active customer" means. They search the catalog, find the glossary entry, see the linked columns, and write the query. The number matches what everyone else reports. No tribal knowledge required.

And here's how you know it's not working: someone renamed a column in Salesforce three weeks ago, the glossary still references the old name, and nobody noticed until the board deck had a blank cell where a number should be. If your glossary can go stale without anyone knowing, it's a wiki page wearing a fancier hat.

The fix isn't more process. It's structural connection between the terms and the data, so when one changes, the other reacts. That's what turns a glossary from a document into infrastructure.

---

Try Fastero free — define your business terms, link them to your data, and stop arguing about what "revenue" means. No credit card required.