Why Quoted Hours Differ From the Calendar Span in EDGEBIC

A quote's estimated hours in EDGEBIC are the real work hours the simulation allocated, not the calendar span from start to finish, which is why the hours look far smaller than the lead time. In EDGEBIC by User Solutions, a job that spans weeks on the calendar may hold only a fraction of that in actual labor, because the span includes nights, weekends, holidays, and time queuing behind other work. The distinction is not a rounding quirk. It is what keeps a quote's cost honest, because labor is priced from work hours, and costing from the calendar span would inflate every quote that crosses a weekend.

Two numbers that answer two questions

Every simulated quote carries both an estimated-hours figure and a lead time, and they measure genuinely different things.

Estimated hours are the sum of the work hours the simulation allocated to work centers across the job. This is labor content: the time operators and machines actually spend on the part.

Lead time is the calendar span from the simulated start date to the simulated end date. This is the journey the job takes through a busy shop, including everything that is not labor.

A quote can show 151 work hours and a 25-day lead time on the same row. Both are correct. One tells you how much work the job is; the other tells you how long it takes to get that work through the current backlog. Confusing them is the source of most "the software is wrong" reactions.

Where the calendar span goes

If a job holds 151 work hours but takes 25 calendar days, where do the other days go? Into everything that is not work:

• Queuing behind committed jobs. The quoted job waits its turn on shared machines, and that wait is the biggest reason a far-out date appears. It is capacity, not labor.
• Nights and non-working hours. The shop does not run around the clock, so the clock keeps advancing while no work happens.
• Weekends and holidays. Days the plant is closed fall inside the span but add zero work, which is why turning on weekend production in a quote scenario shortens the span while leaving the hours alone.
• Setup and sequence gaps. Changeovers and step dependencies stretch the window without adding proportional labor.

None of this is labor content, which is exactly why it belongs in the lead time and not in the hours. The far-out end date is the shop telling you how busy it is, a point covered in quoting when the shop is already full.

Why cost must come from work hours

The reason this distinction is load-bearing is cost. Labor is each work center's allocated work hours times its rate. EDGEBIC sums the work hours from the simulated schedule, so the labor line reflects what the job actually consumes on the machines.

Now imagine costing from the calendar span instead. A job that starts Friday afternoon and finishes Monday morning spans about 66 clock hours but may contain only six hours of real work. Multiply 66 hours by a shop rate and you have charged the customer for a whole weekend nobody worked. Across a book of quotes, span-based costing adds a hidden surcharge to every job that crosses a night, a weekend, or a holiday, and it loses deals you should win. Pricing from work hours removes that surcharge entirely. The full cost mechanics are in pricing a quote from the schedule.

A worked example

Acme's 200-unit Widget-A quote simulates to 151.5 work hours: 20.5 on the saw, 101.0 on the mill, and 30.0 on assembly. The window comes back July 20 to August 14, a 25-day lead time.

Read the two numbers separately. The 151.5 hours is the labor the job needs, and it is what the cost is built from: saw hours times the saw rate, mill hours times the mill rate, assembly hours times the assembly rate, plus material. The 25 days is how long those 151.5 hours take to clear the shop, because the milling step queues behind other committed work and the calendar includes weekends. Had the shop been empty, the same 151.5 hours might have finished in a week, and the simulation would have said so. The hours did not change; the calendar journey did.

This is why a longer lead time does not mean a more expensive job. The price tracks the hours, and the hours are steady regardless of how full the shop is. Only the date moves with the backlog.

Reading the two numbers like a planner

A few habits keep the distinction useful:

• Quote the price from the hours, the date from the span. They are decoupled on purpose. A busy shop lengthens the date without touching the cost.
• Do not multiply lead time by a rate. That reintroduces the weekend surcharge the work-hour model exists to remove.
• Treat a far-out date as a capacity signal, not a cost signal. If the date looks long, check the bottleneck's backlog, then consider a scenario to shorten it. The cost is unaffected either way.
• Explain both to the customer. The hours are what they pay for; the days are how long it takes through your current load. Said plainly, the two numbers stop looking contradictory.

The takeaway

Quoted hours and the calendar span differ because they measure different things: hours are labor content, and the span is the calendar journey through a busy shop, including queuing, nights, weekends, and holidays. EDGEBIC costs from work hours so the price reflects real labor, and it reports the calendar span as the lead time so the date reflects real capacity. Read the price from the hours and the date from the span, never mix them, and both numbers stay honest. See how the schedule becomes a price in pricing a quote from the schedule, walk the full workflow in the EDGEBIC quoting guide, and see the platform in full on the EDGEBIC overview.