> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abrahospitality.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reservation Statuses

> How reservation statuses work in ABRA and how PMS statuses map into them

# Reservation Statuses

ABRA displays and filters reservations using a small set of **internal statuses**. These statuses are fed primarily by your PMS integration (Oracle OPERA, Maestro, MEWS, etc.).

This page explains:

* The **statuses you see in ABRA**
* Which ones are **stored** vs **display-only**
* How PMS events and fields typically map into them

## ABRA reservation statuses

These are the primary statuses used in ABRA:

| ABRA Status   | Meaning                                                       |
| ------------- | ------------------------------------------------------------- |
| **Upcoming**  | Future reservation that has not started yet                   |
| **In-House**  | Guest is currently checked in                                 |
| **Past**      | Stay has ended / guest checked out                            |
| **Cancelled** | Reservation was cancelled                                     |
| **No Show**   | Guest did not arrive                                          |
| **Tentative** | Reservation exists but is not firmly confirmed (PMS-specific) |
| **Unknown**   | ABRA could not confidently map the PMS state                  |

### Display-only statuses

ABRA also shows two “operational” buckets that are computed for display:

* **Arrivals**: reservations that are **Upcoming** and have a check-in date of “today”
* **Departures**: reservations that are **In-House** and have a checkout date of “today”

<Info>
  These are **not canonical stored statuses**. They are convenience filters built from stored status + dates.
</Info>

## How statuses are set

At a high level, ABRA status updates happen via:

* **Real-time events** (streaming / webhooks) from the PMS
* **Scheduled sync jobs** (legacy fallbacks in some integrations)
* **Manual sync actions** (e.g. staff-triggered “sync from PMS”)

ABRA attempts to map PMS-specific terminology into a consistent internal model. The mapping differs by PMS (see each PMS integration page).

## Common mapping model

Most PMSes provide some combination of:

* an explicit **reservation state** (confirmed / checked-in / checked-out / cancelled / no-show)
* explicit **events** (check-in, check-out, cancel, no-show)
* the stay **date range** (check-in/check-out dates)

ABRA’s internal status is typically driven by the most authoritative PMS signal available (usually explicit status fields or explicit events).

## When something looks wrong

If a reservation’s status in ABRA doesn’t match what you expect from the PMS, it is usually due to one of the following:

* A PMS update hasn’t been received yet (temporary delay)
* The reservation was changed in the PMS in a way that doesn’t emit a status-changing event
* The reservation has incomplete data (missing dates or missing identifiers)

If this persists, contact ABRA support with:

* hotel name
* reservation confirmation number
* a screenshot of the reservation in ABRA (showing status + dates)

## Status lifecycle (conceptual)

```mermaid theme={null}
stateDiagram-v2
  [*] --> Upcoming
  Upcoming --> In-House: Check-in
  In-House --> Past: Check-out
  Upcoming --> Cancelled: Cancel
  Upcoming --> No_Show: No-show
  Tentative --> Upcoming: Confirm
  Upcoming --> Tentative: Optional/Requested (PMS-specific)
  Past --> In-House: Reverse check-out (PMS-specific)
  In-House --> Upcoming: Reverse check-in (PMS-specific)
```

<Note>
  Not every PMS supports every transition (e.g. reversals). See the per-PMS mapping sections for details.
</Note>