How do I prove where a KPI number came from during an audit?

You do it by producing a defensible evidence chain, not by showing a dashboard alone.

For an auditor, the question is usually not whether the KPI looks reasonable. It is whether you can trace the reported number back to controlled source data, explain the calculation, show the time period and filters used, and demonstrate that the result was not altered outside approved process.

In practice, you should be able to show:

• the KPI definition and formula in a controlled document or governed analytics layer
• the exact report version or dashboard version viewed
• the reporting period, plant, line, work center, product family, or other scope filters applied
• the source systems involved, such as MES, ERP, QMS, historian, CMMS, or manual logs
• the data lineage from source records to transformation steps to the final metric
• who changed the logic, when, why, and under what change control
• any exclusions, overrides, reclassifications, or late data corrections
• evidence that timestamps, units of measure, and master data mappings were handled consistently

What usually counts as proof

A strong answer during an audit is a reproducible walkthrough. For example: here is the KPI definition, here is the approved data source list, here is the query or transformation logic, here are the production or quality records included, here is the reconciliation to the report total, and here is the audit trail showing no unauthorized edits.

If your KPI is calculated in BI tooling, that can be acceptable, but only if the semantic layer, source mappings, refresh behavior, and access controls are documented and controlled. A screenshot is not proof. A spreadsheet export without version control is usually weak proof. A manual KPI board with no retained calculation record is weaker still.

What auditors often challenge

• metrics built from multiple systems with inconsistent part numbers, work order IDs, or event timestamps
• KPIs that depend on manual data entry without review, approval, or exception handling
• formula changes that were made informally after a business rule dispute
• backfilled or corrected data that changed historical KPI values without a retained revision trail
• different plants using the same KPI name for different calculations
• MES, ERP, and QMS data joined through fragile custom integrations or spreadsheet workarounds

These are common brownfield realities. Many plants can calculate a KPI, but fewer can prove lineage cleanly across legacy systems, custom interfaces, and long-standing local practices. That is a data governance and integration problem as much as an analytics problem.

What you need in a regulated environment

You generally need controls around traceability, version governance, change control, and record retention. The exact level depends on what the KPI is used for. A visual management metric for daily operations may not need the same rigor as a KPI used to support quality decisions, management review evidence, customer reporting, or corrective action closure.

If the KPI influences regulated records, release decisions, formal quality reporting, or audit evidence, the bar is higher. You should expect scrutiny on data integrity, system configuration, validation status where applicable, and whether the underlying records are complete and attributable.

No system can guarantee that outcome by itself. If source data is incomplete, master data is inconsistent, interfaces are unreliable, or calculation logic is unmanaged, your audit position is still weak even with modern dashboards.

Best practical approach

• Standardize KPI definitions across sites and functions before trying to automate them broadly.
• Maintain a governed metric catalog with owner, formula, source systems, business rules, exclusions, and approval history.
• Retain report versions or calculation snapshots for metrics used as formal evidence.
• Reconcile KPI outputs periodically to transaction-level records.
• Limit manual adjustments and require reason codes, approval, and audit trail when they are unavoidable.
• Use stable identifiers across MES, ERP, QMS, and related systems, or document the mapping logic explicitly.
• Test what happens when data arrives late, is corrected, or is duplicated across interfaces.

In short, you prove where a KPI came from by showing lineage, logic, scope, controls, and reproducibility. If you cannot recreate the number from retained records under controlled rules, then the KPI may be operationally useful, but it is not strong audit evidence.