STR Co-Hosting Agreements: Fee Models, Responsibilities, Liability

TL;DR: Co-hosting agreements exist because the platform contract sits with the listing owner while operational authority sits with the co-host. The structural choices that matter are the fee model (percentage of revenue versus flat per-door versus hybrid), the responsibility split across four operational buckets, and the liability allocation for damage, refunds, and platform sanctions. The patterns that backfire are predictable, and the protections worth negotiating are the ones operators only think about after a dispute.

Why the agreement matters when the platform already gives permissions

Airbnb’s co-host system grants operational permissions through three tiers: full access, calendar and messaging, and calendar only. Per Airbnb’s help article on adding a co-host, the owner can adjust those permissions at any time and the co-host’s access can be revoked immediately. The same article states directly: “As the listing owner, you’re responsible for your co-hosts, even those added by full-access co-hosts.”

That sentence is the structural reason a written agreement exists. The platform contract for the listing, the payout setup, and the legal relationship with Airbnb sit with the listing owner regardless of who runs the daily operation. If a guest sues over an injury, if a payout dispute hits the listing, if a regulatory authority issues a notice, the owner is the named party. The co-host carries operational authority but no platform standing.

This creates two parallel risk profiles. The owner is exposed to operational decisions made by someone whose permissions can be set but whose judgement cannot. The co-host is exposed to a business they have built around a listing that can be removed from their portfolio with one permission revocation. A written agreement is what aligns those two risk profiles into terms both sides can live with.

The mistake at the start of most co-hosting relationships is treating the Airbnb permission grant as the agreement. The permission grant is the execution layer. The agreement is what governs the relationship around it: how fees are calculated, when either side can exit, what happens to guest data and reviews on termination, and who pays when something goes wrong.

The four fee models, and the cost stack each one ignores

Co-hosting fees are usually structured one of four ways. Each has a profile of who benefits, and each has a cost component that the headline number does not capture.

Percentage of gross booking revenue. The co-host receives a percentage of the gross nightly revenue. Industry-observed ranges for short-term rental management run 15 to 30 percent of gross, with full-service portfolio management commonly between 20 and 25 percent. This model is the cleanest to operate and the one most STR-specific agreements default to. The catch is “gross of what.” If “gross” means before OTA commissions, the co-host’s fee is calculated on revenue the listing never actually receives. The honest version writes the calculation against “net of platform fees and applicable taxes, ” then defines each term.

Percentage of net. The co-host receives a percentage after defined deductions: platform fees, cleaning fees passed through to cleaners, taxes, and any pre-agreed pass-throughs. This is more accurate but harder to audit. Every line item in the deduction list is a place for ambiguity. The clause that resolves this is a quarterly statement of revenue and deductions with source links to the platform payout reports.

Flat per-door monthly fee. The co-host receives a fixed amount per managed listing per month, regardless of occupancy. This works in markets with predictable demand and is operationally simple, but it transfers occupancy risk to the co-host (a slow quarter for the owner is a profit quarter for the co-host) or to the owner (a peak quarter for the owner is a margin loss for the co-host). The model is rare in pure form and usually appears as a floor under a percentage structure.

Hybrid: base fee plus percentage of revenue above a threshold. A flat per-door base ensures the co-host’s labor is covered in slow periods, with an upside share above a defined revenue floor. This aligns incentives well at scale but adds complexity. The threshold definition is where this model breaks: indexed to prior-year revenue, to a market benchmark, or to a fixed dollar figure, each option has a different long-term outcome.

flowchart TD
    A[Choose a fee model] --> B{Is ADR stable<br/>across seasons?}
    B -- Yes --> C{Portfolio size<br/>and scope?}
    B -- No --> D[Percentage of gross<br/>or percentage of net]
    C -- 1 to 5 doors, full service --> D
    C -- 5+ doors, predictable demand --> E[Flat per-door<br/>or hybrid with floor]
    D --> F{Can both sides audit<br/>the deductions list?}
    F -- Yes --> G[Percentage of net]
    F -- No --> H[Percentage of gross<br/>net of platform fees only]
    E --> I{Is occupancy risk<br/>borne by co-host?}
    I -- Yes --> J[Pure flat per-door]
    I -- No --> K[Hybrid: base + share<br/>above revenue floor]

The cost stack the headline percentage ignores is real. A 20 percent co-host fee on a property generating $60,000 of net booking revenue is $12,000. The remaining $48,000 still pays cleaning labor (not cleaning fees passed to guests, but the operational layer), maintenance, supplies, software stack (the PMS, channel manager, and adjacent tools the co-host runs), insurance, and the owner’s mortgage and operating costs. A workable fee structure prices the co-host’s actual operational cost plus margin, not the residual the owner is willing to part with.

The four responsibility buckets and where they get blurred

Every co-hosting agreement allocates responsibilities across four operational buckets. The agreements that hold up under stress define each bucket explicitly, including who pays for what.

Guest operations. Messaging, booking acceptance, check-in instructions, in-stay support, review response, dispute handling. This is the bucket co-hosts almost always own. The clarifying clauses worth writing: response time service-level agreement (commonly under one hour during stay hours), escalation path for safety incidents, and authority limits (the co-host’s refund authorization ceiling without owner approval).

Physical operations. Cleaning coordination, turnover quality, maintenance dispatch, supplies, inspection. This bucket is split more often than the others. A common pattern: the co-host coordinates and quality-controls, the owner pays the cleaning labor and supplies directly. Another pattern: the co-host pays everything and the percentage is sized accordingly. Either is workable. What is not workable is leaving it undefined, because the gray zone (who pays when a missing supply triggers a guest refund) becomes a dispute every quarter.

Business operations. Pricing, channel distribution, listing optimization, OTA relationship management, performance reporting. The co-host usually owns this, but the owner often retains pricing approval rights at the floor (no nights sold below $X) or at strategic moments (peak event weekends, marathon weekends). The owner approval clause is reasonable when documented; when undocumented it triggers conflict every event season.

Financial operations. Payout receipt, accounting, tax filing, reconciliation. The co-host can receive payouts directly through Airbnb’s co-host payout setup, or the owner can receive payouts and remit to the co-host on a defined schedule. Each has tax implications: direct co-host payouts make the platform issue a 1099 to the co-host on their share; owner-routed payouts make the entire revenue pass through the owner’s books with the co-host fee as an expense. The structure should be chosen with a tax professional, not as a default.

The buckets that get blurred are not random. Physical operations and financial operations are the two where ambiguity costs the most over time. A 25-door portfolio with undefined supply-replacement responsibility generates one dispute per cleaner per quarter. A portfolio with undefined payout flow generates a tax-time discovery that one or both parties did not expect.

Liability allocation: damage, refunds, and platform sanctions

The liability section of a co-hosting agreement is short, but it is the section that matters most when something goes wrong. Three categories warrant explicit treatment.

Damage to the property. Damage claims from guests are routed through Airbnb’s guest damage protection or through the listing’s underlying insurance. Most of the conversation belongs in the underlying insurance review, covered in the STR insurance coverage gaps guide. The co-hosting agreement clause defines who handles the claim filing (commonly the co-host as operator), who carries the deductible (commonly the owner), and what happens when a claim is denied (the default is the owner absorbs, but operator-level negligence carrying liability to the co-host is the exception worth defining).

Guest refunds and chargebacks. When a refund is issued (cancellation, complaint, payout dispute), the question is whose share is reduced. The clean answer is proportional: if the co-host receives 20 percent of gross, the co-host’s share of the refund is 20 percent. The unclean answer (the owner absorbs all refunds because they hold the listing) destroys the co-host’s incentive to negotiate refunds firmly with guests. Proportional is the workable default.

Platform sanctions and listing suspensions. If Airbnb suspends the listing for a co-host error (a delisted photo, a policy violation, a discriminatory message reported by a guest), the owner is the one notified and the one whose Superhost status or account standing is affected. The agreement clause that addresses this defines what the co-host warrants (compliance with platform policy, no off-platform booking solicitation, no fee circumvention) and what happens to fees during a suspension period (commonly suspended fee accrual until reinstatement or termination).

The clause format that works for all three: a defined-term list, an allocation rule per term, and a cap on the co-host’s financial exposure for non-fraud incidents. Without the cap, the co-host’s downside is unbounded. Without the carve-out for fraud or gross negligence, the owner is buying coverage they should not provide.

Termination, exit, and the ownership of intangibles

Termination is the section both sides skip and then need. Three terms govern the exit.

Notice period for termination without cause. Thirty days minimum for limited-scope co-hosting (messaging only, calendar only), 60 days for full-service management, 90 days at the portfolio scale of multiple properties. The notice period is not generosity; it is the time the co-host needs to wind down or the owner needs to transition without disrupting confirmed bookings.

Immediate termination for cause. A defined list: fraud, gross negligence, undisclosed conflict of interest, repeated guest-safety incidents, platform terms breach. Each term should be a defined behavior, not a subjective standard. “Material breach” without definition becomes a litigation question. A defined list becomes an audit question.

Ownership of intangibles on termination. The reviews on the listing belong to the listing. The guest data captured through the platform belongs to the platform, with downstream rights defined by the platform’s terms. The off-platform data (guest emails captured for direct booking, review-request sequences, the operational SOPs the co-host built) is the contested category. The workable default: data captured through the platform stays with the listing, data captured through off-platform direct-booking efforts is co-owned for one year post-termination, and operational SOPs are owned by whoever drafted them with a perpetual license to the other party.

The intangibles clause is where the largest dollar disputes happen. A co-host who built a 10,000-contact direct-booking list across managed properties has built an asset. The owner can argue the asset was built using the owner’s listings; the co-host can argue the asset reflects the co-host’s marketing labor. Without a written allocation, the default is a dispute. With one, it is a planned transition.

Three patterns that work, three that backfire

Patterns that hold up across multiple portfolios and multiple termination cycles share three features. They define fees against a single, auditable revenue concept. They split responsibilities by operational bucket with explicit payment flow. They include both an exit notice and a defined-behavior cause list.

The patterns that backfire share three different features.

The verbal agreement. Operators take on managed doors based on a handshake and the Airbnb permission flip. This works until it does not. The first guest complaint that triggers a refund question is the first dispute. The first slow quarter is the first fee discussion. The first time the owner asks for the listing back is the first lawyer call. The cost of writing a basic agreement (a few hundred dollars at most for a localized template review) is lower than the cost of one dispute.

The percentage of an undefined “gross.” The agreement reads “20 percent of gross revenue” with no further definition. Six months in, the co-host’s accounting and the owner’s accounting do not match, and neither party can reconstruct the intent from the contract language. The fix is to define every term against a source: “gross revenue means total guest payment receipts as reported on the listing payout statement, net of platform service fees and applicable taxes withheld at the platform level.”

Asymmetric termination. The owner can terminate at any time with no notice (because they hold the listing), but the co-host has a 90-day notice obligation (because the owner needs transition time). This is a sign the co-host did not negotiate. The workable asymmetry runs the other way for limited scope (the co-host can exit faster than the owner can replace operationally), and is symmetric for full-service portfolios.

What the platforms actually let you do

The platform layer constrains some of these choices. Airbnb’s co-host system has the structured permission tiers and the co-host payout split feature documented in Airbnb’s help center, and the platform-side relationship is governed by the Co-Host Additional Terms of Service that the owner accepts when adding a co-host. Vrbo and Booking.com handle co-hosts through user roles on the host account rather than a formal co-host program, which means the agreement carries more weight (there is less platform structure to fall back on).

For portfolios distributed across multiple platforms, the agreement should not assume the Airbnb co-host structure applies elsewhere. The OTA permission model differs by platform, and the fee routing options differ. A co-host running 12 properties across Airbnb, Vrbo, and Booking will have three different operational permission patterns, three different payout flows, and one written agreement that has to cover all three.

The PMS layer is where the platform differences are operationally managed (unified inbox, centralized calendar, cross-channel reporting), and the agreement should reference the PMS access scope as well. A co-host with full PMS access has more operational authority than the Airbnb permission tier suggests, and the agreement should track that.

What to do this week

Three actions worth taking before the next co-hosting conversation or renewal.

1. Write down the operational reality, even if there is no written agreement yet. Who currently handles each of the four buckets. Who pays for what. What the fee calculation actually is, in source-data terms. This document is half the work of the eventual contract and reveals the unresolved questions.
2. Run the fee model against a slow-quarter scenario and a peak-quarter scenario. A percentage of gross, a flat per-door, and a hybrid produce materially different cash flows across both. Pick the model where both sides can live with both outcomes. If only one side can live with one scenario, the model is mispriced.
3. Get a localized agreement template reviewed by counsel. Not drafted from scratch. The structural questions in this guide are common to most jurisdictions; the legal-form details (notice period enforceability, fee dispute resolution, governing law) are jurisdiction-specific. A short engagement with an attorney who works with property managers in the operating state is the lower-cost path.

The cost of skipping these is not theoretical. The data point operators report most consistently is that the first co-hosting dispute happens within the first 12 months of the relationship, and the resolution cost (legal fees, lost relationship, sometimes lost listings) commonly exceeds the cost of having written the agreement at the start by an order of magnitude.

Disclaimer (YMYL): This is informational, not legal advice. Co-hosting and property management agreements are contracts governed by state and country law; enforceability of specific clauses (notice periods, fee dispute resolution, data ownership on termination, liability caps) varies materially across jurisdictions. Engage a licensed attorney in the operating jurisdiction before drafting, signing, or terminating an agreement. Information current as of June 2026. Platform policies and fee structures change.