My Job Finished After Its Due Date: Why, and What to Do

A job that finishes after its due date is usually telling the truth about a constraint you did not fully account for: capacity that was already spoken for, a scheduling direction that was never aiming at the date, or a delivery-ready tail that pushed the real finish past the last machine. The fix depends on which, and the schedule gives you enough to tell them apart in a couple of minutes.

EDGEBIC by User Solutions reports lateness against the delivery-ready date and marks a job late the moment the plan cannot make it, before the calendar passes the due date. That early warning is the point: a projected-late job is one you can still rescue. This post extends the "starts later than expected" symptom in the EDGEBIC troubleshooting guide to the finish date and the due date specifically.

First, Read What "Late" Is Measured Against

Late is not measured at the last machine. It is measured at the delivery-ready date: the last work-center operation plus the product's lead time, the calendar-day tail for curing, inspection, or freight. That tail consumes no machine capacity, but it is real time, and every surface (the Drive Schedule grid's days-late column, the dashboard, the Gantt) agrees on it deliberately, so the number never disagrees screen to screen.

Knowing that changes the first question from "why did the machine finish late" to "which of the causes below moved the delivery-ready date past the due date." Work them in order.

Cause 1: The Capacity Was Already Claimed

Forward-scheduled jobs are placed in priority order: lower priority number first, then start date, then due date. A job that finishes late is often standing behind higher-priority work that took the capacity first, or waiting on a slow predecessor branch that a downstream join cannot start without.

How to tell: walk the routing backward on the Gantt and find the long pole. If the finish is late because one upstream step ran days after you expected, that step is your cause, not the finish itself.

Fix: re-rank priorities if this job genuinely outranks what is ahead of it, or attack the upstream delay (an alternate machine for the slow step, a second shift on the bottleneck). The work center overload post covers freeing a machine that is standing in the way.

Cause 2: You Are Scheduling Forward at a Job That Needs a Deadline

Forward scheduling starts every job as early as capacity allows and lets the finish fall where it falls. The due date is a target it reports against, never a constraint it works toward. A job with a firm customer date and slack in front of it will happily start early, finish early, and still be reported against a date it was never steered toward, and if capacity is tight it can finish late without the engine ever having tried to hit the date.

How to tell: the job's direction is forward, and it has a real due date it needs to respect.

Fix: schedule that job backward from its due date. Backward placement right-aligns the work so it finishes on time with the slack deliberately in front. Scheduling a job backward from its due date is the step-by-step; the direction precedence rules (an actuals-started job always goes forward from its resume point, and a pinned bottleneck anchor outranks the due date) are covered in TOC buffers and direction precedence.

Cause 3: The Lead-Time Tail Ate the Margin

A job whose last operation lands on the due date is late by the length of its lead-time tail, because the tail delivers after the last machine stops. Forward scheduling does not reserve the tail for you.

How to tell: the last work-center operation finishes on or near the due date, yet the days-late column shows a positive number roughly equal to the product's lead time.

Fix: schedule the job backward. The backward pass targets the due date minus the lead time, so the tail lands on the due date rather than past it. If you must keep the job forward, shorten the front of the schedule (priority, alternates) enough that the last operation finishes a full lead time early. Understanding the two dates every job carries, item start and job end, is covered in EDGEBIC backward scheduling explained.

Cause 4: The Promise Never Fit

Sometimes the honest answer is that no feasible schedule finishes on time. A backward job in this situation falls back to a forward schedule and is reported as infeasible, with the forward start and end it could actually produce and the number of days late.

How to tell: the job was set to schedule backward, and it appears on the infeasible list rather than right-aligned to its date.

Fix: this is a planning decision, not a bug. If your scheduling policy is set to show the fit popup, the run holds its result without saving and shows you each infeasible job with its reason and forward window, plus editable due date, start date, and priority columns. Adjust the promise you can move, re-run, and only then commit. If the policy accepts the forward schedule automatically, the same jobs are still listed for anyone who asks; the difference is whether you review before or after the save. Editing the start date there sets the earliest start only, never a pinned anchor, so the job stays backward.

Prevention

• Choose direction per job, not per plant. Firm-date customer work belongs backward; make-to-stock and early-as-possible work belongs forward. Configuring scheduling policy sets the defaults and the infeasible-job behavior.
• Set lead times honestly. A product whose curing and freight take three days should say so, or its due-date math will always be optimistic by three days.
• Watch the projected-late flag, not the calendar. A job flagged late a week before its due date is a week of runway to re-rank, add capacity, or renegotiate. The late jobs report collects them so none slips unseen.