Actual Hours Appear With No Planned Hours: Causes and Fixes

When a day shows logged actual hours with zero planned hours beside them, it is usually an orphaned daily breakdown row from a step that had actuals and was then dropped from the forward plan, and a clean scheduling re-run reconciles the breakdown so plan and actual line up again. EDGEBIC by User Solutions carries planned and actual hours together in the daily breakdown, so a row with actual hours and no plan is a stray the anomaly report is built to catch.

This post covers the orphaned-hours symptom in the EDGEBIC troubleshooting guide. It is related to a reschedule created a duplicate schedule row, which covers duplicate detail inflating a step, and to actual dates look wrong, which traces suspect actuals to their source. To confirm the flag before and after, run the scheduler anomalies report.

What You Are Seeing

A step's daily breakdown shows actual hours on a day where the planned hours are zero. No work was expected on that day in the current plan, yet the logged hours sit there, and the step's actual total climbs above what the plan accounts for. The anomaly report flags the row as a stray breakdown.

Why It Happens

Cause 1: A Step Was Dropped From the Forward Plan After Logging (the Usual Answer)

When a reschedule removes a step's forward plan but the step had actuals logged, those hours can persist in the daily breakdown without a matching planned figure. The plan side went to zero; the actual side did not. The result is a row with actual hours and no plan beside them.

How to tell: the day carries logged hours, the plan for that step-day is zero, and a reschedule happened after the hours were logged.

Cause 2: The Breakdown Was Not Rebuilt on the Last Run

The persist step rebuilds the daily breakdown for non-completed schedules by deduplicating and recreating rows. If that rebuild was missed, an earlier cycle's row survives and can carry actual hours with no current plan.

How to tell: a clean re-run removes the row, confirming the detail was simply out of date.

Cause 3: The Hours Belong to Completed Work

If the logged hours are genuinely completed work, they should stay attached to the completed step, not float on a dropped one. An orphan on an empty day is the wrong home for real completed hours.

How to tell: the step or a sibling was completed, and the hours belong to that completion.

How to Fix It

• Re-run scheduling for the job. The persist step rebuilds the daily breakdown and reconciles the orphaned hours against the current plan.
• Verify with the anomaly report scoped to the job: the stray-breakdown flag clears after a clean run.
• Confirm completed hours stay attached to their completed step, which the merge preserves, rather than to a dropped one.
• Do not hand-delete the row, since a fresh run reconciles the breakdown and hand-edits can lose real logged hours.

How to Diagnose It, in Order

1. Confirm the plan for that step-day is zero while actual hours are present.
2. Ask whether a reschedule ran after the hours were logged, the common trigger.
3. Check whether the hours belong to completed work, which should stay attached to the completed step.
4. Re-run scheduling to rebuild the daily breakdown.
5. Verify the stray-breakdown flag clears and the actual total reconciles.

How to Prevent It

• Log actuals before rescheduling, so the historical hours are clean when the plan is rebuilt.
• Re-run scheduling to reconcile a stray row, never hand-edit, since the merge is what keeps plan and actual aligned.
• Watch the actual total against the plan, since an actual sum above the planned work points at an orphaned row.
• Verify with the anomaly report scoped to the job, which flags the stray breakdown before and confirms it is gone after. For duplicate detail inflating a step under a single header, see a reschedule created a duplicate schedule row.