What Is a Quote Expiry Date?

A quote expiry date is the last day a quoted price and promise date are meant to stand, required on every quote and defaulting to thirty days out. It looks like a commercial formality and it is really a data-integrity control, because the two most valuable numbers on a quote, the delivery date and the cost, are both snapshots of a moving target. In EDGEBIC by User Solutions the expiry date is the window inside which that snapshot is still worth believing, and the lifecycle includes an expired status so a stale quote can be labeled as such rather than quietly resurfacing.

How it works

The field lives on the quote form beside the quote date and the target date. It is required, it must be later than the quote date, and it arrives pre-filled thirty days ahead so the default is a sensible commercial validity period rather than a blank.

What makes the date matter is where the quote's numbers come from. Pressing simulate runs the real scheduling engine: a temporary job for the quoted product and quantity is placed against the plant's current capacity, honoring the same shifts, closures and existing job load a real scheduling run would see, and then the resulting dates, hours and costs are read off and the temporary job is deleted. Nothing touches the production plan, which is why the simulation can be re-run freely.

The consequence is that every simulated figure is dated. Three inputs behind it move independently:

Because rates and capacity are the inputs most likely to move without anyone thinking about a particular quote, a warning banner appears on the quote view when either has changed since the quotes were simulated, prompting a refresh and a re-run before sending. That banner is the live counterpart to the expiry date's calendar rule.

The expired state is part of a lifecycle you drive by hand, with one exception:

Every status except converted is informational, so you may move between them freely. Converted is the one the system sets, and it blocks any further conversion so a single quote can never produce two orders. The full set is defined in what is a quote status.

A concrete example

A quote is raised on the sixteenth of July with an expiry of the fifteenth of August. Simulated the same day, it comes back with a window ending on the fourteenth of August, 151.50 estimated work hours and an estimated cost of 9,230 against a quoted total of 17,000, giving a comfortable margin.

The customer goes quiet and calls back on the twentieth of August, five days past expiry, ready to proceed.

Nothing about the stored row has changed, and that is the trap. In the intervening five weeks the plant accepted other work, and several hundred hours of it landed on the same mill this quote's largest operation needs. Re-simulating produces a later end date, because the queue in front of that operation grew. If the mill's hourly rate was also revised upward in July, the cost moves too, and the margin that looked comfortable is now something the sales manager should see before a price is confirmed.

The correct sequence is short: re-simulate, compare the new end date to what the customer expects, check whether the cost moved, re-derive the price from markup if it did, then set the status to approved and convert. Two minutes of work, and the difference between a promise the plant can keep and one it cannot.

How EDGEBIC uses it

The quote grid carries the status filter and the customer and order filters, so finding quotes that need attention is a matter of narrowing the list rather than scrolling it. Because status is informational, an expired label is a signal to colleagues rather than a lock, and nothing stops a genuinely still-valid quote from being revived deliberately after a fresh simulation.

Three habits make the field earn its keep:

• Keep the default thirty days unless the business genuinely quotes longer. A short honest window prompts the re-simulation; a long one suppresses it.
• Re-simulate anything older than its window before reviving it. The stored numbers are not wrong for the day they were produced; they are simply about a shop that has moved on.
• Act on the changed-rates banner immediately. It is telling you the inputs behind stored numbers have already changed, which is more specific than a calendar rule.

If a revived quote no longer meets the customer's date, the next step is not to pad the estimate. Explore what would actually make the date achievable, compare the alternatives with numbers, and only commit to the one you will really execute. That path runs through what is a quote scenario. And when a scenario or a re-simulation moves the cost, re-derive the price rather than leaving the old figure, as described in what is markup percent in quote pricing.

The takeaway

A quote expiry date is a short, deliberate window that makes staleness visible. Because a quoted date and cost are snapshots against a shop load and a rate table that both keep moving, the expiry field is less about contract terms than about knowing when to look again. Default to thirty days, re-simulate on revival, and act on the changed-inputs banner whenever it appears. To see quote simulation and its lifecycle in a working system, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring terms, read what is estimated lead time on a quote and what are estimated work hours on a quote.