Hotel Payment Schedules Across OTAs

A payment label is too compressed to reconcile a hotel booking. Write down four separate events. First, when is the guest expected to pay the room amount? Second, who takes that payment: the property, the OTA, or a payment partner acting in a defined model? Third, when and how does the hotel receive its funds? Fourth, is any separate amount still due at the property? These events can happen on different dates and can involve different currencies or payment instruments.

The first event is guest payment timing. It may be due online at booking, on a later stated date, in scheduled parts, or at the property. The second is the collection model: who processes the transaction. The third is settlement or remittance: the transfer from the collecting party to the hotel, if the hotel is not paid directly. The fourth is an onsite amount, such as a separately disclosed local charge. Do not combine these into a single “paid” field in a spreadsheet.

A reservation can also require a card to secure the booking without taking the room payment immediately. Booking.com’s accommodation payment FAQ distinguishes securing a pay-at-property reservation with card details from collecting its room amount at arrival. Likewise, an authorization hold and a completed payment are different events. This guide does not explain incidental holds; record them separately if your guest policy requires them.

Online payment at booking is the easiest timing to identify: the selected amount is due immediately through the booking flow. A later online payment still has a date or schedule attached to it; “later” alone does not say whether the charge happens a few days before arrival, on another scheduled date, or in more than one part. Record every event and amount instead of reducing the schedule to the first date you noticed.

Pay at the property means the room amount is due directly at the accommodation under the stated booking terms. It does not, by itself, tell you whether a card is required to secure the reservation, how a cancellation is handled, or whether separate taxes are collected locally. Those belong to different fields and may be governed by different policy text. A payment method shown to secure a booking should not be logged as a completed room charge.

Booking.com’s public Demand API documentation gives accommodation timings named pay online now, pay online later, and pay at the property. Its guidance says to use the selected product’s order preview for the current dates, amounts, and accepted methods, because the options may vary with property policy or availability. These are API integration documents, not an Extranet menu path, so do not treat them as instructions for how a hotel account configures its rates.

Partial schedules need one row per payment event. If a booking shows an amount due now and a balance due later, capture both. If the channel's checkout summarizes several events as one total, open the booking details or confirmation and record the dates and amounts available there. If the exact schedule is not visible before purchase, mark it unverified and ask the platform through the account-specific support route rather than guessing.

• ✓Copy the exact payment timing label and all published due dates.
• ✓Record each payment amount and currency separately when the schedule is split.
• ✓Note whether the payment method is used to pay, to guarantee, or to secure the booking.
• ✓Keep amounts due at the property separate from online room payments.
• ✓Mark any date or collection owner that is not visible in the booking evidence as unverified.

The names used by platforms describe specific products and account arrangements, not a universal hotel payment standard. The table below records only what the linked platform documentation establishes. An individual hotel’s contract, selected rate, market, and reservation confirmation still determine the terms for that booking.

Expedia Group’s developer documentation distinguishes Expedia Collect, where Expedia charges the traveller when the reservation is made and the hotel receives the funds after check-out, from Property Collect, where the traveller pays the property in person at check-in. The Property Collect guide also documents exceptional pre-arrival card transactions under specified conditions. A security check or policy-triggered amount should be written as a separate event from the ordinary room balance.

Agoda describes Property Collect as payment due directly to the property on arrival and says the full selling amount is collected from the guest at check-in. Agoda also documents an offset mechanism for commission on Property Collect reservations: the amount owed is deducted from eligible prepaid bookings, with transaction and remittance statements in Partner Portal. That means “property collected the guest payment” does not mean “there is no OTA settlement entry to reconcile.”

A guest can be charged now while the hotel is settled later. Expedia Group’s published receipt model says Expedia Collect charges the guest at booking and the hotel receives those funds after check-out. That timing is a property-side transfer rule, not another guest payment deadline. Keep both dates in the record: charge date for the traveller and remittance date for the hotel.

The same separation matters when a property collects directly. Agoda’s Property Collect documentation describes how its commission is offset against prepaid remittances and how a booking-level statement can be downloaded. A bank deposit that is lower than a property’s gross room collection may therefore need to be reconciled to the platform’s statement and contract, rather than treated as proof that the guest paid less.

For each real reservation, reconcile the booking confirmation, payment or card record, and settlement statement using the reservation identifier. Compare gross room value, any separately stated property-collected amount, the platform’s settlement entry, and the final hotel receipt. Keep commission deductions in the cost record and local taxes in the tax record. This guide does not estimate net revenue or determine whether a fee is contractually correct.

A payment comparison only makes sense when the offers are comparable. Use the same property, arrival and departure dates, number of guests and rooms, booking market, display currency, room category, meal inclusion, and rate conditions. A flexible rate and a non-refundable rate may have different payment terms by design. If the rate conditions differ, record the reason before deciding that one channel has drifted.

Start with public offer and booking-detail evidence without completing a real reservation. Keep the market and locale visible because a payment option may be presented differently by country or currency. If you are reviewing an existing booking, use its confirmation and partner record rather than trying to reproduce the booking using a different rate or travel date. Do not retain full payment-card details in the audit sheet; a reservation ID and an authorized finance record are enough for reconciliation.

For an audit that spans live channels, create one row per source and one row per payment event. Use the guest-facing offer to identify what was promised and the partner finance record to establish what was charged or remitted. If the booking source is an API integration, use its current preview or booking response for that product instead of a static reference page. Record unknown values as unknown and assign them an owner.

• ✓Match the market, date range, guest count, room, meal inclusion, and rate conditions.
• ✓Save the guest-facing terms and the booking-level payment schedule, where available.
• ✓Record the responsible collector and the property’s settlement evidence separately.
• ✓Mark cancellation penalties, local taxes, mandatory extras, commission, and card holds outside this comparison.
• ✓Close a finding only after the approved contract or rate rule and the booking evidence agree.

Different timing does not automatically mean an error. A property may deliberately offer an advance-purchase rate with online payment and a flexible rate paid at the hotel. A long lead time can produce a different schedule from a last-minute booking, and the selected market or product can change available payment methods. Compare the offer to the hotel’s approved commercial rule first; use another OTA’s schedule only as a clue to investigate.

Common false alarms include a card guarantee recorded as a payment, a later online payment mistaken for arrival payment, or the hotel’s payout date mistaken for a guest due date. Other false alarms arise when local taxes, cancellation penalties, or fees are added to one channel’s displayed total but not another. Those items affect what a guest pays, but they are separate from the base room payment event and have their own audit pages.

When the exact rule is unclear, pause the edit. Save the public terms, booking identifier, and finance evidence, then ask the person who owns the OTA contract, rate plan, or payment account to confirm the approved arrangement. Once clarified, update the source-of-truth record and verify the selected live offer again. This keeps a payment correction from changing a rate that was intentionally configured differently.