Hotel distribution and listing glossary

A platform that advertises and sells accommodation to travellers on behalf of the property, usually taking a commission on completed stays.

Each OTA holds its own copy of your listing content, which is why the same hotel can describe its breakfast differently in five places at once. An OTA is not a single system you update; it is a separate record with its own fields and its own idea of what a field means.

A comparison surface that shows prices from several booking sources for the same property, sending the traveller onward to whichever source they choose.

Metasearch mostly renders content it has received from elsewhere, so a wrong amenity on an OTA listing can reappear on a comparison page you never edited. Fixing the upstream record is the only durable repair.

Unpaid links to a property's own booking source shown alongside paid results on Google, managed through Hotel Center along with rates and availability.

They are rate-and-availability plumbing rather than listing content, which is exactly why hotels mix them up with Business Profile. Content and commerce are two different Google products with two different owners.

The page a traveller actually reads, as distinct from the record you edit in a partner portal.

The whole discipline of listing verification rests on this distinction. A saved field in an extranet is a statement of intent; the public page is the only evidence that the intent arrived.

The platform-provided dashboard where a property manages its listing, rates and reservations for one channel. Booking.com's is called the Extranet; other platforms use their own names.

Each channel's extranet is a separate login holding a separate copy of your content, and they do not talk to each other. Knowing which portal owns a field is the first step of fixing it.

Expedia Group's partner platform. Expedia Group states a listing managed there appears on brands including Expedia.com, Hotels.com, Travelocity, Orbitz and Wotif.

It is the reason there is no Hotels.com extranet to find. One record feeds several consumer brands, so a Hotels.com problem is corrected in Partner Central and then verified on the Hotels.com page itself.

Trip.com's partner platform. Trip.com states that once a property is live you can update your details in eBooking at any time.

Trip.com publishes little about where individual fields live, so your own notes from the first time you edited a field are effectively the documentation for this channel.

Software that distributes rates and availability from one place to many channels, and in some configurations sends listing content as well.

The most common wrong assumption in hotel distribution is that a channel manager keeps descriptive content in step. It usually syncs rates and availability reliably and content partially or not at all, which is why listings drift while the calendar stays perfect.

The system running the property's day-to-day operation: reservations, room assignment, housekeeping, guest folios and billing.

A PMS knows what the hotel does, not what the internet says about it. Where content flows out of a PMS through an integration, a field corrected in an extranet can be overwritten on the next push.

The system that holds rates, inventory and reservation logic centrally, usually for a group or chain, and feeds them to the channels and the booking engine.

In a group, the CRS is frequently the real source of truth for rate plans. An operator editing a rate-level fact in an extranet may be editing a copy that the next synchronisation replaces.

A reservation network used primarily by travel agents and corporate booking tools to search and book accommodation, air travel and car hire.

GDS content is usually terse and separately maintained, so a property can be accurate everywhere a leisure traveller looks and out of date where a corporate agent does.

A certified third party that connects a property's systems to a platform's inventory or content interface on its behalf.

Where one is involved, some fields become read-only in the portal and an edit has to be made upstream. A value that reverts after you change it is the classic symptom.

The software that takes a direct reservation on the property's own website.

It is the one channel whose content you control completely, which makes it the natural home for the approved wording every other channel is checked against.

A sellable combination of price and conditions: what the guest pays and what that payment includes, such as meals, cancellation terms and prepayment rules.

This is the single most useful distinction in a listing audit. Two channels showing different breakfast or cancellation terms are often showing different rate plans, and both can be correct - which is why the rate plan must be recorded alongside every captured value.

What meals a rate includes: room only, bed and breakfast, half board, full board, or all-inclusive. Booking.com configures meals both as a price payable on arrival and as an inclusion in a specific rate plan.

The published content models carry structured fields for breakfast and for all-inclusive and none for half or full board, so the middle of the range survives only as prose - which is why it is the least consistently published board code.

A rate calculated from another rate by a fixed rule, such as a percentage discount or a set amount off a parent plan.

A derived rate inherits changes from its parent, including mistakes. One wrong edit upstream can move several published prices and the inclusions attached to them.

A gross rate is the price a guest pays, from which the channel deducts commission. A net rate is what the property receives, with the channel setting the guest-facing price above it.

The two models produce different commission bases and different pass-through tax treatment, which is the usual reason a calculated commission figure disagrees with a settlement statement.

The number of rooms of a given type made available to a channel for a given date.

Not content, but it shapes what content a traveller ever sees: a room type with no allotment on a channel is a room type that channel's audience cannot find, however well it is described.

A block that prevents a room type or rate plan being sold for particular dates.

A closeout left in place after the reason for it has passed is invisible in a content audit and indistinguishable, from the traveller's side, from a property that is simply full.

A rule requiring a booking to cover at least, or at most, a set number of nights.

It changes which rate a channel can display for a given search, so two channels searched with different stay lengths can legitimately show different inclusions. Fix the search before comparing the content.

Rate parity is an arrangement about the prices a property publishes across channels. Content parity is the separate question of whether the factual details it publishes agree.

They are constantly confused and they are not the same problem. This site is about the second: whether your breakfast, parking and arrival facts match, which is a question of accuracy rather than of commercial terms.

The descriptive, slow-changing information about a property: facilities, policies, descriptions, photos and amenities, as opposed to rates and availability.

It is the half of distribution with no alarm attached. Rates and availability break loudly and get fixed; a wrong pet policy can sit published for years.

Which level a fact belongs to. Expedia Group's reference lists document amenities at property, room and rate-plan level.

An amenity recorded at the wrong scope reads as available everywhere or nowhere. Most apparent contradictions between channels are scope differences rather than errors.

Matching a property's room types to the equivalent entries a channel or intermediary holds, so that the right unit is sold with the right description.

Mapping errors produce the worst class of listing problem: a guest who booked one room and will be given another, with the mismatch invisible in any field-level comparison.

The classification a channel assigns - hotel, hostel, apartment, guesthouse and so on. Expedia Group's reference lists give each property exactly one category.

The category decides which fields a channel offers you at all, so a misclassified property is structurally unable to publish facts it has. A cluster of missing fields often resolves to one wrong category.

Airbnb's structure for a property with several bookable units, where Airbnb states property amenities are those in shared or common areas and unit amenities are those available in different units.

It is how a hotel is configured on Airbnb, and it explains why an operator looking for a single listing editor cannot find the shared-space fields.

A platform's published structure for accommodation data - which facts exist as fields, and what each one means. Google's lodging schema is the most openly documented example.

Reading one tells you what a channel can and cannot express. Several listing facts that operators assume are missing by accident - half board, reception hours, minimum check-in age - simply have no field to live in.

Google's structured amenity and service values for a hotel, edited in the Hotel details section of a verified Business Profile. Google states they cannot be updated through the spreadsheet upload.

The bulk-upload exception catches out groups managing many properties: a file that uploads without error will not have changed a single hotel attribute.

The property's own authoritative record of each factual value, with its scope, its owner and the date it was last reviewed.

Without one, an audit can only report that channels disagree. With one, it can say which channel is wrong - which is the difference between a list of differences and a list of fixes.

Two or more readable sources publishing values for the same field that cannot both be true of the same property, rate and date.

Setting the bar at 'cannot both be true' is what keeps a comparison honest. A difference in wording, or between two rate plans, is not a conflict, and counting it as one manufactures problems.

A field for which no readable source published a usable value, so there is nothing to compare and no basis for calling it either consistent or wrong.

It is not the same as agreement and must never be scored as one. A field nobody published is a gap to fill, and reporting it as a match is the most tempting way for a checker to flatter a property.

A listing that was found but could not be retrieved, so it contributed no evidence either way.

A channel we could not read is not a channel with no mismatches. It has to be reported as unverified, or a coverage gap silently becomes a clean bill of health.

Converting semantically equivalent values to a common form before comparing them, so that 15:00 and 3 pm, or EUR 77 per day and EUR 77 per night, are not treated as disagreements.

Without it a comparison reports wording differences as errors. With it, the original wording still has to be kept beside the normalised value, because the evidence is what an operator will act on.