Semantic layer: keep KPI definitions consistent across tools

The same question can hide different calculations

Ask finance and sales for last month's revenue. One team may use posted invoices net of credit notes; the other may use signed orders. A dashboard can display either number accurately while creating a misleading comparison.

A semantic layer addresses this problem by connecting business language to defined data relationships and calculations. It can be implemented in a reporting platform or a separate data system. Calling something a semantic layer does not, by itself, make it independent of the vendor.

For a company using Power BI alongside AI and operational dashboards, the useful question is concrete: can the team explain and reproduce each important KPI across those consumers?

Write a definition someone else can implement

Start with one metric such as net invoiced revenue. Record the business owner, source fields, date basis, included statuses and currency rules. Specify the level of detail and which filters may change the result.

A useful definition should answer:

• Does the calculation include or exclude VAT?
• Are credit notes negative rows or handled through another relationship?
• Which date assigns a row to a month?
• How are cancellations and missing values treated?
• Which entities and currencies may be combined?
• What should happen when there are no matching rows?

Put the business definition beside implementation details, not only inside a chart description. Microsoft documents how Power BI measures respond to report context. When rebuilding a calculation elsewhere, test that context instead of translating the formula by appearance.

Use examples that expose disagreements

Consider a hypothetical test dataset with a EUR 1,000 invoice excluding VAT and a EUR 200 credit note, both posted in September. Under a net-invoiced-revenue definition, the expected September total is EUR 800. An October order does not belong in that total merely because it was entered in September.

Add tests for an empty month, a division filter and a credit note posted after the original invoice. Agree the expected result for each before changing tools. A grand total that matches can still hide incorrect monthly allocation or duplicated rows.

These examples form a small acceptance pack. They do not need a new enterprise platform. A reviewed definition and a controlled dataset are enough to begin making an undocumented calculation transferable.

Separate source portability from calculation portability

A shared source feed reduces duplicated extraction work. It does not ensure that every consumer interprets the source identically. Power BI may contain DAX measures and relationships that differ from calculations in another dashboard.

DigiData's AI agent and dashboards can use approved measurements within DigiData. Its OData feed supplies supported source tables for external reporting. Do not assume every saved measurement is automatically exposed through OData or converted into a Power BI measure. Check the actual route and validate the result in each consumer.

Nor does this remove AI error. A correct result can still receive an inaccurate explanation. Ask for the period, filters and calculation used, and review unsupported explanations separately from the number.

Assign responsibility when definitions change

Give each KPI an owner who can approve changes. Record the reason, effective date and reports affected. If finance changes how credit notes are allocated, the downstream report owners need to know before comparing new figures with last month's management pack.

Run the acceptance pack after changing relationships, source mappings or calculation logic. Include ordinary-user access checks: a correct total is still wrong for a reader who is not authorised to see it.

Start with the few KPIs used in real decisions. Once those are documented and tested, extend the approach to the next report. Use the vendor lock-in checklist to examine whether data, definitions and operating knowledge can actually move when required.