What Is cutoffTime in Shipping Schema?

cutoffTime is the order-processing time boundary after which a merchant no longer processes orders received that day, adding one day to the delivery-time estimate for orders after the cutoff.

The property expects a Time value and can be used on ServicePeriod and ShippingDeliveryTime. In modern service-oriented shipping graphs, it can sit inside the ServicePeriod used for handling time or transit-related timing context.

cutoffTime does not define the whole delivery promise. Duration, business days, origin, service, destination, holidays, inventory, and transit rules still determine the final customer-facing date.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Define the operational boundary.
• Encode the local time accurately.
• Combine it with calendar and duration.
• Test the final date.

Use the free backlink checker to identify linked landing pages before changing a shared shipping cutoff.

Primary specification: Schema.org definition for cutoffTime.

cutoffTime is accurate when orders on each side of the boundary receive the same processing start and delivery estimate as checkout.

cutoffTime can be used on ServicePeriod and ShippingDeliveryTime, and its expected value is Time.

ServicePeriod is the structured context that combines cutoffTime with duration and businessDays for handling or transit periods. ShippingDeliveryTime can also carry the property in the older total-delivery structure.

Do not attach cutoffTime directly to Product, Offer, OfferShippingDetails, ShippingService, ShippingConditions, or ShippingRateSettings. Those entities may contain or connect to a timing structure, but they are not listed parents for the property.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the timing parent.
2. Place the property inside it.
3. Use a Time value.
4. Validate the full entity path.

Review ServicePeriod and handlingTime in ShippingService.

Correct placement keeps cutoffTime attached to the period whose start it actually controls.

Encode cutoffTime as an ISO 8601 time with seconds and an explicit UTC offset when the offset is needed to preserve local operational meaning.

A value such as 14:30:00-07:00 identifies a local clock time and offset. A bare 14:30:00 can become ambiguous when servers, feeds, warehouses, and consumers operate in different time zones.

Generate the value from the warehouse or pickup-location policy, not the shopper browser or application server zone. Preserve the source zone identifier internally so daylight-saving offsets can be generated correctly for the relevant date.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Store the local zone authority.
• Generate ISO time and offset.
• Keep seconds explicit.
• Test parser and rendered graph.

An ISO cutoff value is reliable when it maps unambiguously to the merchant's local processing boundary on the order date.

Orders before cutoff may enter same-day processing, orders after cutoff add one day to the delivery estimate, and exact-cutoff behavior must follow an explicit merchant policy.

The definition explains the after-cutoff effect but does not resolve every merchant's equality rule. Checkout systems may treat exactly 2:00 PM as accepted or deferred depending on queue and operational policy.

Document equality in the authoritative commerce source. Test one second before, exactly at, and one second after, then repeat with different order channels and clocks to detect rounding or synchronization defects.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Define inclusive or exclusive equality.
2. Use consistent timestamp precision.
3. Synchronize clocks.
4. Test all three boundary cases.

Boundary behavior is correct when every system classifies the same timestamp identically.

The day added after cutoff must advance through the applicable business-day calendar rather than blindly adding twenty-four hours.

An order after cutoff on Friday may begin processing Monday when the warehouse operates Monday through Friday, but holidays or Saturday operations can change that result. The ServicePeriod businessDays value supplies the regular operating schedule.

Join each cutoff to the calendar of the warehouse, store, seller, or service that owns it. Do not apply one headquarters calendar across all origins or pickup locations.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Identify the fulfillment authority.
• Read its business days.
• Apply holiday exceptions.
• Advance to the next valid processing day.

The added day is truthful only when it follows the actual operating calendar for the selected fulfillment source.

cutoffTime can shift when handling begins, while handlingTime and transitTime determine separate preparation and carrier-movement intervals in the complete delivery calculation.

For delivery, an after-cutoff order may start handling on the next business day, then enter transit after dispatch. For pickup, the cutoff may shift preparation readiness without any carrier transit. A transit ServicePeriod can have its own operational constraints where supported.

Do not add the cutoff delay twice in both handling and total delivery logic. Define one authoritative calculation sequence and compare the composed date with checkout.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Classify cutoff once.
2. Calculate handling readiness.
3. Calculate transit if applicable.
4. Apply exceptions.
5. Compare final arrival or pickup date.

Compare transitTime in ShippingConditions.

cutoffTime integrates correctly when it shifts the proper stage once and the composed date matches checkout.

Each warehouse, store, seller, carrier handoff, and service may require its own cutoff because time zone, operating calendar, preparation capacity, and dispatch schedule can differ.

Express may close earlier than standard; pickup may close relative to store hours; a West Coast warehouse can accept orders after an East Coast facility has closed. Multi-origin carts may need the slowest package or multiple promises.

Resolve the actual fulfillment source before applying the cutoff. If allocation changes after checkout, the customer promise must still follow the authoritative availability and routing policy.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Resolve seller and origin.
2. Resolve selected service.
3. Load its local cutoff and calendar.
4. Calculate each shipment.
5. Combine only per checkout policy.

Multi-source cutoffs remain accurate when timing begins from the actual origin and selected service rather than a universal site setting.

Common cutoffTime mistakes include omitting the time zone, using the server zone, ignoring exact-boundary behavior, adding calendar days instead of business days, sharing one cutoff across services, and applying the delay twice.

Other defects include malformed time strings, stale daylight-saving offsets, cutoff after closing hours, mismatched warehouse allocation, missing holiday exceptions, and valid markup that produces a different date than checkout.

Repair the fulfillment timing source and generator together. Shared cutoff defects can change delivery promises across large Offer cohorts, so stage changes and keep timestamp regression tests.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Crawl every cutoff value.
• Validate format and parent.
• Map origin, service, and zone.
• Run boundary-date scenarios.
• Repair shared sources.

cutoffTime defects require format, zone, calendar, scope, calculation, and checkout evidence together.