← Help center

Showing check-in and check-out times on the certificate

For a long time PreArrive only carried check-in dates. That was fine for "did the guest stay past their checkout" claims, but left a gap whenever the dispute was about an early arrival, a late-checkout fee, or a noise-after-hours rule. Times are now a first-class field on the property and on each reservation, with an IANA timezone so "3:00 PM" reads correctly regardless of where the guest is booking from.

Set them on the property

Open the property → Details card.

  • Check-in time: the default for every new reservation on this property. Common values: 3:00 PM, 4:00 PM.
  • Check-out time: same shape, on the other end. Common values: 10:00 AM, 11:00 AM.
  • Timezone: IANA name (e.g. America/New_York, America/Los_Angeles, America/Phoenix). The dropdown lists every US zone PreArrive supports. If your property is outside the US, the editor accepts any standard IANA name.

All three fields are optional, but the timezone is the one that matters most. Without it, "3:00 PM" is ambiguous. The guest's email client may render it in their own zone, and a denied-claim review may not be able to tell whether check-out at 11:00 AM was local-late or UTC-early.

Per-reservation overrides

Every reservation inherits the property's defaults but can carry its own check-in and check-out time. From the reservation:

  • On the New reservation form, click Override times to set a non-default value at creation.
  • On an existing reservation, open Actions ▾Edit times. Save to update the signed PDF preview, the iCal feed, and any not-yet-sent email.

A reservation override only affects that one stay. It doesn't change the property's defaults. Common reason to override: a Sunday redeye that needs 8:00 AM check-in, or a Monday flight that needs 4:00 PM check-out.

Where the times render

Once a reservation has effective times (either inherited or overridden), they show up:

  • Signing page: "Your stay: May 20, 3:00 PM → May 23, 11:00 AM ET" above the rules.
  • Certificate PDF: the Stay row reads the same window. The Claim Kit PDF adds explicit Check-in time / Check-out time / Timezone rows so a claims reviewer can match a noise complaint or late-departure photo against a specific local moment.
  • Guest email (signing invite, copy email, reminder): the body reads the times in the property's timezone.
  • Host email (signed notification, reminder): same.
  • iCal feed: events carry DTSTART / DTEND as full timestamps when both date and time are present. Your PMS reads them as a real arrival/departure window, not a midnight-to-midnight all-day block.

When times are missing, every surface above falls back to the legacy date-only behavior. The fallback is graceful. Nothing breaks, nothing reads "Not supplied."

How the scheduler uses them

When both a property timezone and a per-reservation check-in time are present, the auto-send scheduler anchors its offset on the local check-in moment. A 72-hour offset on a 3:00 PM Friday check-in in America/New_York means the packet is eligible at 3:00 PM Tuesday local, which is the moment the guest actually starts thinking about the trip.

Without those fields, the offset falls back to midnight UTC on the check-in date. Setting the timezone tightens the math considerably and is the single highest-leverage thing you can do to make the schedule feel right to the guest.

Calendar sync and times

iCal feeds from Airbnb, VRBO, and Booking.com carry DTSTART / DTEND entries. When the platform exports those as full timestamps (with hours and minutes), PreArrive extracts the local check-in and check-out times automatically and writes them onto the synced reservation.

When the platform exports them as date-only "VALUE=DATE" entries (Airbnb often does), no times come through. The synced reservation inherits the property defaults. You can still override on a per-reservation basis in the inbox or after confirming.

Was this helpful?

Still stuck? Message us — we read every message and reply within a few hours on weekdays.