Why Manufacturing Reports Disagree: How to Create One Trusted Version of the Truth

Manufacturing reports commonly disagree because departments use different source systems, reporting dates, calculations, KPI definitions or manually maintained spreadsheets.

For example, sales may report an order when it is entered, finance may recognise it when it is invoiced and operations may count it only after production has been scheduled.

All three reports may therefore be technically accurate while answering different questions.

The most common causes include:

• Disconnected business systems
• Different definitions of the same KPI
• Manual spreadsheet manipulation
• Reports refreshed at different times
• Duplicate or incomplete records
• Unclear ownership of data and calculations
• Different rules for exclusions, adjustments and exceptions
• Departmental reports created without a shared reporting model

Creating one trusted version of the truth requires more than installing a dashboard. It requires agreement about where information comes from, what each measure means, how it is validated and who is responsible for maintaining it.

What does “one version of the truth” mean?

A single version of the truth does not mean every employee must use exactly the same report.

Finance, production, sales and purchasing all need different views of the business.

It means those views are built from governed, consistent information and shared business definitions. For example, different dashboards may display:

• Sales performance by customer
• Production output by work centre
• Gross margin by product
• Inventory value by location
• On-time delivery by customer or product group

The dashboards can look different and support different decisions, but the underlying rules should be consistent.

A trusted reporting environment answers five questions clearly:

1. Source:          Where did the data originate?

2. Definition:   What does the measure mean?

3. Timing:           When was the information last updated?

4. Ownership:  Who is responsible for its accuracy?

5. Application:  What decision should the report support?

Microsoft describes enterprise and semantic models as governed, reusable layers that consolidate information and encode shared business rules. These models can provide authoritative data for multiple reports while maintaining consistent calculations and definitions.

That is an important distinction.

A single version of the truth is not one enormous spreadsheet or dashboard. It is a controlled reporting foundation that allows different users to analyse trusted information appropriately.

2. The same KPI has several definitions

Many reporting disagreements are not data errors, they are definition errors. Consider on-time delivery.

One department may calculate it against:

• The date originally requested by the customer
• The date confirmed by the business
• The latest revised delivery date
• The date goods left the warehouse
• The date goods arrived with the customer

Each definition produces a different result. The same problem can affect:

• Revenue
• Gross margin
• Order intake
• Production efficiency
• Schedule adherence
• Inventory accuracy
• Customer profitability
• Lead time
• Forecast accuracy
• Work in progress

Before building dashboards, leadership teams should agree what the organisation is trying to measure and why.

A useful KPI definition should document:

• Its business purpose
• Its calculation
• Included and excluded transactions
• The reporting period
• The authoritative data source
• The owner responsible for approving changes

Without this discipline, adding more dashboards can create more disagreement rather than greater clarity.

3. Reports are refreshed at different times

Timing can explain why two otherwise accurate reports do not match. A production report refreshed at 8:00am may not include transactions entered later that morning. Finance may report only posted transactions, while an operational dashboard includes unposted activity.

Similarly:

• Sales may use today’s exchange rate
• Finance may use the rate applied when the transaction was posted
• Inventory reports may include allocations made since the last warehouse update
• Purchasing may use the latest material plan while production retains an earlier schedule

Every important report should make its timing clear. Users should know:

• When the data was refreshed
• Whether it is live, near-real-time or batch-updated
• Whether figures include unposted transactions
• Which reporting period and cut-off rules apply

“Real-time” should not be used as a vague promise. The necessary reporting frequency should be based on the decision being made. A production exception dashboard may need frequent updates. A monthly profitability analysis may not.

4. Spreadsheets introduce uncontrolled changes

Spreadsheets remain useful tools for analysis, modelling and one-off calculations. Problems arise when they become an unofficial reporting layer between operational systems and leadership decisions.

Typical risks include:

• Formulas being changed without review
• Rows being excluded manually
• Copies circulating by email
• Data being refreshed inconsistently
• Employees maintaining separate versions
• Adjustments being made without an audit trail
• Departing employees taking essential knowledge with them

Our article 10 Signs your business has outgrown spreadsheets explores this issue in greater detail.

The goal should not be to ban spreadsheets. It should be to identify where they are performing a role better suited to a controlled ERP, data or business-intelligence process.

5. Data quality problems begin at the point of entry

Reporting teams are often expected to correct problems created much earlier in the process.

Examples include:

• Duplicate customer or supplier records
• Inconsistent product descriptions
• Missing classifications
• Incorrect units of measure
• Unclosed production jobs
• Transactions posted to the wrong period
• Incomplete routing or bill-of-material data
• Inconsistent reason codes
• Free-text fields used instead of controlled values

A dashboard can present this information more attractively, but it cannot make unreliable source data trustworthy. Improving reporting accuracy often requires changes to:

• Data-entry controls
• Validation rules
• Master-data ownership
• Process discipline
• User training
• Exception handling
• Periodic data-quality reviews

This is why reporting improvement is a business-process initiative, not simply a visualisation project.

6. Reports are created independently

Self-service reporting can be valuable. It enables knowledgeable employees to explore information without waiting for every new question to become an IT development request.

However, unmanaged self-service reporting can create:

• Duplicate reports
• Conflicting calculations
• Unclear ownership
• Unverified data sources
• Different security rules
• Multiple versions of the same KPI

The answer is not necessarily to centralise every report. A more practical model combines:

• Governed core data and semantic models
• Certified organisation-wide reports
• Controlled departmental analysis
• Clear development and approval standards
• Defined ownership and support

Microsoft’s governance guidance recommends making decisions about content ownership, certified data, permitted data sources, workspace management and the circumstances in which manually maintained files may be used. This provides central confidence without preventing useful departmental analysis.

7. Nobody owns the complete reporting process

Reporting responsibilities are often fragmented.

IT manages data connections. Finance checks financial totals. Operations defines production measures. A Power BI developer builds dashboards. Managers request changes.

But nobody owns the reporting environment from source transaction to management decision. A strong operating model normally includes clear responsibility for:

• Source-system data
• Master data
• KPI definitions
• Data models
• Report development
• Security and access
• Testing and approval
• User training
• Change management
• Ongoing monitoring

Ownership does not need to sit with one person. It does need to be visible and coordinated.

The clearest cost is the time spent reconciling information. But the wider commercial impact can be greater.

Slower decisions – Leadership teams delay action while figures are checked. An important production, purchasing or pricing decision may be postponed because nobody is confident enough to proceed.

Excess inventory – When teams do not trust demand, stock or scheduling information, they often protect themselves by holding additional inventory. That may reduce short-term anxiety while increasing working-capital requirements and obsolescence risk.

Reactive purchasing – Delayed or incomplete information can lead to urgent buying, expedited delivery costs and reduced negotiating power.

Weak forecasting – Forecasts become less valuable when teams spend more time debating historical data than considering future scenarios.

Reduced accountability – It is difficult to hold teams accountable when every department uses a different definition of success.

Poor customer communication – Customer-service teams may be unable to provide confident delivery information if order, production and stock data are inconsistent.

Management fatigue – Repeatedly checking, explaining and rebuilding reports consumes leadership attention that could be used for improvement and growth.

Reduced trust – Once employees lose confidence in reports, they may begin maintaining personal spreadsheets or informal data sets. That creates another layer of fragmentation, making the original problem worse.

The Blue Sky ERP Reporting Confidence Framework

Blue Sky ERP’s Reporting Confidence Framework provides a practical way to evaluate and improve reporting across five connected stages:

1. Capture

2. Connect

3. Validate

4. Visualise

5. Act

Stage 1: Capture

Is the right information being recorded correctly?

Reporting quality begins where data is created. This may be when:

• A customer order is entered
• A purchase receipt is processed
• Material is issued to a job
• Production is completed
• An invoice is posted
• A quality exception is recorded
• A delivery date is changed

Leadership questions include:

• Are required fields completed consistently?
• Are validation rules appropriate?
• Are employees recording events at the right time?
• Are master-data standards clear?
• Are reason codes and categories controlled?
• Which manual adjustments occur outside the ERP system?

The output of this stage should be a clear understanding of where important data originates and which process controls protect its quality.

Stage 2: Connect

Can information move reliably between systems?

Manufacturing businesses often need several specialist applications. The objective is not necessarily to force everything into one platform. It is to ensure that information moves between platforms predictably, securely and with clear ownership.

Review:

• Which systems exchange data
• Whether interfaces are automatic or manual
• How frequently information is updated
• Which application owns each record
• How errors are identified and resolved
• Whether integrations are documented
• What happens if an interface fails

Blue Sky ERP’s existing guide to Power BI and ERP integration explains how connected ERP information can support more timely analysis.

The important principle is that integration should reduce complexity, not simply move it somewhere less visible.

Stage 3: Validate

Can users trust the information?

Validation is where raw data becomes governed business information. This stage should establish:

• Agreed KPI definitions
• Reconciliation rules
• Data-quality checks
• Ownership and approval
• Refresh timing
• Change control
• Security requirements

A semantic model can help encapsulate shared relationships, calculations and business rules so that multiple reports reuse the same logic rather than recreating it independently. Microsoft describes well-designed semantic models as a foundation for reliable, governed analytics at scale.

Questions include:

• Has each critical KPI been formally defined?
• Can users trace a number back to its source?
• Are totals reconciled against authoritative systems?
• Who approves changes to calculations?
• Are certified reports clearly distinguished from working analysis?
• Can the business explain why two legitimate measures differ?

Confidence does not mean every number will always be perfect. It means the organisation can understand, trace and resolve discrepancies consistently.

Stage 4: Visualise

Is information presented in a way that supports action?

An attractive dashboard is not automatically a useful dashboard. Effective reporting prioritises:

• The audience
• The decision
• The level of detail
• The required frequency
• Relevant exceptions
• Clear comparisons
• Appropriate context

A Managing Director may need a concise view of:

• Revenue
• Margin
• Cash
• Delivery performance
• Inventory
• Capacity
• Major risks

A production manager may need:

• Schedule adherence
• Work-centre utilisation
• Material shortages
• Quality exceptions
• Overdue operations
• Labour performance

Both audiences may use the same governed data but need different presentation and depth. Good visualisation should make it easier to identify:

• What has happened
• Why it happened
• Whether action is required
• Who should act
• What should be investigated next

Power BI can support interactive dashboards, drill-through analysis, shared semantic models and controlled access.

The value comes from combining these capabilities with clear business definitions and dependable ERP data, not from visualisation alone.

Stage 5: Act

Does the reporting process improve decisions?

Reporting creates value only when it changes behaviour or enables better decisions. For each important dashboard or report, ask:

• What decision is this intended to support?
• Who reviews it?
• How often?
• What threshold requires action?
• Who owns the response?
• How is the outcome recorded?
• Is the report still used?

Examples include:

• A shortage dashboard triggering purchasing action
• A margin exception report prompting a pricing review
• An overdue-order dashboard escalating production constraints
• A cash-flow forecast informing payment and investment decisions
• A quality dashboard identifying recurring failure patterns

A report that is produced but does not influence any decision should be questioned, simplified or retired.

The goal is not to create more information. It is to create greater operational confidence.

A practical manufacturing reporting review

Businesses do not need to redesign their entire reporting environment at once. A focused review can begin with one important management question.

For example:

Can we reliably explain whether customer deliveries are improving or declining? The review might then follow these steps.

Step 1: Choose one decision

Select a decision with visible operational or commercial value.

Examples:

• Whether production capacity is sufficient
• Which inventory requires action
• Whether margins are declining
• Which orders are at risk
• Which customers are becoming less profitable

Step 2: Identify the existing reports

Document:

• Who creates them
• Which systems they use
• How often they are refreshed
• Which manual adjustments are made
• Who relies on them

Step 3: Compare the definitions

Ask each department to explain how its figure is calculated. Differences often become obvious at this stage.

Step 4: Trace the data

Follow each significant measure back to its source.

Identify:

• Manual hand-offs
• Duplicate entry
• Delayed updates
• Uncontrolled spreadsheets
• Missing ownership
• Inconsistent master data

Step 5: Agree the business definition

Document what the measure should mean and which variations are legitimately required.

Step 6: Build or refine the governed model

Create a shared logic layer that can support appropriate reports for different audiences.

Step 7: Test with users

Do not test only whether the totals calculate correctly. Test whether users:

• Understand the measures
• Can investigate exceptions
• Know what action to take
• Trust the output
• Can identify when data was refreshed

Step 8: Monitor adoption and quality

Review:

• Usage
• Data-quality exceptions
• Unused reports
• New duplicate reports
• Requests for manual adjustments
• Changes to definitions

Reporting confidence requires ongoing management, not a one-off dashboard project.

ERP, Power BI and Microsoft Fabric: what role does each play?

These technologies perform related but different roles.

ERP

ERP records and manages core business transactions and processes, including:

• Sales orders
• Purchasing
• Inventory
• Production
• Finance
• Customer and supplier records

A well-managed ERP environment provides structured operational data and consistent workflows.

Power BI

Power BI enables users to analyse, visualise and share information.

It can combine ERP information with approved data from other systems and provide:

• Dashboards
• KPI monitoring
• Drill-through analysis
• Trend reporting
• Role-based views
• Self-service exploration

Microsoft Fabric

Microsoft Fabric can provide a wider data and analytics platform for integrating, transforming, modelling, governing and analysing information across multiple sources. For organisations with more complex requirements, it can support common data foundations, reusable semantic models, lineage, security and governance.

Microsoft’s current Fabric guidance emphasises governance across the data estate, including ownership, sensitivity, lineage, access and auditability.

These tools should not be seen as competing alternatives. A typical architecture may use:

• Epicor ERP to manage transactions
• Integrations or Fabric to connect and prepare data
• Governed semantic models to define shared business logic
• Power BI to deliver analysis to decision-makers

The right architecture depends on the organisation’s size, systems, reporting needs, security requirements and internal capabilities.

Can Power BI solve inconsistent reporting?

Power BI can be an important part of the solution, but it cannot resolve every cause on its own.

It can help businesses:

• Connect approved sources
• Reuse governed semantic models
• Standardise calculations
• Automate refreshes
• Control access
• Share certified reports
• Reduce manual spreadsheet consolidation

It cannot independently correct:

• Poor transaction discipline
• Inaccurate master data
• Unclear KPI definitions
• Weak process ownership
• Conflicting departmental objectives
• Unresolved integration failures

A Power BI project should therefore begin with reporting requirements, process understanding and data governance, not with dashboard design.

Questions every manufacturing leadership team should ask

Use these questions to assess reporting confidence:

Data

• Which systems contain our most important operational data?
• Which system is authoritative for each data category?
• Where is data re-keyed or adjusted manually?
• Which recurring data-quality problems affect reports?

Definitions

• Do departments use the same KPI definitions?
• Are calculations documented?
• Who approves changes?
• Are exclusions and exceptions clear?

Reporting

• How many versions of key management reports exist?
• How much time is spent preparing and reconciling them?
• Can users trace a number to its source?
• Are reports refreshed frequently enough for the decisions they support?

Governance

• Who owns each critical data set and KPI?
• Which reports are certified?
• Who can create and distribute new reports?
• How are security and access managed?

Action

• Which decisions does each report support?
• What thresholds trigger action?
• Who owns the response?
• Which reports are produced but rarely used?

If several of these questions are difficult to answer, your business may benefit from a structured reporting review.

Signs your manufacturing reporting environment needs attention

Your reporting process may require review when:

• Management meetings regularly become reconciliation exercises
• Departments maintain their own versions of important KPIs
• Reports depend on one or two experienced employees
• Data is exported and manipulated manually every week or month
• Leaders question the accuracy of dashboards
• Financial and operational figures cannot be reconciled easily
• The same measure is calculated differently across reports
• Employees create private spreadsheets because shared reports are not trusted
• Reports are slow to produce or already outdated when distributed
• Users cannot trace figures back to source transactions
• The organisation has many dashboards but limited agreement about performance
• Reporting delays are affecting customers, inventory or production decisions

These are not simply technical symptoms. They often indicate wider issues involving processes, ownership, integration and governance.

How Blue Sky ERP helps improve reporting confidence

Blue Sky ERP helps manufacturing and distribution businesses connect ERP processes with effective reporting and analytics.

Depending on the organisation’s needs, this may include:

• Reviewing existing reports and data sources
• Identifying conflicting KPI definitions
• Assessing manual spreadsheet processes
• Connecting Epicor ERP and approved third-party sources
• Designing shared data and semantic models
• Developing Power BI dashboards
• Defining reporting governance and ownership
• Training users
• Monitoring and improving adoption

The objective is not simply to produce more dashboards. It is to create information that leadership and operational teams can use with confidence.