Booking.com hides guest data after 30 days but Expedia sets no limit.

The OTA guest data clock the hotel trade has argued about for a month sits in Booking.com's General Delivery Terms at Annex 1, clause 2.2.6. It reads that Booking.com will make guest personal data available to the accommodation on the extranet for thirty days after the end of a guest's stay or the date of cancellation, and that it has no obligation to make that data available beyond this point. Expedia's equivalent document, the controller-to-controller agreement for independent hotels, contains no such clause. Where its transfer annex asks for the retention period, the answer for data flowing to the hotel is that it runs in accordance with the retention policy of the hotel.

This piece is for independent hoteliers who have read that an online travel agency takes the guest record away after checkout, and who want to know what the contracts they signed actually say. Both documents are public and were read in full for this article. Hospitality.today reported the thirty-day clause first, in August.

The OTA guest data window is a display setting, not a deletion of your record

The distinction the clause turns on is the word "available".

Clause 2.2.6 governs what Booking.com will show on the extranet. It says nothing about what the property may keep, and it carries an escape hatch: the thirty days runs "or by any other means and for any other period as determined by Booking.com". A property that pulled the reservation into its property management system on the day of booking holds that record on its own servers under its own retention policy, and nothing in the General Delivery Terms reaches into it.

That is not a loophole but the contract's own architecture. Annex 1, clause 2.1.2 states that where Booking.com makes personal data available, the accommodation acts as an independent and separate data controller over its own processing. Clause 2.1.3 goes further: neither party processes personal data on behalf of the other.

Expedia says the same in its own words. Clause 2.1 of the independent hotel agreement records that each party is an autonomous and independent controller, and clause 3.1(b) requires each to have its own lawful basis. Two of the largest platforms in the sector have written, separately, that the hotel owns the legal responsibility for its own copy.

The marketing bar covers unsolicited contact, not every future email

The second half of the trade reading is that these contracts forbid a property from ever marketing to a guest who arrived through a platform. That is not what either says.

Booking.com's clause 2.9.3 prohibits the accommodation from using the messaging service, or guest contact details provided by Booking.com, to send unsolicited electronic communications. The operative word is "unsolicited", and the clause is enforced by an indemnity rather than a general ban on future contact. Annex 1, clause 2.2.4 sets the wider rule, and it is conditional rather than absolute: the accommodation shall process the data only to the extent necessary to perform its obligations under the agreement, as otherwise agreed between the parties in writing, if the accommodation has a legal ground including consent from the guest where necessary.

Read in full, that sentence contemplates processing beyond the reservation where the property has a lawful basis. Read as the trade has read it, only the first limb exists. Expedia does not address marketing to past guests at all.

What follows is narrower and more useful than the version circulating. The contracts do not delete a property's guest list. They decide what the extranet shows, and they put the legal risk of using that list on the property rather than the platform. An address handed over at the front desk, with a record of that consent, sits outside the platform's contract entirely.

The clock that does end in a forfeiture is the one nobody is writing about

While the trade has been counting days on the guest record, a different countdown in the same document ends in money changing hands.

Booking.com's Annex 3A, clause 7.2 gives a property twelve months from check-out to charge the virtual card issued for a facilitated payment reservation. Clause 7.3 sets out what happens if it does not: the card is deactivated, the accommodation's rights and claims to the amount automatically cease to exist, and Booking.com has full right, title and interest in that amount. Clause 7.4 adds that the property releases and forever discharges Booking.com from any claim related to it.

That is a real forfeiture of room revenue already paid by a guest, written into the payment annex of the standard agreement, and it sits alongside the $10.1 billion of traveler cash the platform holds against stays not yet taken. A missed card charge is not a data question. It is the only clock in either contract where the property loses something it would otherwise have kept.

Expedia's data list runs further than most properties realize

The contracts also disagree about scope, and Expedia's is much the wider of the two.

Booking.com defines customer data narrowly: arrival and departure dates, nights booked, room type, room price, guest name and address, credit card details where applicable, and any specific request. Email is absent from that definition, appearing only in the list attached to the standard contractual clauses.

Expedia's transfer annex lists identification data, contact details including email and social media handles, tax and government identification numbers, bank and payment card details, billing information, booking history and preferences, correspondence, marketing and review data, prize draw entries, details of co-guests and emergency contacts, and loyalty information. It then names sensitive data in the same flow, including religious belief evidenced by food preference, and sexual orientation, ethnicity or accessibility needs as indicated by a search filter such as an LGBTQ-welcoming property.

A hotel receiving that as an autonomous controller carries the corresponding obligations, and most properties running a small connectivity stack they did not build have never read the list.

What this means for operators

Some properties are timing their export to the booking rather than the checkout, on the reasoning that a record already in the property management system is governed by their own retention policy and the thirty-day extranet window never applies to it. The trade-off is that the obligation travels with the record: once it is yours, the lawful basis for holding it is yours to evidence. Testing it takes one export and one look at what your system actually stores.

Others treat the front desk as the only source they will market from, on the reasoning that an address given in exchange for something the guest wanted carries a consent record no platform clause touches, which is the same logic behind the arguments over who produced the customer. The trade-off is volume: a desk capture rate below about half leaves most of the year unreachable.

Both readings are defensible from the documents. What neither settles is the twelve-month virtual card cut-off, which is not a matter of interpretation and which a property either charges in time or forfeits outright.