> For the complete documentation index, see [llms.txt](https://adrasis.gitbook.io/console/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://adrasis.gitbook.io/console/contracts-and-onboarding/contracts.md). # 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 a statically managed property, publish the contract into a plan with the same currency as its quoted price. A net plan receives the contract's buy amount and buy currency; a commissionable plan receives its selling amount and selling currency. The calendar keeps one quoted price for each plan. *Hotel Sunrise can keep EUR as its property default and maintain separate EUR and TRY contract plans.* Choose a compatible existing plan or create one in the selected contract currency. This authors separate prices; publishing does not convert them. See [Plan currency and calendar entry](/console/pricing-and-availability/rate-plans.md#choose-the-plan-currency). ## 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. The commercial model belongs to the selected rate plan. It determines which contract amount is published and how that quoted price is used; it is not selected separately for each booking. ## 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 Adrasis AI Operator 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 supply contract covers every property you consume from that bedbank (you pull the catalog wholesale). * A B2B partner agency's distribution contract covers every property you publish to them. The contract page 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. ## Loading a contract from a spreadsheet Most contracts arrive as a supplier's rate spreadsheet. Rather than re-key it, you upload the file and a guided wizard turns it into live pricing — with a full preview and a hard correctness check before anything applies. {% stepper %} {% step %} ### Upload and parse Drag the supplier's rate file in. The wizard reads its structure — period bands, the rate grid, allotment, child pricing. Free-text terms (*"no-show: first night"*) are pulled out for review. {% endstep %} {% step %} ### Three independent checks The wizard checks the file three ways: **structural** — are the periods, occupancy and child brackets coherent; **cross-read** — does an independent reading of the file agree with the parsed grid; and **math** — when the system recomputes a price from the contract terms, does it match the contract's own number. {% endstep %} {% step %} ### Preview the full matrix You see every cell — period by room by occupancy — with your contract value next to the recomputed value and a clear match marker on each. For an amendment, the matrix overlays the current live rates so you see *old → new* and the delta. You can stop here without applying. {% endstep %} {% step %} ### Approve and go live On approval, the system projects the contract into live pricing — rate buckets, occupancy curves, child rules, promotions, allotment and release periods — runs a final integrity check, and only then writes it live. {% endstep %} {% endstepper %} {% hint style="warning" %} **The math check is a hard gate.** If a recomputed price does not match the contract — *the system computed 120 EUR but the contract says 115 EUR* — the import stops. You correct the source and retry; a contract that does not reconcile never goes live. {% endhint %} ### Room category suggestions Supplier spreadsheets name rooms in their own words — *"Superior Garden View"*, *"Twin Eco"*. Before apply, the AI Operator proposes how each maps to your catalog categories (*Superior Garden View → Deluxe*). Where its proposal and the catalog agree, it pre-fills; where they diverge, you decide. The final category is settled before the contract goes live — nothing is guessed silently. ## 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 page 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). ## Market validity Supplier contracts are often negotiated for specific sales markets — a season contract may state that its prices apply only to bookings originating from a named group of countries. Adrasis captures this restriction at upload: the extracted draft surfaces the sheet's market line, the operator binds it to one of the organization's source markets, and from the moment the contract goes live its rate plan is only offered to bookers inside that market. Everyone else simply never sees those prices. * A plan with no market binding sells everywhere — nothing changes for contracts without a restriction. * Widening a plan into an additional market later is a single edit on the rate plan; the original negotiated market keeps its contract reference, so commercial widening stays visible and reversible. * Where a supplier prices markets differently, each market's prices load as their own rate plan, each valid only in its market. ## AI Operator and contracts Common phrases that map to the AI Operator 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 This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://adrasis.gitbook.io/console/contracts-and-onboarding/contracts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.