# Contracts A **contract** is the commercial agreement that backs a property in your catalog. It says who you are dealing with, what inventory the agreement covers, what pricing applies, what policies travel with it, and how long it runs. Rate plans are the public face of contracts; the contract itself holds the terms. {% hint style="info" %} **Rate plans are the face; contracts are the terms.** When a number on a booking looks wrong, the contract is where you go — not the rate plan card. {% endhint %} Concrete example: you sign a one-year contract with Hotel Sunrise covering 20 Standard rooms and 10 Deluxe rooms, May–October, at a net rate of 120 EUR/night for Standard and 160 EUR/night for Deluxe, with a 25% markup, free cancellation up to 24 hours before check-in, and a 7-day release period on pre-allocated allotment. That single contract row backs every rate plan you publish for the property — *Best Available Rate*, *Non-Refundable Europe*, *Member Saver*, *Half Board* — and is the row you change when terms shift mid-season. ## What a contract holds | Element | What it carries | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Counterparty** | The supplier, partner agency, or distributor on the other side. | | **Scope** | Which properties, rooms, rate plans the contract covers. | | **Validity** | Start date, end date, renewal terms, termination notice. | | **Pricing model** | Net rate + markup, or commission on gross. | | **Currency** | The currency the contract is denominated in. | | **Allotments** | Inventory pre-allocated to you — a fixed number of rooms the supplier holds for your sales channels per room type and date range (e.g. 10 Deluxe rooms reserved for you every night in July). | | **Release period** | The cut-off before check-in at which any unsold allotment returns to the supplier (e.g. *7 days*: rooms held for you up to 7 days before arrival; on day 7 unsold rooms go back into the supplier's general pool). | | **Cancellation policy** | The refund and modification terms travellers see. | | **Child & age policies** | How children are priced, what counts as a free under-N age. | | **Payment terms** | Direct payment, virtual card, deposit, deferred — when, how, in which currency. | | **Markets** | Where the inventory can be sold (per-country, per-region, per-channel). | Every field has implications elsewhere on the platform. A change to the markup propagates to derived rates; a change to the cancellation policy updates rate plans; a change to the allotment changes inventory. ## How contracts and rate plans relate A contract typically backs several rate plans: * *Best Available Rate, refundable* — public retail, full markup. For example, 180 EUR/night with free cancellation up to 24 hours before check-in. * *Non-Refundable Europe* — same contract, tighter cancellation, slightly lower markup. Same room at 162 EUR/night (10% off), locked at booking, sold only into European markets. * *Member Saver* — same contract, member-only audience, additional discount. 153 EUR/night for signed-in loyalty members, refundable. All three sit on top of one contract. Adjusting the contract's underlying terms updates all three; adjusting one rate plan does not change the other two. For multi-source properties (a property that arrives from more than one channel), each source is its own contract. The same property in your catalog can be backed by, say, a direct contract for some date ranges and a channel-manager contract for others. The platform tracks which contract each rate cell traces to. ## Net rate vs. commission Two pricing models coexist: * **Net rate + markup.** The contract gives you a net rate; you add your markup; the traveller pays gross. Typical for bedbank suppliers and some direct contracts. * **Commission on gross.** The contract publishes a gross rate; you take a commission off the top. Typical for hotel-direct and some channel agreements. Which model applies depends on the contract type — you do not pick per-booking. The pricing engine reads the contract type and applies the right calculation automatically. ## Allotments and release periods For contracts that pre-allocate inventory:
Allotment held → release period fires → unsold returns to supplier

Pre-allocated rooms stay yours until the release-period cut-off; whatever did not sell goes back to the supplier's general pool on that day.

Worked example. Your contract with Hotel Sunrise carries an **allotment** of 10 Deluxe rooms per night for July, with a **release period** of 7 days. On July 1 you have all 10 rooms held for sale. By July 18 you have sold 4 of the 10 rooms for the night of July 25. On July 18 (7 days before arrival) the release period fires: the 6 unsold rooms for July 25 go back to the supplier's general pool — the supplier can now sell them through other channels (their direct site, OTAs, walk-ins). You keep the 4 confirmed bookings on contract terms; you simply lose first-call on what was unsold. The console's contract-detail page shows current allotment health for any date in the contract's validity window — sold-versus-held by night, with the release-period date highlighted. When inventory is running thin you see it before the channel does, and you can ask Adragent to *"flag every contract where the July allotment is more than 70% sold for any night."* ## Multi-property contracts Many contracts span multiple properties at once: * A chain hotel's master contract covers all the chain's properties under shared terms. * A bedbank supplier feed contract covers every property that bedbank distributes (you pull the catalog wholesale). * A B2B reseller's distribution contract covers every property you publish to them. The contract surface lets you scope at the contract level (properties A, B, C) or at the property level (override term X for property B). Defaults flow down; overrides are explicit. ## Contract lifecycle
Draft → For signing → Active → Amended → Expiring → Expired

Contracts move through a small set of states. Each transition is recorded with the operator who triggered it.

| State | What it means | | --------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Draft** | The contract is being authored; not yet shared with the counterparty. | | **For signing** | Sent to the counterparty for e-signature; tracked through [E-signature](/console/contracts-and-onboarding/e-signature.md). | | **Active** | Both sides have signed; rate plans, allotments, distribution all flow from it. | | **Amended** | Active with changes since the original — the amendments are part of the contract record. | | **Expiring** | Within the renewal-notice window; the platform surfaces it for action. | | **Expired** | Past validity. Existing bookings stay valid; no new bookings under the contract. | You move contracts through these states from the contract page; every transition is recorded. ## When a contract changes Contracts are not static. Mid-season, a supplier might: * Adjust net rates for the next quarter. * Change cancellation policy. * Alter allotments for specific date ranges. * Add or remove markets. The contract surface tracks **versions** — each amendment has its own validity window, and the contract record carries the chain. Bookings made under the old version keep its terms; new bookings get the current version. This is what makes "*we changed our cancellation policy on June 1 — what bookings does that affect?*" a single query: every booking returned was made before June 1 under the looser policy, every booking after was made under the new one, and the answer holds up in a dispute. ## Per-channel contract exposure A contract may cover several channels with different terms: * The same supplier rate goes to direct retail with full markup, to a B2B partner with a lower margin, and to metasearch with a markup that wins price-display competitively. * The same property can be off-limits to some channels (sales-staff only, no metasearch exposure). The contract holds the terms; per-channel exposure decides what surfaces where. See [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md). ## Adragent and contracts Common phrases that map to Adragent contract operations: * *"Show me every contract expiring in the next 30 days."* * *"Increase the markup on the new Antalya supplier contract by 2 percentage points."* * *"Find every contract where the cancellation policy is more lenient than our standard for that property class."* * *"Apply the new bedbank pricing template to every contract we hold with bedbank suppliers."* Read operations return immediately; writes preview before applying. ## Where to next * **The end-to-end onboarding flow** → [Onboarding flow](/console/contracts-and-onboarding/onboarding-flow.md) * **How contracts get signed and stored** → [E-signature](/console/contracts-and-onboarding/e-signature.md) * **The rate plans contracts back** → [Rate plans](/console/pricing-and-availability/rate-plans.md) * **The pricing engine that reads contract terms** → [Pricing engine](/console/pricing-and-availability/pricing-engine.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://adrasis.gitbook.io/console/contracts-and-onboarding/contracts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.