Sales, operations and accounting all have different numbers: fixing siloed data

Why three departments can report three different numbers

Reports disagree because each department pulls from its own system, defines the same term in its own way and refreshes its numbers on its own schedule. Sales counts an order when it is signed, operations when it ships, accounting when it is invoiced, and all three are correct by their own rules. The fix is not a better spreadsheet; it is agreeing on shared definitions and connecting the systems so every report draws from one trusted source of data.

I hear the symptom described in nearly the same words by company leaders in every industry we serve: we spend the first half of every meeting arguing about whose number is right. When that is happening, decisions wait, trust erodes and the people who build the reports spend their week reconciling instead of analyzing. The good news is that siloed data is one of the most solvable problems in a growing company.

How data silos form in a company that is doing well

Silos are usually a side effect of growth, not neglect. Each department picks the tool that solves its own problem quickly: a CRM for sales, an inventory or scheduling system for operations, an accounting package for finance, and spreadsheets to fill the gaps. Each choice is sensible. Together they produce a company where the same customer, product or job exists in four places with four slightly different spellings.

Nobody owns the connections between those tools, so people become the connection. Someone exports from one system, cleans the file by hand and pastes it into another. That person becomes indispensable, the process becomes fragile, and the numbers are out of date the moment the export finishes.

• Different systems use different identifiers for the same customer or product.
• Key terms such as revenue, active customer or on-time delivery have no written definition.
• Data moves between systems by manual export and import, not by integration.
• Reports are built in spreadsheets from exports, so each one is a snapshot from a different moment.
• Old records live in Word documents and PDFs that no system can read.

What disagreeing numbers really cost

The cost of siloed data rarely shows up as a line item, which is why it is easy to tolerate. It shows up as slower decisions, staff time spent on reconciliation, and mistakes that reach customers. Add up a month of these and the case for fixing the problem usually makes itself.

There is also a strategic cost. Leaders who cannot trust their numbers fall back on instinct. That may work for a while, but it gets harder as the company adds locations, product lines or people, and it becomes a serious problem when a lender, investor or buyer asks for figures that hold up under scrutiny.

• Hours each week spent exporting, cleaning and pasting data between tools.
• Meetings that debate the number instead of the decision.
• Orders, invoices or shipments that fall through the gap between two systems.
• Customers who hear different answers from different departments.
• Forecasts built on figures that were stale before they were finished.

Trace one number from start to finish this week

You can diagnose most of the problem yourself in an afternoon. Pick the single number that causes the most argument in your leadership meetings, for example monthly revenue, open orders or on-time delivery. Then ask each department to show you, step by step, where their version comes from: which system, which filter, which date field and who touches it before it reaches the report.

Write the answers side by side. In my experience the differences fall into three groups: definitions that were never agreed, data that is entered twice and drifts apart, and timing gaps between when systems are updated. Each group has a different fix, and knowing which one you have is most of the battle. Some differences can be closed with a written definition and a meeting; others need the systems themselves to be connected.

Keep this exercise. The document you produce is exactly what a data team needs to start work, and it often shortens the discovery phase of a project considerably.

When a better spreadsheet is no longer enough

If the problem is mainly definitions, a well-run meeting and a shared glossary can solve a surprising amount. If only a handful of people produce reports and the volume is small, a carefully built and documented spreadsheet may carry you for a while longer. My guide on replacing the spreadsheet that runs your company helps you judge where that line sits for your business.

Once several systems feed the same report, data is re-entered by hand, or decisions depend on numbers that are more than a day old, the problem has outgrown manual fixes. That is the point to bring in people whose job is data engineering. Waiting longer rarely makes the eventual project smaller; it just adds more history to migrate and more workarounds to unwind.

What one source of truth actually involves

A single source of truth is not one giant system that replaces everything. In most companies it is a layer that sits beside the existing tools. Data flows automatically from each system into a central store, where it is cleaned, matched and organized according to definitions the business has agreed. Reports and dashboards then read from that one place, so everyone sees the same number at the same moment.

At Aezion our data engineering practice covers each piece of this: data strategy, modernizing the data stack, cloud data management, data visualization, and data science and machine learning once the foundation is solid. We work with the major platforms in this space, including Microsoft, AWS, Google, Databricks and Snowflake, and we also build on Microsoft Fabric, which brings data pipelines and reporting together for companies already using Microsoft 365.

The work does not have to happen all at once. We usually start with the one or two numbers that cause the most argument, connect only the systems that feed them, and deliver a dashboard leaders can trust. Once that first slice is working, adding the next data source is faster, because the matching rules, definitions and pipelines are already in place. Starting small also shows quickly whether the definitions your team agreed on hold up against real data.

• A data strategy that names the decisions the data must support.
• A written glossary of shared definitions, owned by the business.
• Automated pipelines from each source system, replacing manual exports.
• Matching rules so one customer or product has one identity everywhere.
• Dashboards built for the questions leaders actually ask.

Connect the systems, consolidate them or replace one?

Not every silo needs the same treatment. Connecting systems through integrations and a central data store is usually the first and least disruptive step. Consolidating makes sense when two tools do overlapping jobs and one can absorb the other. Replacing a system is the right call when it cannot share data at all, is no longer supported, or forces workarounds that create the mismatches in the first place.

Where the data lives matters too. Many companies move their data platform to the cloud as part of this work, and that move has its own cost traps; I cover them in my guide on whether the cloud actually saves money. For small, departmental gaps, a low-code tool may be enough, and my guide on building software in-house or with low-code tools explains where that works and where it does not.

Keeping the numbers aligned after the fix

Data problems come back if nobody owns them. Every shared definition needs a business owner who decides when it changes. New tools need to be connected before they go live, not after. Access needs rules, so people see what they need and nothing more, especially where customer, health or financial information is involved.

It also helps to watch the pipelines themselves. Automated data flows can fail quietly when a source system changes a field name or a vendor updates its interface. Simple monitoring that alerts someone when a feed stops or a number swings outside its normal range catches those failures before they reach a board report. Treat the data platform like any other system the business depends on: it needs an owner, a support plan and periodic review.

That last point is more than good practice. Texas has its own rules about protecting personal information, and a central data store makes it both easier and more important to follow them. My guide on Texas privacy law and the customer data in your software covers the basics to discuss with your attorney.

What a first data conversation with us covers

Bring the number you traced and the side-by-side notes on where each version comes from. In a first conversation we will look at which systems are involved, which differences are definitions and which are integration gaps, and whether the right next step is a glossary, a set of integrations, a data platform or a system replacement. We will tell you honestly if the problem is smaller than you feared.

Integration is often where the biggest gains are. One client, an auto parts distributor, wrote in a Google review that the software we built was fully integrated into their backend and ERP systems and eliminated thousands of man-hours per year. Results depend on the starting point, but the pattern is common: once systems share data automatically, the hours spent reconciling them go back to the business. Dallas-area companies can meet us in Frisco to start.

Questions people ask me