The day you connected your eighth supplier, your inventory did not become eight times larger. The result list got longer, the page got slower, the same hotel appeared three times, and your reservations team started asking which one they were supposed to sell. That is not a sign of a badly built integration. It is the natural behaviour of multi-supplier inventory: every supplier sends the same physical property with its own code, its own spelling of the name and its own content quality.
The gain is not in the number of connections. The gain is hidden in three decisions that reduce those overlapping views into one correct record: how you decide that two records are the same hotel, which of the two offers for that hotel goes on sale, and — when you merge two records — which fields you blend and which ones you never touch. The third is the least known and the most expensive, because a wrongly merged cancellation policy makes the customer read the wrong terms, and the agency pays the difference.
This article collects the thresholds, decision orders and control routines that a contracting or product manager can use when making those three decisions. That includes the allotment, stop-sale and release triangle that kicks in the moment you put your own contracted hotels into the same list. Even if you use no software at all, most of the rules here can be applied in a spreadsheet and one weekly meeting agenda item.
The problem starts with your second supplier and becomes unmanageable at the eighth
With a single supplier you do not have a duplicate problem. The moment you connect the second one, the same property starts appearing twice. From there the growth is not linear but multiplicative: every new source overlaps separately with every source you already have.
The scale of that overlap is higher than most teams assume. According to Vervotech's 2026 hotel mapping guide, in a large market such as Dubai, Bangkok or London the inventory overlap between any two suppliers routinely exceeds 60%. The same source notes that a mid-sized online travel agency sooner or later ends up connected to 15 suppliers. So what you manage is not 15 clean lists — it is 15 largely overlapping views of the same properties.
There is a moving part too. In the analysis AltexSoft builds on GIATA data, GIATA's twenty-year statistics show that around 2% of hotels go through a fundamental change every year: a change of name, a change of chain affiliation, or updated contact details. If your catalogue holds 3,000 hotels, the identity data of roughly 60 properties drifts every year. Mapping is not a job you finish once; it is an asset with a maintenance cost.
| Connected suppliers | What happens in practice | What to do |
|---|---|---|
| 1 | No duplicates, but no comparison either | No mapping needed |
| 2-3 | Duplicates become visible, can be cleaned by hand | Start defining canonical identity |
| 4-7 | Staff can no longer see which offer is cheaper | Mapping source and winning-offer rule are mandatory |
| 8+ | An unmapped list is not sellable | Room-level mapping and a discovery-log routine are required |
The threshold in that table is this: from the fourth supplier onwards, mapping is not an improvement, it is a precondition. Past that point manual clean-up stops being something human effort can keep up with.
The canonical hotel ID: the idea of one true record
A supplier's hotel code is not an identity; it is a row number in that supplier's own catalogue. The same property carries four different codes across four sources. A canonical hotel identity is the parent record that binds all of those codes to one physical property. Once that record exists, the question "is this the same hotel?" never reaches a member of staff again.
The same property arrives from four sources with four different codes and four different spellings. The canonical identity reduces them to one card; the lowest offer goes on sale and the others are kept behind it for comparison.
The matching decision cannot be made by looking at a single field. Name spelling varies from supplier to supplier ("GRAND MARINA RESORT SPA" and "Hotel Grand Marina Resort and Spa" are the same property), coordinates sometimes point at the entrance and sometimes at the car park, and address formats differ by country. So the decision is made by evaluating a normalised name, coordinate proximity, address and postcode, and the star rating and property type together.
An accuracy rate is not a marketing line, it is a budget item
Mapping providers publish accuracy rates, and those rates look almost identical to each other. According to AltexSoft's overview, GIATA reports 99.998% and Vervotech reports 99.999% accuracy at hotel level. The same overview states that GIATA's database holds roughly 1.2 million properties and 124 million booking codes, while Gimmonix holds 1.9 million properties.
The real difference is not in the number but in how it is reached. Vervotech's guide states that rule-only systems plateau in the 90-95% band in well-covered markets, and that anything above 99.9% only scales with hybrid approaches combining rules, machine learning and human review. When you evaluate a source, the question is not "what percentage?" but "how do you reach that percentage, and in which market did you measure it?"
The cost of an error is concrete too. Based on a figure AltexSoft attributes to GIATA's marketing manager, an average hotel mapping error costs an OTA in Germany roughly EUR 1,500. That is the cost of correcting one incorrectly matched record and closing out the consequences it caused; it is not a per-booking cost.
Vervotech gives the booking-side equivalent separately: a 4% mapping error rate means 40 wrong room confirmations in every 1,000 bookings; at a mid-sized OTA handling 50,000 bookings a month, that is roughly 2,000 wrong room confirmations a month.
Do not multiply those two numbers — they are different units. But do rescale the second one to your own volume: at an agency doing 800 bookings a month, a 4% error rate produces roughly 32 wrong room confirmations a month. Each one is a complaint, a rebooking or a price difference. Calculate that number once; the debate about the return on a mapping investment ends there.
Five questions to ask when choosing a mapping source
- Coverage: what is the coverage rate in the destinations I sell? Do not accept a global average — ask for the figure for Crete, Sharm El Sheikh and the Algarve, or whichever three destinations carry your volume.
- Room level: do you map at hotel level only, or at room level too? Give me the accuracy figure for each separately.
- Update frequency: 2% of hotels change every year; how often is the catalogue refreshed and how am I notified of a change?
- Conflict resolution: if two records fall under the same identity, which one wins, who makes that call, and can it be reversed?
- Unmatched record report: can I get the codes that could not be matched as a list? If you cannot, you have no way of knowing how large your blind spot is.
The fifth is the one most often skipped and the most critical. Letting unmatched records fall into a discovery log that is reviewed weekly is the only practice that stops mapping quality from decaying over time.
The winning-offer rule: when the same hotel arrives at two prices
You have deduplicated; now you have to decide which of the two offers for the same hotel goes on sale. The common simplification is "lowest price wins". In most cases that is a correct and defensible default — but not always.
"Cheapest" is only meaningful if the two offers are selling the same thing. In the following situations the lowest price is the wrong decision:
- The two offers carry different meal plans. The gap between room only and bed and breakfast alone can be larger than the price gap.
- The two offers carry different cancellation policies. A non-refundable offer is naturally cheaper than a flexible one; putting them side by side and declaring the cheaper one the winner is not comparison, it is confusion.
- One of the prices arrives excluding taxes and fees. The offer that is more expensive in total looks cheaper in the list.
- The offer is on request; until confirmation arrives it is not actually sellable.
That is why the decision must not be single-criterion but sequential.
| Order | Criterion | Rule |
|---|---|---|
| 1 | Comparability | If meal plan and room type do not match, do not place them side by side |
| 2 | Real sellability | An on-request offer is not equal to an instantly confirmed one |
| 3 | Total cost | Compare the amount including taxes and fees |
| 4 | Cancellation flexibility | At equal price, the flexible policy wins |
The fourth line is not a preference, it is a risk decision: when two offers arrive at the same price, selling the one with the more flexible cancellation policy lowers the amount the agency will be left holding when a cancellation comes in. Turn that rule into written policy; left to individual discretion, the lowest figure on the screen wins every time at the moment of sale.
Content cross-filling: which field merges, which never does
Once the winning offer is set, a second opportunity appears. The supplier with the cheaper price is usually the poorer one on content: a short property description, few images, an incomplete facilities list. Moving the losing supplier's richer content into the empty fields of the winning offer directly improves sellability.
But the boundary of that merge is very clear, and most teams learn it for the first time through a complaint.
On the left, static facts about the property: these can be completed from the losing supplier. On the right, the contractual terms of the offer that is actually selling: these are never blended.
The distinction reduces to a single question: does this field belong to the property, or to the offer that is selling?
- Belongs to the property, may be merged: hotel name, address and coordinates, images, facilities, description text, star rating, theme tags, guest score. Whichever supplier this information comes from, it describes the same reality.
- Belongs to the offer, never merged: price, cancellation policy and the last free-cancellation date, meal plan code, room type and occupancy, availability, taxes and fees included in the price, rate plan conditions, items payable at the property.
The rule in one sentence: a card that reads its price from supplier A and its cancellation policy from supplier B tells the customer the wrong terms. When the customer says "it said refundable", there is nothing left to defend; the agency absorbs the difference. That is the one instruction to give whoever builds your content merge logic.
Room mapping: one level harder than hotel mapping
Assume you have solved hotel-level mapping. The real money is lost one level below, at room level. As GIATA notes in its own material, many companies go for hotel mapping first because duplicate properties are visible to the eye; but hotel mapping solves only part of the problem.
The size of that gap is best shown by one provider's own numbers. According to AltexSoft's overview, Vervotech reports 99.999% at hotel level and 95% at room level. Same company, same data, two different worlds.
The operational meaning is striking: at hotel level the error margin is one in a hundred thousand; at room level it is one in twenty. In other words, the room-level error margin is roughly 5,000 times the hotel-level one. If one room in every twenty is mismatched, your room-by-room price comparison is not statistically trustworthy.
Four different room names in the same hotel: "King Room With Park View", "Twin Room With Partial Bosphorus View". Under each room type there are two price rows — same room, different rate plan. In the panel on the right the cancellation policy and the meal plan are selected separately. (The interface language in this example is Turkish; the room names come from the supplier feed in English.) What mapping has to compare is not the room name, but all three of those together.
The cause is simple: the same room arrives from different suppliers as "Standard Room Sea View", "Sea View Double" or "Superior Double Sea View". Mapping requires bed type, view, bathroom configuration and amenities to be normalised separately — far more fine-grained work than property-level matching.
The applicable rule
If a room-level match cannot be established, the thing to do is not to guess but to withdraw the comparison:
If two offers for the same hotel do not match at room level, a side-by-side price comparison is not shown. They are shown as two separate cards, with the source supplier visible on each.
This rule blocks a false "cheaper" claim. Staff see both cards and make their own call; the system does not fake a certainty it does not have. In the short term the list looks less tidy; in the long term the complaint count falls.
Meal plan codes: RO, BB, HB, FB, AI, UAI
After price, the meal plan is the most misunderstood field in hotel sales — and suppliers do not send it as a standard code. It arrives as free text: "Bed and Breakfast", "Breakfast Included", "B/B", "Frühstück inklusive" — all the same thing.
The canonical set established in the industry has six codes.
The six canonical codes and the free-text equivalents suppliers use most often. If you cannot reduce incoming text to these six codes, both your meal plan filter and your price comparison will mislead.
The process to apply has three steps:
- Build a reduction dictionary. Keep a dictionary that maps each supplier's free text to one of the six codes. The dictionary must be per supplier; the same text can mean different things at two different suppliers.
- Do not silently discard the unmatched. Values with no entry in the dictionary must fall into the discovery log and be reviewed weekly. Assigning a default code and moving on comes back at the end of the month as an "I thought breakfast was included" complaint.
- Accept that equalising the code does not equalise the scope. Especially for UAI.
"Ultra all inclusive" is not a standard, it is a contract clause
UAI has no binding definition in the industry. Its scope is set by the contract with the property: at one hotel imported drinks are included, at another only local production; à la carte restaurant access may be unlimited at one property and once per stay at another.
The practical consequence: when you sell UAI, communicate that property's scope list, not the code. For your own contracted hotels, extract that list from the contract and write it into the product description. If your supplier hotels do not send a scope list, keep a "scope varies by property" warning visible on the sales screen.
When your own contracts join the list: allotment, stop-sale, release
The moment you put your own contracted hotels into the same search list, a new management load appears. In supplier inventory, availability was somebody else's problem; in your own contract it is yours.
Three concepts get confused with each other constantly because all three affect capacity. But they answer three different questions.
At the top, on an axis counting down to arrival: the allotment block, the release window and the rooms returning to the property. At the bottom, the daily capacity strip: days open for sale, days closed by stop-sale, and days that are quietly unsellable because no rate was entered.
- Allotment: the block of rooms you have the right to sell. Its question: how many can I sell?
- Stop-sale: closing sales on a given day. Its question: which day is closed?
- Release: the moment an unsold room returns to the property. Its question: by when?
The release window: industry range and negotiation target
According to DMC Quote's 2026 guide to hotel allotment contracts, the standard negotiated range is 14-21 days before arrival, with a negotiation target of 21-30 days. In Xotels' definition this period is called the "release period" or "cut-off date" and marks the end of the time the blocked rooms are held.
The balance here is simple: the longer the release period, the more of the unsold-room risk sits with the property; the shorter it is, the more sits with you. Ask for a long release at the start of the season; once you have proven you can sell, use it as leverage in the rate negotiation.
Soft, hard and free sale: same hotel, three different risks
The ranges given in the same guide separate the three models clearly.
| Model | Discount off rack | If unsold | When to choose it |
|---|---|---|---|
| Free sale | 5-15% | No obligation | New destination with uncertain demand |
| Soft allotment | 10-25% | Returns at release | Seasonal core product with known demand |
| Hard allotment | 20-35% | Paid whether sold or not | High-volume property with proven occupancy |
According to the same source, the typical deposit on hard allotment is 25-50% on confirmation, with a negotiation target of 25% deposit and 30-day payment terms. The balance is normally requested 14 days before arrival, with a target of 7 days. On volume tiers, discount ranges by annual room nights are given as 15% at 50-100 nights, 20% at 101-250, 25% at 251-500 and 30% above 500. The high season supplement is 30-50% as standard, with a negotiation target of a 25% cap or a flat seasonal rate.
Decision rule: only enter a hard allotment where you have realised occupancy from the same property last season. With no historical data, start in soft allotment's 10-25% band; taking on every unsold room for the sake of an extra 10-20% discount will write a loss far larger than that discount in the first weak season.
Days with no rate or no allocation: the silent revenue leak
In your own inventory the most expensive mistake is not a stop-sale but the gap nobody notices. A stop-sale is a deliberate decision; a day with no rate entered is a day on which nobody decided anything. Both are unsellable, but only one is intentional.
These days go unnoticed without a report, because they do not throw an error in the search — they simply return no result for that date. The customer goes to another hotel, and you assume nothing happened.
Applicable routine: before the season opens and once a week through the season, run a "days with missing rate or allocation" report. These reports have a practical limit: in the installation we work with, the scan window is capped at 92 days. If your season runs longer than three months, the report must be run in slices rather than in one pass — otherwise the last month of the season is never scanned, and precisely your highest-rated days stay in the blind spot.
Calculate the size of the loss once. A hypothetical but realistic example: if a block of 6 rooms has 2 days with no rate, 12 room nights are quietly unsellable. At an average of EUR 150 a night, that means EUR 1,800 of selling rights never reached the shop window. Rebuild the figure with your own room count and average rate; the cost of a weekly reporting habit disappears next to it.
One slow supplier should not stall the whole search
In a search that queries eight sources at once, the slowest source does not have to set the pace for the entire search. Two design decisions prevent that.
Progressive result streaming: results are listed as they arrive, not when all of them have arrived. When the slow source answers, its results are appended. Staff see the first results within seconds.
Circuit breaker: a source that keeps failing or timing out is temporarily disabled and retried at set intervals. That way one broken supplier does not reproduce the same delay on every single search.
A similar cadence is needed on status synchronisation. In the installation we work with, booking status synchronisation runs on a two-minute loop with a per-provider circuit breaker. The constraint to be aware of is this: status querying is not available at every supplier. Automatic tracking only works on sources that support a status query; on the others, booking status is managed by a timeout sweep.
Your operational rule follows from that: write down, as a list, which of your suppliers have no automatic status tracking and define a manual checkpoint for bookings on those sources. If you do not produce that list at the start, the first time you notice it will be the moment a customer arrives at a property and is told there is no booking.
On-request hotels: on the list, but not sold
On-request hotels are offers that look sellable but carry no guaranteed capacity. The booking is not final until confirmation comes from the property. Operationally that is not a problem — it becomes one when it is explained badly to the customer.
What closes the risk is not software but a standard piece of text. The template given to the customer at the point of sale must contain these three facts:
"This property is confirmed on request. Your booking is currently in pre-request status and will be finalised on the property's confirmation. Confirmation usually takes [X hours]. If confirmation does not arrive, no charge is taken and alternative options will be sent to you."
The operational rule that goes with it: when you sell an on-request offer, identify and hold an instantly confirmed alternative for the same dates. When confirmation comes back negative, the customer should hear "here is another option", not "we couldn't find it". That single habit converts a meaningful share of on-request cancellations into sales.
Season-opening checklist
Checks that can be completed in one sitting before you open the season:
- ☐ Unmatched hotel code report pulled for every connected supplier; discovery log cleared.
- ☐ Duplicate hotel scan run across my top 20 destinations; remaining duplicates merged by hand.
- ☐ Side-by-side comparison switched off for offers that do not match at room level.
- ☐ Meal plan reduction dictionary reviewed for every supplier; unmatched free text coded.
- ☐ Scope lists for properties sold as UAI extracted from the contract and written into the product description.
- ☐ "Missing rate / missing allocation" report run on own contracted hotels, sliced if the season exceeds 92 days.
- ☐ Release period confirmed in writing in every contract; anything under 14 days taken into negotiation.
- ☐ Last season's occupancy data filed for every property entered into hard allotment.
- ☐ Stop-sale days mutually confirmed with the property (days closed by the property listed separately from days closed by you).
- ☐ Suppliers without automatic status tracking listed; manual checkpoint and owner assigned.
- ☐ Customer notification template and hold-an-alternative rule communicated to the team for on-request properties.
- ☐ Winning-offer decision order turned into written policy and made visible on the sales screen.
What to ask, line by line, when choosing software
No system that manages multi-supplier inventory does everything. The capabilities below are frequently assumed but missing in most installations; when you take a proposal, ask about each one separately and see the "yes" on screen:
- Is there a channel manager integration? Can you push the allocation and rates of your own inventory to an external channel manager?
- Is there inventory distribution outbound? Can you offer your own contracted inventory to another buyer as XML/API?
- Is there bulk import? Can you upload room, rate and allocation data from a file (Excel/CSV), or is everything keyed in on screen?
- Is the contract document stored? Can you attach the contract PDF to the hotel record and find it later?
- Is there a group/block booking module on the hotel side? The hotel equivalent of the block logic used on the flight side does not exist in most systems.
- Can ancillary services be sold on a booking? Can items like transfers, tours and extras be added to a hotel booking?
- Is there a partial payment / deposit flow? Can you take a deposit on an accommodation booking and collect the balance before arrival?
- Which suppliers does automatic status tracking work on? Do not accept "all of them" — ask for the list.
The answer to all eight of these can be "no" and the system can still be the right system for you — as long as you know the answer before you buy and write that work into your plan as a manual process. The gap that appears when the question was never asked is the most expensive gap to close mid-season.
Sources
- Vervotech — What is Hotel Mapping? The 2026 Guide for OTAs, Bedbanks, and Metasearch: https://vervotech.com/blog/what-is-hotel-mapping-guide/
- AltexSoft — Hotel Mapping Tools: How GIATA, Gimmonix, Vervotech, and Other Solutions Work: https://www.altexsoft.com/blog/hotel-mapping-tools-how-giata-gimmonix-databindr-and-other-solutions-work/
- GIATA — Hotel Mapping and Room Mapping: https://www.giata.com/hotel-mapping-room-mapping-travel-bookings/
- DMC Quote — Hotel Allotment Contracts: Negotiating Terms: https://dmcquote.com/blog/post/hotel-allotment-contracts-negotiating-terms
- Xotels Glossary — Allotment: https://www.xotels.com/en/glossary/allotment
Frequently Asked Questions
Why does the same hotel arrive from several suppliers under different names?
Every supplier keeps its own catalogue by its own rules; it may write the hotel name in capitals, abbreviate it, or prefix it with "Hotel". Address formats vary by country and by source, and coordinates sometimes point at the entrance and sometimes at the car park. That is why the same physical property looks like four different records across four sources. The fix is to bind all of those codes to a single canonical hotel identity.
What is the difference between hotel mapping and room mapping?
Hotel mapping establishes that different suppliers' codes belong to the same physical property. Room mapping matches the room types inside that property: is "Sea View Double" the same room as "Standard Room Sea View"? The second is markedly harder; according to figures compiled by AltexSoft, one provider reports 99.999% accuracy at hotel level and 95% at room level. If the room match does not hold, a price comparison loses its meaning.
What is the difference between allotment and free sale?
An allotment is a block of rooms the property has set aside for you and that you hold the right to sell. Free sale has no reserved capacity; you sell at a contracted rate but availability is confirmed with the property on every booking request. According to DMC Quote's 2026 guide, free sale is priced 5-15% below rack, soft allotment 10-25% and hard allotment 20-35% below — the bigger the discount, the bigger the risk you carry.
How long should the release period be?
According to the same DMC Quote guide, industry practice is 14-21 days before arrival, with a negotiation target of 21-30 days. The rule is this: the longer the release period, the more of the unsold-room risk sits with the property; the shorter it is, the more sits with you. Ask for a long release at the start of the season and use your proven sales performance as leverage later. Review every contract under 14 days separately.
Is a stop-sale the same as zeroing out the allocation?
The operational outcome is similar, the record is not. A stop-sale explicitly closes that day for sale and keeps the reason traceable. Zeroing the allocation erases the difference between "sold out" and "I closed it". That distinction matters in reporting and in reconciliation with the property: use stop-sale for deliberate closures and leave allocation exhausted by sales alone.
What do RO, BB, HB, FB, AI and UAI mean?
Respectively: room only; bed and breakfast; half board (breakfast plus one main meal); full board (three meals, drinks usually excluded); all inclusive (meals plus the drinks specified in the contract); and ultra all inclusive (an extended drinks/services scope). UAI has no binding industry definition; its scope is set by the property contract, which is why two properties can sell different things under the same code.
If one supplier does not respond, will my search results be incomplete?
Not if progressive result streaming is in place: results are appended as they arrive, and the slow source's answer shows up later. For sources that keep failing, a circuit breaker temporarily disables them and retries at set intervals. The permanent fix is monitoring: track weekly which supplier times out how often, because this is inventory quietly shrinking.
Can I trust a mapping provider's accuracy rate?
Look less at the number and more at how it was obtained. According to Vervotech's 2026 guide, rule-only systems plateau in the 90-95% band in well-covered markets; above 99.9% scales only with approaches where rules, machine learning and human review work together. Ask for the figure for the destinations you actually sell rather than a global average, and always ask whether you are given the unmatched-record report.
Five things you can do tomorrow morning
- Count the duplicates. Search your three highest-volume destinations and count by hand how many times the same hotel is listed. That single number is what starts the conversation about a mapping investment.
- Calculate your own error cost. Multiply your monthly booking count by 4%. The result is a realistic estimate of the wrong room confirmations you will live with every month if mapping quality does not improve.
- Write down the merge rule. A one-page note: which fields are cross-filled and which never are. Price, cancellation policy, meal plan and room occupancy belong on the "never" list. Hand that note to whoever builds your content merging.
- Run the missing-days report. List the days with no rate or no allocation on your own contracted hotels. If your season exceeds 92 days, pull the report in slices; confirm your highest-rated weeks are not sitting in the blind spot.
- Put every release period in one table. For each contract, write the property name, the release day and the deposit percentage side by side. Flag anything under 14 days and anything at 50% deposit; those flagged rows are next season's negotiation agenda.