What is a semantic layer and why dashboards need one

Finance opens a Power BI report and sees one margin, while sales opens a Metabase chart and sees another. Neither is wrong. Each builder wrote a private formula inside their own report, and the two formulas treat freight, discounts and returns differently.

Most dashboards are built straight on tables, so every chart carries its own arithmetic. Copy a chart into a new report and that arithmetic travels along, drifting a little each time someone edits a filter. It adds up.

The fault is rarely in the data. It is in the definition. Nobody wrote down what margin means across the whole company, so each report invented its own answer and defended it. The owner then loses half of every review meeting to arguing over whose slide is correct, instead of deciding what to do about a falling product line.

Treat it as a dictionary the dashboards must obey. Each entry is a measure, such as net revenue or outstanding receivables, and beside it sit the formula, the filters and the tables it joins.

It also holds the dimensions people slice by, such as customer, branch, product family and month, with the join paths fixed once. A report builder drags in a measure and a dimension and cannot get the join wrong.

Where it lives differs by tool. Power BI keeps it in the dataset model and Looker uses LookML. Metabase has models and metrics, while a warehouse view or a dbt project does the same job for any tool that lacks its own.

The trick is placement. If every definition lives in one place and every tool reads from it, the tools cannot disagree. The layer can be as plain as a set of curated database views that the BI tools query exclusively.

Raw tables are hidden from report builders. They see a view called finance_margin_monthly, not forty joined sources, and Power BI, Metabase and Looker Studio all query that same view, so the number agrees on every screen.

Change a definition once and every report follows. That is the real payoff. The month you decide to net credit notes against sales, a single edit corrects every chart, export and scheduled email that quotes revenue. Auditors and lenders asking how a figure was produced get one written answer instead of three.

A single report, built by one person on one source, needs no layer, because a well-named view is enough. Skip the ceremony. Do not build machinery for a problem you do not yet have. Add the layer when a second report, a second tool or a second builder appears, because that is the moment definitions begin to fork.

The signs you have outgrown that are plain. Two people give the owner different numbers for the same month. A new hire rebuilds a report from scratch because nobody trusts the old one, or the finance head keeps a private spreadsheet to check the dashboard.

Pick the ten numbers your management meeting argues about. Write each as one sentence, then as a formula, then as a list of exceptions, remembering that a returned item and a cancelled order are the usual troublemakers.

Have the finance head sign off each line. Then build the layer for those ten only, point one dashboard at it, and compare the results against the old figures. Explain every gap before widening the scope, and keep a note of each fix so the next hire sees why a definition changed.