# How IT Leaders Build Trust in Business Data - Published: 2026-11-09 - Author: [CIO Grid](https://ciogrid.com/author/ciogrid-com.md) - Topics: [Q&A](https://ciogrid.com/qa.md) - Source: https://ciogrid.com/qa/how-it-leaders-build-trust-in-business-data/ - Publication: CIO Grid - Publisher: Connectively (Terkel, Inc.) - Editorial policy: https://ciogrid.com/editorial-policy/ - AI use: The perspectives in this article were written by the named contributors and submitted through Connectively. Connectively's automated system selected them and used AI to write the headline, introduction, section headings, summary sections, and illustration, and to make minor edits for clarity. Articles are assembled and published automatically. Report errors to corrections@connectively.us. ### Standardize Core Definitions Rick Elmore, CEO, Simply Noted. When teams bring conflicting numbers to a meeting, the fix is rarely better dashboards. It is agreeing on definitions. Two teams can both be right if one counts an order when it is placed and the other when it ships. I pick a small set of core metrics, write down one definition and one owner for each, and make that the only version used in decisions. When numbers still disagree, we trace both back to the source together before debating what they mean. That turns an argument into a shared debugging session. I also ask every team to show the method alongside the number. Trust grows when people can see how a figure was built, and it drops fast when a number arrives with no explanation. A short written definitions page does more for data trust than another tool. --- ### Name Accountable Stewards The change that made the greatest impact was assigning a named steward to each important metric. We previously shared ownership broadly, which made accountability unclear. When a number seemed incorrect, several people could explain parts of the process, but no one was responsible for fixing the entire issue. This made it harder to resolve disagreements and maintain trust in shared data. We now assign a steward to maintain each definition, approve changes, and coordinate corrections when source data changes. This role is not about controlling access but giving teams a clear contact for questions. The steward also identifies repeated confusion and improves the related documentation. As a result, we resolve issues faster and build greater trust in shared information. --- ### Appoint Outside Challengers Most organizations treat data consistency as a technology project, then wonder why arguments survive a platform change. The deeper issue is that metrics carry incentives. A department can protect its budget or forecast by choosing the version of a number that flatters performance. We changed the review process, not just reports. Every metric received a challenger from outside the team that owned the outcome. That person tested the definition, source, and incentives before the number entered planning discussions. This created productive friction early. It also made metric owners explain causality instead of merely presenting movement. Trust grew because scrutiny became routine, rather than a personal accusation triggered by disappointing results. --- ### Show Formulas with Denominators Conflicting numbers are rarely wrong. They usually answer slightly different questions. What fixed it for us was making every number carry its formula and its denominator. We found the problem in our own files. Our reference notes for video ads quote hook rate, the share of impressions that watch at least 3 seconds, with four different healthy levels: 30% as a baseline in one note, above 10% as good in another, 20% as a benchmark with 30% as the target in a third, and 30 to 40% as the 2025 benchmark in a fourth. Hold rate was worse. One source divides 15-second views by 3-second views. Another divides full plays by impressions. A third published a scaling floor with no denominator at all. A healthy 7% on one definition cannot be compared with a healthy 15% on another. So we made two rules. No figure goes into a report without saying how it was calculated. And when sources disagree, the account's own trailing 14 days is the tie-break, with a published level used only for an account that has no history, and the level named. We also stopped letting either metric decide a scale-up. Our own notes say hook and hold show what to fix, while cost per result and return on ad spend decide the rest. --- ### Eliminate Manual Order Transcription Conflicting numbers usually start where people copy ata by hand. A Hamburg manufacturer of precision pars that my IT company supports had staff typing 30 to40 PDF orders a day into the ERP, and typos in part umbers led to wrong deliveries. We set up AI to readeach email and PDF into one table and draft the invoce, with a person checking before anything goes out.Checking now takes under a minute per order, and invices go out at once instead of after 24 to 48 hours. --- ### Unify Analytics Platforms This issue was a constant source of headaches for us, and I eventually gave up on ever finding a solid solution. Then, one fell into my lap. We were working on cutting costs specifically by reducing the number of software platforms we rely on, and that naturally meant getting rid of some of our data and analytics tools and unifying what was left into a single dashboard. I liked this because it kept our costs down and gave me fewer numbers to track, but it also did a lot to reduce miscommunication between different teams. --- ### Audit Collaborative Records Another convenient transition that helps us maintain trust in Tinkogroup's business information is working in a shared document with unified rules, rather than having team members use separate copies of the same information. We have a shared document that tells us who made what changes and when. If people see any mistakes or inconsistency, they can make the correction and notify the colleague in charge so that it doesn't happen again. I don't believe that one source of information is enough. I think we need to make it easy to trace changes back and clarify how to make them. Since everyone is working on the same document and is following the same rules, it is easier to identify discrepancies and understand where they are coming from and keep the team consistent. It creates accountability as well, without turning mistakes into a blame game. We want to have good, accurate information and ensure that the right people know about the change so that the team can have one updated version to make decisions. --- ### Publish a Business Glossary Conflict between teams and departments over metrics and definitions are a major challenge to scaling data sharing. It undermines trust in data and prevents information being used across the business. Often, this is because different departments have their own definitions for terms such as "customer", which aren't replicated across businesses. This leads to inaccurate reporting, issues between teams and a general belief that data is not useful. The only way to overcome this is through an agreed business glossary that standardizes terms and definitions to avoid confusion. Make sure the glossary is user-friendly, such as through pop-up definitions of key terms when employees are looking at data. This gets everyone on the same page, stops unnecessary debates, and delivers consistent, high quality information to all. --- ### Create a Calculation Dictionary Trust in business data improves when every team uses the same definitions, reporting periods, and source records. Conflicting numbers often come from different calculation methods, outdated spreadsheets, or inconsistent reporting dates, not necessarily inaccurate data. I recommend establishing one approved source for each critical business metric and assigning a clear owner responsible for its accuracy. If sales, finance, and operations report different revenue figures, leadership should be able to trace each number back to its original transactions and explain any differences. The practical change I would prioritize is creating a **shared metric dictionary** that defines how important figures are calculated, where the data comes from, and when it was last updated. In enterprise IT procurement, for example, purchasing might report inventory based on confirmed supplier orders, while sales counts products available for immediate delivery. Both figures can be correct, but treating them as interchangeable creates unrealistic customer commitments and purchasing decisions. I recommend starting with the five metrics that influence the most important decisions. Assign an owner to each, document its calculation, and review discrepancies during a weekly cross-functional meeting. Any correction should appear in the central reporting system so teams do not continue working from conflicting spreadsheets. The real measure of data trust is whether two departments can explain the same number using the same evidence. --- ### Run Prepublication Reconciliation Checks Data trust improves fastest when discrepancies are treated as test failures rather than political disagreements. In application security, two systems that interpret the same input differently create exploitable gaps. The business equivalent appears when a customer count, revenue figure, or service measure changes according to who exported it and when. A practical change was adding reconciliation checks before high-impact figures were published. Automated comparisons tested totals against transaction records and flagged drift. I learned not to demand agreement across every view, because timing and purpose differ. Each exception instead needed an explanation, owner, and expiry date. That made data quality a warning mechanism for integrations, processes, and incomplete records. --- ### Trigger Updates From Workflow Events Trust does not come from centralizing every dataset. It comes from establishing a reliable path from source activity to management reporting. In large distributed teams, handoffs create more inconsistency than systems do. A client status, delivery milestone, or renewal risk can be interpreted differently at each stage unless the workflow itself defines when that status changes. The most valuable adjustment I have made is connecting metric updates to workflow events rather than asking people to update reports separately. When a defined approval, completion, or escalation occurs, the related record changes through the same operational process. This reduces duplicate entry and removes the lag between reality and reporting. Consistency improves because teams are no longer being asked to remember a second administrative task after doing the work. --- ### Trace Figures Through Common Lineage I improve trust in conflicting business numbers by tracing each one to its source and calculation. A dashboard can display the discrepancy, but people making the decision need to know which system supplied a figure, the period it covers and how it was transformed. Group the same activity by event date and by deal-creation date, for instance, and two correct charts can answer different questions. We can investigate that difference more usefully than a pair of screenshots. At Ronas IT, Zoho CRM, Google Analytics and ClickUp feed a BigQuery warehouse connected to Metabase. Our marketing and sales teams use Metabase dashboards to examine leads and deals alongside analytics and operational data. We use dbt to build marts for different departments, and leadership reads the resulting charts in Metabase. People reviewing a decision now have a common analytical layer where they can inspect the inputs and transformations. The shared pipeline gives the teams a way to trace the reason two reports diverge. I'd start with a decision where teams currently bring different figures. Trace each value back to its source and document its time window, unit and calculation. Agree on the query, then publish it in the shared reporting layer. When figures diverge again, check the source records and calculation before editing the dashboard. The test is whether someone in the meeting can reproduce the figure from its source. --- ### Pin Context Beside Charts Most data fights between teams are not about bad data. They are about two correct numbers measuring different things, with nobody saying so out loud. Amazon brands live with this every day. The advertising team reports sales from the Sponsored Products campaign report, which uses a 7 day click attribution window and credits a sale to the ad that was clicked. The brand team pulls Ordered Product Sales from the Business Report (Detail Page Sales and Traffic by Child Item), which counts every order on the day it was placed, whatever the source. Finance works from the Date Range settlement report, where revenue appears when Amazon pays out, net of refunds and fees. Put those three side by side for the same week and they will never match, and each team assumes the others are wrong. The one practical change that fixes this is a written metric dictionary that sits above every dashboard. For each number you publish, it states the exact source report or SP-API endpoint, the date logic (order date, ship date or settlement date), the attribution window, and whether returns are netted out. Pin that definition next to the chart itself, so nobody has to guess where a figure came from. The second change is to stop letting each team pick its own headline number. With the brands we manage, TACOS, total ad spend divided by total sales from the Business Report, is the shared metric for profitability conversations, because it ties ad data to the full sales picture instead of only ad-attributed sales. Once the definitions are visible, the argument shifts from your number is wrong to which number answers this question. That is the conversation you actually want. --- ### Verify Filing Entities Before Imports I don't have departments arguing over numbers. I have data sources arguing, which is the same problem with less politeness. Talval pulls company financials from US and European regulatory filings plus market data feeds, and they disagree more often than you'd think. The change that helped most: a number has to prove who it belongs to before it's written, not after it's on screen. In October we found that an Italian grid operator had been carrying another utility's 2025 accounts for five months, identical to the last digit. The importer stamped every row with the company ID we had asked for, instead of the ID inside the filing itself, so our check was verifying our own question. Now identity comes from the filing's facts, and a package that names a different entity is skipped. A separate audit of the IDs we'd already stored found 4 wrong out of 288. Second, when two sources disagree there's a precedence rule, decided once and written down, not argued case by case. A secondary source may fill a gap. It may not overwrite the primary. Third, nothing gets deleted or corrected automatically on one signal. "This row matches another company's exactly" isn't enough on its own. "And this company never filed for that period" makes it safe. Consistency didn't come from a better dashboard. It came from refusing to write a number we couldn't attribute. --- ### Embed Validation Within Ingestion In my experience, conflicting numbers often start with inconsistencies in the underlying data. Different teams may be working with datasets that contain missing records, duplicates, outdated information, or different data formats. Even a well-designed data pipeline can produce unreliable results if source websites change, records are missing, duplicates appear, or data is collected incorrectly. That's why we include data validation in every pipeline we build. This includes automated checks to identify missing fields, duplicate records, unexpected changes in data volumes, and inconsistencies in formats or values. We also monitor these checks over time to catch issues before they affect downstream systems and reports. --- ### Test Values Across Integration Layers When two teams bring different numbers to a meeting, I would first ask how each number was produced. Often the disagreement is not about the calculation itself. One report may use a different time window, another may exclude failed records, or two systems may define the same field differently. Choosing one dashboard as the official answer does not fix those differences. My experience at Yahoo Finance has made me especially careful about this. I worked on quality engineering for financial features, including connected brokerage integrations and the services behind portfolio information. When information moves between an external provider, backend services and a user interface, there are several places where the meaning of a value can change. A correct response from one service does not automatically mean the final information shown to a user is correct. The practical change I advocate is to make validation traceable across those boundaries. Start with a small set of important fields and document what each one means, where it originates and how it should change along the way. Then test realistic cases at the integration and application levels. For example, an account connection may be successful while a portfolio refresh is delayed. Those are two different states and should not be treated as one success metric. It also helps to make timing explicit. A balance captured at one point in the day cannot always be compared directly with a value pulled later. This approach is closely related to the kind of cross layer validation I have done in software testing. It gives people a way to investigate discrepancies instead of arguing over whose report is right. Engineers can find the step where the data diverged, and business teams can agree on what they are measuring. I would not claim that I personally led a companywide reconciliation of executive dashboards. My direct contribution has been building and applying checks that help teams trust the data flowing through their applications. The lesson I take from that work is simple: consistent numbers begin with consistent definitions and a clear path back to the source. One useful habit is to record the exact scenario behind a mismatch, not just file a ticket saying the values disagree. Include the source response, the transformation involved and when the data was fetched. That turns a debate into something the team can reproduce and fix. --- ### Specify Headline Scope Explicitly I start by checking whether the numbers describe the same thing. Using the same data provider does not guarantee that two reports use the same scope or calculation. At Market Brew, our account-management team flagged that figures in our Search Console-backed dashboard did not match Search Console for the same period. I investigated, and we updated reporting to use property-level daily totals for headline search metrics, while keeping query and page breakdowns separate. We also addressed how domain variants were combined so overlapping properties were not double-counted. The practical change was to give the headline figures an explicit reporting basis that could be checked against the source. A detailed table and an overall total answer different questions; they should not be treated as interchangeable. My recommendation is to make every important metric answer four questions: where did it come from, what period does it cover, what does it include, and how was it calculated? Then compare reports using those same boundaries. That turns a disagreement about whose dashboard to trust into a specific calculation the team can inspect. --- ### Align Project Identifiers When I talk about the data, the first question we need to ask is, is that data correct? Can we believe that data? One example was a broken connection between the operational CRM and QuickBooks, the finances. The chart of accounts was not mapped out correctly. So pretty much the AI agent could not understand that we were talking about the same projects, because they were not mapped out, and they were not connected between those two systems. Operations had one number, finance had another. The practical change was mapping them first: the same project, the same name, in both systems, before anybody builds a report or an agent on top. If your data is wrong, AI will scale the wrong number, and that's a disaster. You need your CRM updated, your books in order. --- ### Treat Quality Controls as Code In my work, trust improves when every shared metric has one certified definition, calculated in one place, with its lineage visible. The value of reducing detection latency far outweighs the benefits of any individual detection technique. Researchers realized this years ago, and this is why Amazon, having identified that data validation traditionally occurred manually while software validation was highly automated, invested in declarative, unit-test style quality validation that could scale to billions of rows of data by calculating metrics over incrementally ingested data. A separate team at Google arrived at a similar conclusion, finding that schema validation and skew detection should be treated as pipeline features, not manual ad-hoc processes. Data quality is pipeline code, and the lessons about test-driven development and infrastructure as code apply just as strongly to data as they do to software. The failure modes which have proven most challenging to pipelines at scale fall into three broad categories, each of which has a technique particularly well suited to addressing it. Schema drift is when producers change what columns they write, or how they use existing columns, and requires explicit schema validation at the pipeline boundary to detect. When someone questions a number now, anyone in the room can trace where it came from and which definition produced it, so the discussion moves to whether the definition is right, not whose spreadsheet is. Vishnuvardhan Reddy Kaithapuram, Software Development Engineer at Amazon Advertising. --- ### Formalize Lead Acceptance Marketing and sales commonly argue over lead counts because the handoff is treated as a reporting event instead of a commitment. Marketing may count a form submission, while sales counts only a contact it accepts. Both views matter, but neither should be mislabeled as the other. One practical change I have implemented is a lead handoff agreement inside the CRM workflow. It defines fields, acceptance criteria, expectations, disposition codes, and when a record becomes sales owned. Exceptions are visible in email or notes. That structure produces better data because it improves the customer process first. It also reveals whether a count difference reflects submissions, unworked leads, rejected fits, or follow-up, each requiring a different fix. --- ### Set Success Criteria Early You improve trust in business data by agreeing on what each number means before anyone measures it. When teams use conflicting numbers, they are usually measuring different things under the same name. On one automation initiative I was part of, every team tracked the same headline metric: the percentage of decisions that were successfully automated. Each team defined it differently. One counted a decision as automated if the system produced the outcome after a person entered the data. Another counted it if the system extracted the data and recommended a decision, even when a person still had to validate it. A third counted only straight-through processing, where the system extracted the data and made the correct decision on the first pass with no human touch. All three numbers were accurate, but each told a different story, and leadership could not tell whether the project was succeeding. It is the same failure that cost NASA the Mars Climate Orbiter, when one team calculated in imperial units and another in metric. The math was right, but the definitions were not shared. The practical change that fixed this for us was a return to project management and Agile fundamentals. We agreed on definitions up front and wrote them into acceptance criteria, so "automated" meant one thing before anyone measured it. We tied each metric to a clearly stated project outcome instead of a feature, and we set a shared Definition of Done that every team signed off on. Then we added sprint reviews to validate progress against those definitions throughout the build rather than discovering the gap at final user acceptance testing. That discipline reframed the conversation. The debate shifted from whose number was right to what it would take to move the one number we had all agreed on. When teams do not trust the data, do not start with the data. Start with agreement on what success means before the work begins. --- ### Build a Unified Data Model Conflicting numbers almost never come from bad data. They come from two teams defining the same word differently. Sales counts revenue when the deal is signed, finance counts it when the invoice is paid, and both are right by their own definition. So arguing about whose spreadsheet is correct goes nowhere. The change I'd make is to agree on the definition once, write it down in plain words, and then build it into one shared data model that every report reads from. Not a document that lists the definition next to a dozen spreadsheets that each calculate it their own way, but one calculation that everybody's report uses. If someone needs a different version, it gets its own name ("booked revenue" and "paid revenue"), so nobody can confuse the two again. It sounds boring, and it is. But once there's one number with one name, the meeting can move on to what the number means. --- ### Centralize Logic Within Semantic Layer To improve trust in business data when conflicting numbers exist across teams, you must establish single source-of-truth semantic definitions and align ownership between the data producers and data consumers. Conflicting numbers almost always stem from inconsistent business logic such as different teams calculating customer churn or gross margin with their own formulas rather than underlying raw data errors. One practical change that consistently remedies this friction is introducing a centralized semantic layer where business metrics are defined once in code and governed globally, rather than written individually inside separate dashboard tools or SQL queries. By standardizing the logic for key indicators at the repository level, every department queries the exact same calculation regardless of which visualization platform or analytics tool they use. In practice, establishing clear operational data contracts between software engineering teams and analytics departments prevents upstream schema changes from silently breaking downstream metrics, ensuring that shifts in numbers reflect real business movement rather than reporting flaws. Organizations that adopt this approach reduce executive time spent debating metric definitions during strategy meetings and shift the focus entirely to performance. The main benefit of enforcing standardized definitions is the immediate elimination of reporting silos and faster decision-making confidence across executive leadership. The main risk is operational friction during implementation, as individual teams often resist abandoning their legacy reporting setups or customized metric variants. As you implement this, watch out for metric governance becoming a bureaucratic bottleneck that slows down ad-hoc analysis; the goal is to standardize core executive KPIs while maintaining a clear, lightweight process for teams to propose and iterate on new metrics. In my experience, shifting to standardized metric definitions enabled our team to align cross-functional reporting across leadership meetings and streamline multi-department alignment \[Replace with your own measurable results, team context, or organizational outcome\]. --- ### Catalog and Resolve Discrepancies I'd invest in better data collection/reporting before I'd invest in better data tools. Bad data undermines trust faster than bad data tools. One of the ways we run into bad data is that we'll see data discrepancies between different sources, and when we use one of those sources to make a statement, somebody will call us out for being inaccurate. Recently, for example, we had a really old version of a page that claimed we worked with fewer than a tenth of the 13,000+ businesses we've actually worked with. That data was accurate when it was originally collected, but wasn't updated as new data came in, and was quoted in different places on our website. Similarly, we described our turnaround time four different ways between our quotes, shipping policy, and press releases. It's rare that somebody deliberately messes things up like this. It's usually just a failure to update data as new information comes in. So how do you deal with this? For us, we created a document that lists out the data we use for statements we make about Arklavo. For each statement, we list the data point we should be using at the moment ("use now"), where we got that data point from, and highlight when there's a discrepancy between sources. The key here is not deciding what the correct answer is, but documenting where the discrepancy is. Then somebody needs to make a decision about what the correct answer is and make sure that data point is updated in all the places it's relevant, not just where somebody happened to notice it was wrong. --- ### Enforce Authoritative Baselines Hi , I would be happy to share my perspective on this. As an enterprise software consultant working with large-scale SAP systems, conflicting data across departments is one of the most common friction points I encounter when organizations scale. Here is how you tackle it and the practical change that makes the biggest difference: The Root Cause: Conflicting numbers usually happen because different teams rely on localized or disconnected data extracts rather than a centralized, standardized architecture. When sales, finance, and supply chain each maintain their own reporting logic, misalignment is inevitable. The Practical Change: The most impactful shift is moving away from ad-hoc data pulls toward an enforced, automated data pipeline backed by a single source of truth (SSOT). In our environment, this meant centralizing core data definitions directly within the enterprise resource planning (ERP) framework and standardizing master data governance so that all downstream reporting draws from the exact same validated tables and automated transformation scripts. The Result: When teams know that everyone—from operations to executive leadership—is looking at the exact same automated baseline, arguments over conflicting spreadsheets disappear, and decision-making speeds up significantly. I am happy to be named as a source (Sunil Medepalli, Senior SAP Consultant & Enterprise Developer contracting with IBM) or speak on background. Let me know if you would like to explore this further! Best regards, Sunil Medepalli ## Related - [Build Trust in Business Data Across Enterprise Teams](https://ciogrid.com/qa/build-trust-in-business-data-across-enterprise-teams.md) - [Clarify Business Data Ownership Across Teams](https://ciogrid.com/qa/clarify-business-data-ownership-across-teams.md) - [Make Dashboards Believable: Data Quality Practices for Analytics Leaders](https://ciogrid.com/qa/make-dashboards-believable-data-quality-practices-for-analytics-leaders.md) - [22 Ways to Justify Major IT Investments to Skeptical Executives](https://ciogrid.com/qa/22-ways-to-justify-major-it-investments-to-skeptical-executives.md)