The charge posts to the guest folio, on its own, every time
In this market, charge-to-folio is the star feature everyone sells as an integration. In Room Order it is not an integration: it is the same database.
Why this feature defines the vendor
Ordering is half of room service; charging correctly is the other half. The modern guest expects to say “charge it to my room” and have it just work: no terminal at the door, no cash, no signing three papers. For the hotel, that charge must land on the right stay folio, ready for checkout and invoicing.
Traditional vendors achieve this by connecting to the hotel PMS through integrations: a bridge between two systems that do not know each other. When the bridge fails, charges get lost or duplicated, and the desk reconciles them by hand the next morning. Room Order is part of R2 OS, the system where the reservation already lives: the order and the folio share one database, so the charge never crosses a bridge.
How charging works in Room Order
From “confirm order” to the line item on the stay folio.
The QR knows which room is ordering
Each QR is tied to its room. On confirmation, the order is born linked to the active stay of that room, without the guest typing reservation numbers.
- QR tied to the room
- Linked to the active stay
- Zero friction for the guest
The order appears on the folio
The confirmed order posts as stay consumption: dishes, quantities, time and amount. The desk sees it on the same folio where the reservation lives.
- A line per order on the folio
- Traceable per guest and date
- Visible to the desk immediately
Or pay on delivery, you decide
Not every hotel wants everything on the folio. Run pay-on-delivery, or combine: folio charges for guests with a reservation and direct payment for outside visitors.
- Folio charge or pay on delivery
- Rules per hotel
- Pool visitors without a reservation included
Checkout without surprises
At the end of the stay, every consumption is where it belongs: on the folio, itemized. No tickets lost in a waiter pocket, no ghost charges to argue about.
- All consumption in one place
- Per-order detail at checkout
- Fewer disputes, more trust
Ask any vendor what happens to the charge when their PMS integration goes down at midnight. With Room Order the question does not exist: there is no integration to go down.
Charge to folio: native vs integrated vs none
The three realities of the market.
| Room Order (native) | PMS-integrated layer | External app | |
|---|---|---|---|
| Charge reaches the stay folio | |||
| No integration project | |||
| No point of failure between systems | |||
| Manual reconciliation next morning | No | Sometimes | Always |
| Per-order detail at checkout | Depends |
Frequently asked questions
Does the guest have to prove who they are to charge the room?
The QR already identifies the room and its active stay. The hotel decides the confirmation rules it wants for authorizing charges, based on its operation and risk profile.
What about visitors who are not staying?
They can order paying on delivery. Folio charging is for guests with an active stay; the rest of the flow works the same for any visitor at your pool or lobby.
How does the charge look at checkout?
As consumption line items on the stay folio, with dishes, time and amount per order. Guests recognize every charge and disputes go down.
Does it work if my hotel does not use R2 OS?
Room Order is at its best inside R2 OS, where folio charging is native. It can run standalone with pay-on-delivery, but automatic charge-to-room is exclusive to hotels on the platform.
Does this replace my invoicing?
It does not replace it: it feeds it. Consumption is posted and itemized on the stay folio, which is the base your hotel invoices from as usual.
Turn every room into your best table
Book a demo and watch your menu, your kitchen and your room folio work as one system.