When a negotiated hotel rate is marked "loaded" in a global distribution system, that is a claim by the person who keyed it in. It is not proof that an agent will actually pull the right rate, in the right field, under the right identity, on the dates it should be bookable. Those two things are not the same, and the gap between them is where corporate travel programs quietly lose money.
The same verification technology that powers trust on the ItWhip and Choé platform also runs a rate-integrity engine for negotiated hotel rates, available to any hotel or travel program through Choe Cloud. The core idea is simple to say and hard to do: loaded is not verified. This is how it works, end to end.
Loaded versus verified
Loaded is the loader's claim: a rate code was entered into the chain. Verified is the engine's proof: the negotiated rate actually returns to an agent, in the correct field, under an authorized identity, at the negotiated value, and is bookable on the dates it should be.
Most loading errors are silent. The code looks entered, but it returns under the wrong field, or at a different value, or a property that is not even in the program answers, or the rate is closed on a peak night it was supposed to protect. Each of those is lost revenue or a failed corporate audit. The platform turns every one of them into a named, evidenced catch.
It starts with the RLI
Every audit begins with a Rate Loading Instruction, the RLI: the document a program or client sends that says exactly which rate goes where. It arrives in any format, a branded table, a GBTA master form, an email, or a paste. An extraction step turns it into structured rows, one per property, GDS, and room type, mapping any terminology to canonical fields without inventing codes. Anything low-confidence routes to a human.
Before anyone loads a thing, deterministic screening checks the instruction against the client registry: the right GDS for the client, the right code in the right field, required fields present, room types that resolve, Last Room Availability where the program demands it. A bad instruction is caught here, not after it is loaded.
Then it proves the load
After loading, a loader pastes the live agent-view screen, the same thing an agent would see. The engine canonicalizes each returned row, matches it against what the registry expected, and records a discrepancy for anything that does not line up: the code, the field it sits in, the value, the room type, the identity (name, pseudo city, office ID, chain code), and whether anything is actually bookable.
Two dimensions are kept separate on purpose. Load correctness, meaning the right code in the right place at the right value, always fails when it is wrong. Bookability, meaning open or closed and why, only grades a load that is otherwise correct. A closed rate never hides a wrong code, and a correctly loaded rate that is merely yield-closed is not called a failure.
Every discrepancy gets a name
The engine does not just say "something is off." It names the failure mode and explains it in plain language, with the dollars per night at risk where a rate value is involved. A rate loaded at $189.00 when the program negotiated $159.00 is named as a wrong value with $30.00 per night at risk. A code in the wrong field that never returns to the agent. A property loading a rate it has no business loading. A blackout night left bookable when the close-out should have protected it. A rate whose effective period has ended with no renewal behind it.
What a single wrong rate costs
Consider one corporate rate loaded $30.00 per night above the value the program negotiated. A team booking a few hundred room nights a month at that property is overpaying thousands of dollars a year on a single mistake, on a single property, in a single GDS. Multiply that across a portfolio of properties, three or four GDS systems, and the seasonal reloads that quietly drop a code or a date range, and the leak is real money that never shows up as a line item. It just looks like the rate.
The audit makes that leak visible before the invoices land. Each catch carries the property, the GDS, the exact discrepancy, and the negotiated value at risk per night, so a revenue or procurement team can fix the highest-dollar items first instead of guessing.
Honest about what it cannot see
A platform that audits rate integrity is only as trustworthy as its boundaries. Some restrictions, like Last Room Availability and rate parity, are not printed on the agent-view screen at all, so the engine never guesses them: a named person or a system record attests whether a required restriction was carried onto the load, and the strength of that evidence decides whether it fails or routes to a human. Cancellation, deposit, advance-purchase, and minimum-stay terms live in the rate rules and the reservation system, not the screen, so they are not claimed as verified. And the platform never invents a realized-loss figure: it leads with the count of rates at risk and the negotiated value at risk per night, clearly marked as exposure, not money already lost.
A request portal that cannot go off-program
Clients submit rate requests from a form where every field is chosen from their own authorized program, so an off-program request is structurally impossible. An identical re-request flows straight through; a changed or new one is flagged for human review, and a changed blackout set is treated as inherently suspicious, because contract terms do not normally amend mid-program. The actual load and commit always stay a credential-gated human step.
Why it matters
A negotiated rate that is loaded wrong does not announce itself. It books at the wrong value for months, or never returns to the agent at all, and the loss only surfaces in an annual audit, if then. Proving the load, naming every discrepancy, and putting the value at risk on the board turns a silent leak into a fixable list. That is the same principle behind every part of the ItWhip and Choe platform: do not trust that it was done, prove it.
Two sides of one platform
Rate Verification is one half of the picture. Choe Cloud proves that the rates a hotel or program negotiated are actually loaded and bookable, per the RLI. Choé, the AI booking assistant behind ItWhip, is the other half: a traveler just asks, and Choé searches, books, and plans the whole trip across cars, hotels, and flights. Same principle on both sides: do not assume it works, prove it and do it.
Read the full Rate Verification documentation at choe.cloud/rate-verification, or meet Choé at choe.app.