A haul truck at an open-cut mine received its 5,000-hour engine service twice in three weeks. The first service was correct — the truck had genuinely hit 5,000 operating hours. The second service was triggered because SAP PM’s counter reading jumped from 9,998 to 12, the counter having overflowed at 10,000, and the system calculated that 4,986 hours of usage had occurred since the last reading.

The maintenance planner caught it and cancelled the second work order manually. But the underlying problem — SAP PM’s handling of counter overflows on mining equipment — remained in the system, silently corrupting the maintenance scheduling data that fed every reliability report downstream.

How SAP PM counters work

SAP PM tracks equipment usage through measuring points configured as counters. A haul truck might have counters for engine hours, odometer kilometres, and payload cycles. Each counter has a measuring point linked to the equipment record, and maintenance plans reference these counters to trigger time-based or usage-based work orders.

When a technician or automated system enters a new counter reading via a measurement document, SAP calculates the delta between the current reading and the last reading. That delta drives the maintenance plan’s schedule. If the last reading was 4,500 and the new reading is 5,000, the delta is 500 hours, and any maintenance plan triggered at a 500-hour interval generates a work order.

The counter overflow reading is a configuration value that tells SAP what happens when the counter exceeds its maximum. For a 5-digit mechanical hour meter, the overflow value is 99,999. When the next reading is lower than the previous one and the counter is configured with an overflow value, SAP should recognise that the counter has wrapped around and calculate the correct delta.

Where it breaks

The problem is threefold.

First, the overflow value has to be configured correctly. In our case, the haul trucks had electronic hour meters that displayed 4 digits with one decimal place, giving a maximum of 9,999.9. The counter overflow in SAP was configured at 99,999 — a 5-digit value — because someone had set it for a mechanical counter format that didn’t match the actual meter. When the reading went from 9,998 to 12, SAP didn’t recognise the overflow. It saw a reading that was lower than the previous one but below the overflow threshold, and depending on the configuration, either rejected it or treated it as a negative delta.

Second, the behaviour on overflow is configurable but poorly documented. SAP PM offers several options for what happens when a reading is lower than the previous one: reject the measurement document, accept it and calculate a negative delta, or accept it and calculate the wrap-around delta. The setting is in transaction SPRO under Plant Maintenance → Maintenance Plans → Scheduling → Counter-Based Maintenance Plans, and it interacts with the “Permit Lower Value” flag on the measuring point. Getting the combination wrong means either legitimate overflow readings are rejected (and technicians learn to stop entering them) or non-overflow decreases are incorrectly treated as overflows.

Third, nobody tests this until it happens in production. Counter overflows are rare events — a haul truck running 6,000 hours per year hits a 10,000-hour overflow every 20 months. By the time it happens, the person who configured the counter has moved on and the technician entering the reading doesn’t know why it’s being rejected or accepted incorrectly.

The downstream data problem

For a data engineer building analytics from SAP PM data, counter overflow creates two problems in your data warehouse.

Negative deltas in your usage calculations. If you’re extracting measurement documents and calculating equipment utilisation from the delta between consecutive readings, an uncorrected overflow produces a negative value that either breaks your aggregation or, worse, gets silently absorbed into an average that’s now wrong. A fleet of 40 haul trucks where two have overflowed counters can skew the fleet average utilisation by 5–8%.

Missing measurement documents. If the overflow causes SAP to reject the reading, there’s a gap in the measurement history. Your utilisation calculation shows zero hours for that period, which looks like the truck was parked. Reliability reports that calculate planned vs. unplanned maintenance ratios now have a denominator problem — the operating hours are understated, making the maintenance ratio look better than it actually is.

What I do now

When building a data pipeline from SAP PM measurement data, I add three checks:

  1. Delta validation. Flag any measurement document where the calculated delta is negative or exceeds the maximum plausible usage for the measurement interval. A haul truck can’t run more than 24 hours in a day. If the delta says it did, something overflowed.

  2. Gap detection. If the time between consecutive measurement documents exceeds the expected entry frequency by more than 2x, flag it. A missing reading often means a rejected overflow entry that the technician gave up on.

  3. Overflow correction. For counters with known overflow values, calculate the correct delta as (overflow_value - previous_reading) + current_reading when the raw delta is negative. This requires knowing the overflow value, which means extracting it from SAP’s configuration tables, not hardcoding it.

The truck getting serviced twice was a visible symptom. The invisible damage — corrupted utilisation metrics, wrong reliability ratios, and skewed fleet analytics — was worse because it shaped decisions without anyone knowing the data was wrong.