Two dashboards, two different OEE numbers, same machine, same shift. This happens constantly in CNC shops — and it's almost never a data problem. It's a definition problem: two systems silently disagreeing about what counts as downtime, where the clock starts, or what "planned" means. This guide walks through the specific errors that cause TRS/OEE numbers to drift apart, how to spot each one, and how to fix it before it corrupts a quarter of reporting.
TL;DR:
Most OEE mismatches trace back to five repeatable errors: double-counted downtime, planned-time drift, clock mismatches between data sources, inconsistent micro-stop thresholds, and ambiguous event tagging.
Each error has a specific, checkable symptom — a systematic gap in one direction, a recurring spike at shift boundaries, or a category that keeps absorbing unrelated stops.
A short weekly audit (documented in a shared KPI dictionary) catches these before they become "the dashboard nobody trusts."
"TRS" (Taux de Rendement Synthétique) and OEE describe the same three dimensions — Availability, Performance, Quality — but the formulas only produce comparable numbers when every system uses the same clock, the same denominator, and the same event taxonomy. In practice, machine controllers, MES, and ERP rarely agree on all three by default. For the canonical formulas and terminology mapping, see the complete OEE guide; this article assumes those definitions and focuses on where they break down in production.
A KPI dictionary — one documented reference for scheduled_time, running_time, cycle_time_standard, good_count, scrap_count, and event timestamps — is the single fix that prevents most of the errors below. Without it, every team member builds slightly different assumptions into their reports, and reconciliation becomes a monthly fire drill.
The most damaging error is also the hardest to spot from a dashboard alone: two systems both claim the same stoppage. A PLC tap logs a tool-change stop. A separate MES event, triggered by the same physical event but a different signal, logs it again under a different reason code. Availability drops twice for one real event.
Symptom: Availability consistently lower than a manual stopwatch check by a stable percentage, especially on machines with more than one data source feeding the same KPI.
Fix: Assign every downtime event a single canonical source per machine. If two systems can theoretically both detect a stop, define which one is authoritative and suppress the other for that event type.
Availability = Operating Time / Planned Production Time. That denominator looks stable, but it drifts silently: a supervisor adds a maintenance window to the ERP calendar without updating the MES schedule; a shift pattern changes and the old planned-time template stays in place. The formula doesn't change — the input to it does, invisibly.
Symptom: A step-change in Availability that lines up with a schedule change, not a machine change.
Fix: Treat the planned-production-time calendar as a single shared source of truth, not a value re-entered per system. Log every calendar edit with a timestamp and owner so a step-change can be traced to its cause in minutes, not days.
Performance depends on comparing an ideal cycle time (often extracted from G-code) against actual operating time (usually from PLC or spindle-state signals). When these two come from different clocks — one from the controller's internal clock, one from an edge gateway's system clock — even a few seconds of drift compounds across a shift into a Performance number that's wrong in a consistent direction.
Symptom: Performance that's biased the same way (always slightly high or always slightly low) rather than randomly scattered.
Fix: Synchronize all machine, edge, and server clocks to NTP and verify daily. For methods to extract and validate standard times themselves, see the cycle time extraction guide and the G-code cycle time workflow — both cover how to reconcile program-derived estimates against measured runs, which is the second half of this same problem.
Chasing down which system's clock or event log is right, machine by machine, eats hours every week. JITbase reconciles machine, PLC, and program-derived timestamps automatically so Availability and Performance are calculated from one consistent source.
See how JITbase tracks OEE →Every shop needs a rule for what counts as a stop versus background noise — typically a configurable threshold like "ignore interruptions under 10 seconds." The error isn't having a threshold; it's having a different one per machine, per operator, or per reporting period without documenting the change. A threshold quietly moved from 10 seconds to 30 seconds makes Availability look better without any real improvement on the floor.
Symptom: Availability improves but downtime-event counts drop faster than downtime minutes — a sign that short stops are being filtered out, not eliminated.
Fix: Set the micro-stop threshold once, document it next to the dashboard, and review it on a fixed cadence (weekly is common) rather than adjusting it ad hoc when a number looks off.
Setup, tool change, material load, quality hold, breakdown — each needs a distinct reason code, but in practice one catch-all category (often "other" or "changeover") absorbs everything operators don't have time to classify correctly. This doesn't change the OEE number itself, but it destroys the diagnostic value of the dashboard: a shop can see Availability is low without ever learning why.
Symptom: One downtime category growing disproportionately relative to the others, especially right after a busy shift or a new operator onboarding.
Fix: Keep the reason-code list short (5–8 categories) so operators can tag accurately under time pressure, and audit the catch-all category weekly to reclassify anything that's been miscoded.
Even a clean, well-defined KPI can be corrupted downstream. A non-idempotent API retries a failed post and creates a duplicate event in the ERP. A batch job runs twice after a network hiccup and double-aggregates a shift's parts count. These errors are invisible at the machine level and only show up as an unexplained spike in a monthly report.
Symptom: A KPI that's correct in the MES but inflated or deflated once it reaches the ERP — the mismatch appears specifically at the integration boundary, not at the source.
Fix: Use unique event IDs and idempotent write operations for every integration between machine data, MES, and ERP, so a retried or duplicated message can't be posted twice.
If your ERP numbers and shop-floor numbers never quite match, the gap is usually in how — and how often — data moves between systems, not in the machines themselves.
Explore JITbase Production Monitoring →Run this once per quarter, or immediately if two dashboards disagree:
Pull the same shift's Availability from two systems (e.g., MES and ERP). If they differ by more than a few points, check for double-counted events before assuming a data error.
Confirm the planned-production-time calendar is identical across every system that calculates Availability.
Check NTP sync status on every machine, edge device, and server feeding OEE calculations.
Review the micro-stop threshold on record and confirm it hasn't drifted from the documented value.
Pull a Pareto of downtime reason codes and flag any catch-all category exceeding roughly 15–20% of total downtime.
Spot-check for duplicate event IDs in the ERP for a sample week.
For the full audit methodology and a broader data-readiness framework, see our OEE data readiness checklist and the shop-floor integration validation checklist, which covers acceptance thresholds for cycle-time variance and event completeness before go-live.
Fixing a single error is a one-time win; documenting the fix is what keeps it fixed. A shared KPI dictionary — a versioned document or table listing every canonical field, its source system, and the rule that resolves ambiguity — should live next to every dashboard so a new hire or a new vendor integration can't silently reintroduce one of the errors above. For practical steps on connecting that dictionary to your planning and reporting systems, see the ERP labor-tracking integration guide and the ERP/MES integration playbook.
For bilingual shops maintaining both an English "OEE" report and a French "TRS" report, keep the terminology mapping and the underlying field definitions in the same document — a good starting reference is our French-language piece on calculating cycle time from G-code for reliable KPIs, which covers the same reconciliation problem from the cycle-time side.
Once your KPI definitions are fixed, the next question is usually financial: how much is the fix worth. See what a clean TRS/OEE baseline is worth in recovered capacity.
Calculate your ROI →Most cross-system OEE disagreements come from a small, repeatable set of errors: double-counted downtime, planned-time drift, clock mismatches, inconsistent micro-stop thresholds, ambiguous tagging, and integration duplication.
Each error has a distinct symptom — look for systematic (not random) bias, or a mismatch specific to one system boundary — which makes root-causing faster than re-auditing everything from scratch.
A documented, versioned KPI dictionary is the durable fix: it prevents the same error from being silently reintroduced by a new integration or a new team member.
Double-counted downtime is the most damaging and the hardest to spot, because two systems can each correctly log a real event and still produce a wrong combined number when both are counted against the same Availability calculation.
The two systems usually disagree because they use different planned-time calendars, different clocks, or because an integration step duplicated an event during a retry. Checking each of these individually is faster than assuming the underlying data is wrong.
Compare Availability for the same shift from two independent sources. A downtime event that both a PLC tap and a separate MES trigger can detect is a common source of duplication, so start by checking machines with more than one data feed.
There is no universal number; the threshold depends on process tolerance and should be set once, documented, and reviewed on a fixed schedule rather than adjusted whenever a KPI looks unfavorable.
Some can. Clock mismatches and duplicate event IDs can be flagged by automated validation checks. Definition drift, such as a changed planned-time calendar or a shifted micro-stop threshold, is easier to catch with a scheduled manual audit against a documented KPI dictionary.