--- title: "BI Reporting: How To Build Reports People Trust" description: "What BI reporting covers, the main types of business intelligence reports, why figures disagree, and how a semantic layer gives one trusted number." canonical: https://shipshapedata.com/resources/business-intelligence/bi-reporting/ language: en-GB author: "Emile Van Zyl" author_role: "MarTech Automation Consultant" author_url: https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/ date_published: 2026-11-04 date_modified: 2026-11-04 --- # BI reporting: building reports people actually trust > What BI reporting covers, the main types of business intelligence reports, why figures disagree, and how a semantic layer gives one trusted number. Section: Home > Resources > Business intelligence Canonical page: https://shipshapedata.com/resources/business-intelligence/bi-reporting/ By Emile Van Zyl, MarTech Automation Consultant (https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/) | published 2026-11-04 The monthly performance meeting starts with a question about the numbers, and an hour later nobody has discussed the business. Finance has one revenue figure, sales has another, and operations has a spreadsheet that agrees with neither. Each team built its report correctly from its own data. The problem is not the charts. It is that nobody agreed what the number means. BI reporting is the practice of turning data from your business systems into scheduled and interactive reports that show what happened and what is happening now. A good BI report draws on governed data, uses one agreed definition of each metric, and gives the reader a figure they can act on without first checking where it came from. This guide is for the people who own reporting in an organisation: heads of data, finance and operations leads, and the analysts who build the reports. It explains what BI reporting covers, the main types of business intelligence reports, why reports disagree, and how a semantic layer ends the argument about whose number is right. It finishes with how trusted reporting becomes the base for forecasting. ## What BI reporting is Business intelligence covers the whole chain that turns raw activity into numbers people use: the pipelines that collect data, the warehouse that stores it, the model that organises it and the tools that present it. Reporting is the last step of that chain, and the one everyone sees. Our guide to how the business intelligence stack fits together covers the earlier layers in more detail. A BI report answers a defined question for a defined audience. It might show weekly sales by region, open support tickets by age, or margin by product line. It draws on data from more than one system, applies agreed rules to it, and presents the result as tables, charts or both. It can arrive on a schedule by email, sit in a portal, or be built on demand by the person who needs it. A BI reporting tool is the software that does the presenting. Power BI, Tableau and similar platforms connect to data sources, hold a model of the data and render reports. The tool matters less than people expect. Two teams using the same tool will still produce different numbers if they define the metric differently. ### Reports, dashboards and analytics The terms overlap, and it helps to separate them. A report is a structured view of data, often detailed and often exported, built to answer a known question for a set period. A dashboard is a compact visual summary of a small number of key performance indicators, usually interactive and refreshed often, built for monitoring at a glance. Analytics goes further than both. It asks why something happened and what is likely to happen next, using statistical methods and exploration rather than a fixed layout. Plain reporting and BI reporting differ in scope. Plain reporting pulls figures out of one system, such as a list of invoices from the finance package. BI reporting combines several systems into one consistent view, so a single report can relate invoices to orders, stock and support activity. That combination is where the value sits, and it is also where the disagreements start. ### Where Excel fits Excel can do much of the work of a BI tool. It connects to data, pivots it, charts it and can hold a small data model. Many organisations run their reporting on it. The weakness is not capability but control. Each workbook carries its own copy of the data and its own version of the logic, so the definition of a metric lives in a formula someone wrote, in a file someone saved. Excel works well as a place to explore governed data. It works badly as the place where the definitions themselves live. ## Types of business intelligence reports Business intelligence reports fall into a small number of types. Most organisations need several of them, and each type makes different demands on the data underneath. - Operational reports. Daily or intraday views of current activity, such as orders shipped, tickets open or jobs completed. They need fresh data and simple, stable definitions. - Management and KPI reports. Weekly or monthly views of performance against target for leadership teams. They need consistent definitions above all, because they are compared period on period. - Financial reports. Revenue, cost, margin and cash, often reconciled to the ledger. They need to match the finance system exactly, or finance will not accept them. - Ad hoc reports. One-off answers to a new question, built by an analyst or a business user. They need well-modelled data that a non-specialist can query safely. - Analytical reports. Deeper views that segment, compare and look for causes. They need detailed history and enough context to explain a change, not just show it. - Regulatory and compliance reports. Fixed-format returns for a regulator or auditor. They need a documented calculation and a traceable route from source to figure. ### Managed and self-service delivery Reports also differ by who builds them. Managed reports are prepared by a central data team, checked and published for others to read. Self-service reports are built by business users from data the central team has prepared. Both are valid. Self-service only works when the prepared data carries the agreed definitions with it, which is the subject of our guide to self-service business intelligence and how to govern it. Many reports are also delivered on a schedule, sent by email or published to a portal at a fixed time. Scheduling is a delivery choice rather than a type. It does raise the stakes on definitions, because a scheduled report reaches many readers at once, and any error reaches all of them. ## Why two reports show different numbers Most BI reporting problems are not chart problems. They are arguments about whose number is right. A sales director and a finance director can both bring a revenue figure to the same meeting, both built carefully, and both correct by their own rules. The time goes on reconciling the figures rather than on the decision. The causes usually come from a short list. - Different definitions. One team counts revenue when an order is placed, another when it is invoiced, a third when cash arrives. Each is a reasonable rule. Without one agreed rule, each report is right and they still disagree. - Different sources. One report reads from the CRM, another from the ERP. The systems hold overlapping records that were never matched, so totals drift apart. - Different timing. One report refreshed at midnight, another at noon. Orders placed in between appear in one and not the other. - Different filters. One report excludes internal accounts or cancelled orders, another does not, and neither says so on the page. - Logic in the wrong place. The calculation sits inside a single report or spreadsheet, so when someone changes it, only that copy changes. - Quality problems in the data. Duplicate records, missing values and broken joins inflate or reduce totals in ways nobody notices until two figures are compared. > A report is only trusted when two people can build it separately and get the same number. Each of these can be fixed one report at a time, and many teams try. The fix rarely lasts, because the next report is built the same way. Comparing the systems themselves, as described in our guide to why systems disagree and how to reconcile them, deals with the source problem. The definition problem needs a different answer. ## One definition per metric: the semantic layer A semantic layer is one governed definition of your business. It sits between the warehouse and the reporting tools and holds the agreed meaning of each metric and each business term: what counts as revenue, what an active customer is, how margin is calculated, and which date decides the month a sale belongs to. Every report and every tool reads the metric from that layer instead of calculating it separately. The effect on the monthly meeting is direct. When finance and sales both pull revenue from the same governed definition, they get the same number. If they need different views, such as booked revenue and invoiced revenue, those become two named metrics with two clear definitions, not one word with two meanings. The meeting moves on to what the number says. ### What sits underneath it A semantic layer is only as reliable as the data it reads. We build it as the top of a staged foundation. Data lands in a cloud data warehouse in its raw form, the bronze layer. It is cleaned, de-duplicated and matched across systems in the silver layer. It is shaped into business-ready tables in the gold layer, usually as a dimensional model. Our comparison of star and snowflake schemas for dimensional models explains the choices at that stage, and the wider design is covered in our guide to business intelligence architecture. This works on the main warehouse platforms, including Snowflake, Databricks, Google BigQuery and Microsoft Fabric, with dbt commonly used to build and test the transformations. The platform is a fit decision. The order of building is what matters: clean data first, agreed definitions second, reports third. ### Ownership keeps it true A definition without an owner drifts. Each metric in the semantic layer needs a named owner in the business, a written definition that a non-specialist can read, and a change process so that a new rule is agreed before it is applied. A data dictionary records those definitions in one place. When a regulator or auditor asks how a figure was calculated, the answer is a single documented rule rather than a set of conflicting explanations. ## Designing reports people act on A trusted number is necessary but not sufficient. A report also has to be read and used. Most reports that go unread fail because they were built around the data available rather than the decision the reader needs to make. ### How to make a BI report - Start with the decision. Write down who will read the report, what they will decide from it and how often. A report without a decision behind it becomes a monthly export nobody opens. - Choose a small number of measures. Pick the metrics that bear on that decision and take them from the semantic layer. If a metric does not yet have an agreed definition, agree it before building. - Check the data. Confirm the sources, the refresh schedule and the known gaps. State them on the report so readers know what they are looking at. - Design for the reader. Put the most important figure first, compare it with target or the previous period, and use the simplest chart that shows the point. - Test with the people who will use it. Ask them to answer their real question from the draft, and change what confuses them. - Publish and maintain. Assign an owner, set the refresh, and review usage after a few cycles. Retire reports that nobody uses. ### Signs a report will be used Reports that get used share some features. Each figure has context, such as a target, a trend or a comparison, so the reader can tell whether it is good or bad. Definitions are one click away. The report states when the data was last refreshed. It shows enough detail to explain an exception without becoming a data dump. It also has a person behind it who will answer questions and fix problems. > Build the report around the decision, not around the data that happens to be available. ## From reporting to forecasting Reporting describes what happened. Forecasting estimates what will happen next. The two are often treated as separate programmes, but a forecast is built from the same history the reports show. If that history is inconsistent, the forecast will be inconsistent too, and it will present the error with confidence. The work done to make reporting trusted is the same work a forecast needs. Clean, matched history from the silver and gold layers gives a model reliable inputs. Governed metric definitions mean the forecast predicts the same revenue figure the board already reviews, so the two can be compared without translation. Lineage from source to figure means an unexpected forecast can be traced to its cause. A sensible sequence is to get one area of reporting trusted, such as sales or stock, then add a forecast to that same area. Our guides to demand forecasting and predictive analytics explain the methods. The first win, a report that ends the argument about the number, pays for the second: a forecast people believe because it starts from that number. ### When to wait Some organisations want to start with forecasting because it is the more visible goal. We advise against it when the reports still disagree. A forecast built on data the business does not trust will not be used, however good the model is. In that situation the honest first step is the foundation, and we will say so. ## Where this leaves you If your reporting meetings spend their time reconciling figures, a new BI tool or a redesigned dashboard will not fix it. The cause sits underneath the reports: different sources, different timing and, above all, different definitions of the same metric. The fix is a clean, staged data foundation with a semantic layer that holds one governed definition of each metric, owned by a named person. Start with the reports that cause the most argument. Agree their definitions, build them on governed data, and design them around the decisions people need to make. Once one area is trusted, the same foundation supports forecasting in that area, and then in the next. Our visualise and predict service builds dashboards, reporting and forecasting on one version of the truth, and the data foundation provides the warehouse, medallion architecture and semantic layer underneath it. We scope honestly, start with the reports that matter most to your decisions, and stay past go-live. If your figures do not yet agree, Talk to us and we will tell you where we would start, or say plainly if we are not the right fit. ## Frequently asked questions BI reporting is the practice of turning data from your business systems into scheduled and interactive reports that show what happened and what is happening now. It combines data from several systems, applies agreed rules to it and presents the result as tables and charts. A good BI report uses one governed definition of each metric, so readers can act on the figure without first checking where it came from. A BI reporting tool is the software that connects to your data, holds a model of it and presents it as reports and dashboards. Power BI and Tableau are common examples. The tool handles presentation, sharing and refresh schedules. It does not decide what a metric means. Two teams using the same tool will still produce different numbers unless the metric definitions are agreed and held in one governed place, such as a semantic layer. Excel can do much of the work of a BI tool: it connects to data, pivots it, charts it and can hold a small data model. Its weakness is control rather than capability. Each workbook holds its own copy of the data and its own version of the logic, so definitions drift between files. Excel works well for exploring governed data, but it is a poor place to keep the definitions of your metrics. Start with the decision the report supports: who reads it, what they decide and how often. Choose a small number of measures and take them from agreed, governed definitions. Check the sources, refresh schedule and known gaps, and state them on the report. Put the most important figure first with a target or comparison, test the draft with real users, then assign an owner and retire the report if nobody uses it. Plain reporting usually pulls figures out of a single system, such as a list of invoices from a finance package. BI reporting combines several systems into one consistent view, so one report can relate invoices to orders, stock and support activity. That combination is what makes BI reporting useful, and it is also why agreed definitions matter, because each system may count the same thing in a different way. Reporting presents structured views of data to answer known questions for a set period. BI is the wider chain that makes those reports possible: pipelines, warehouse, data model and tools, often including dashboards that summarise key indicators at a glance. Analytics goes further, asking why something happened and what is likely to happen next. All three depend on the same governed data, and forecasting works best when it starts from reporting the business already trusts. ## Frequently asked questions ### What is BI reporting? BI reporting is the practice of turning data from your business systems into scheduled and interactive reports that show what happened and what is happening now. It combines data from several systems, applies agreed rules to it and presents the result as tables and charts. A good BI report uses one governed definition of each metric, so readers can act on the figure without first checking where it came from. ### What is a BI reporting tool? A BI reporting tool is the software that connects to your data, holds a model of it and presents it as reports and dashboards. Power BI and Tableau are common examples. The tool handles presentation, sharing and refresh schedules. It does not decide what a metric means. Two teams using the same tool will still produce different numbers unless the metric definitions are agreed and held in one governed place, such as a semantic layer. ### Is Excel a BI tool? Excel can do much of the work of a BI tool: it connects to data, pivots it, charts it and can hold a small data model. Its weakness is control rather than capability. Each workbook holds its own copy of the data and its own version of the logic, so definitions drift between files. Excel works well for exploring governed data, but it is a poor place to keep the definitions of your metrics. ### How to make a BI report? Start with the decision the report supports: who reads it, what they decide and how often. Choose a small number of measures and take them from agreed, governed definitions. Check the sources, refresh schedule and known gaps, and state them on the report. Put the most important figure first with a target or comparison, test the draft with real users, then assign an owner and retire the report if nobody uses it. ### What is the difference between BI and reporting? Plain reporting usually pulls figures out of a single system, such as a list of invoices from a finance package. BI reporting combines several systems into one consistent view, so one report can relate invoices to orders, stock and support activity. That combination is what makes BI reporting useful, and it is also why agreed definitions matter, because each system may count the same thing in a different way. ### What is the difference between reporting, BI and analytics? Reporting presents structured views of data to answer known questions for a set period. BI is the wider chain that makes those reports possible: pipelines, warehouse, data model and tools, often including dashboards that summarise key indicators at a glance. Analytics goes further, asking why something happened and what is likely to happen next. All three depend on the same governed data, and forecasting works best when it starts from reporting the business already trusts. --- Shipshape Data is a London AI consultancy: we build the data foundation your AI depends on, then the AI on top. Site guide for agents: https://shipshapedata.com/llms.txt | Contact: hello@shipshapedata.com