Hotel revenue reconciliation: automate OTA commission audits
Published on :
May 25, 2026
Nicolas Marchais is co-founder and CEO of Phacet. After seven years at Spendesk, he built Phacet as the agentic layer that orchestrates across ERP, banking and email systems. Reliable, auditable, cross-system, what he calls a Finance Workforce.
A single OTA booking at your hotel can touch up to seven systems before it is fully settled. The guest books on Booking.com or Expedia. The reservation drops into your channel manager. It flows to your PMS. The virtual credit card hits your payment gateway. The settlement lands in your bank. The commission invoice arrives by email. The journal entry posts in your ERP. At every handoff, something can go wrong, and most of the time, nobody notices until weeks later, when a guest disputes a charge or your monthly close shows a revenue gap that nobody can explain.
This article maps the seven systems a single OTA booking crosses, the six error categories that quietly drain revenue, why your PMS and channel manager were never built to do the reconciliation, and how a layer of agents above the existing stack runs the daily check that recovers the money before it walks out the door.
Why OTA commission reconciliation is not a PMS problem
Walk into any hospitality finance department in 2026 and ask the obvious question: who reconciles your OTA commissions? The answer is almost always "the PMS does it." It does not. The PMS records the reservation, the channel manager distributes inventory, the OTA collects the booking, the gateway processes the card, the bank receives the settlement, and the ERP posts the journal entry. Each system handles its own slice. None of them owns the end-to-end reconciliation between what the guest paid, what the OTA invoiced as commission, and what the bank deposited.
The structural reason this work falls between systems: OTA commissions are not transactional charges that flow through a single pipeline. They are calculated as percentages on net room revenue, applied differently depending on whether the booking was a flexible rate or a non-refundable one, adjusted for resort fees and taxes that may or may not be commissionable, and stripped further when a stay is shortened or cancelled. The math depends on terms that change by OTA, by rate plan, and by booking type. No PMS validates that math against the actual invoice the OTA sends weeks later. No channel manager has visibility on the bank settlement that arrived two weeks after that. The work crosses every system in your hotel tech stack, and there is no single system that owns it.
This is what makes OTA commission reconciliation structurally different from supplier invoice reconciliation, payroll posting, or any other AP workflow. It is revenue-side reconciliation, and revenue-side reconciliation requires reading data from your channel manager, your PMS, your gateway, your bank, and the OTA's commission invoice, then matching every line of the invoice back to the original booking it was charged against. The architectural problem behind this is what our data alignment across systems glossary entry describes. The number of hotels actually doing this daily is close to zero. Almost everyone does it monthly at best, often quarterly, and the errors that fell through the cracks two months ago are no longer recoverable.
The 7 systems a single OTA booking touches
A typical Booking.com reservation at a mid-market urban hotel illustrates the chain.
Guest selects a room on Booking.com, agrees to the rate, enters card details. Booking issues a confirmation and creates a reservation record. The commission rate (typically 15% to 25% depending on Genius status, geography, and program tier) is calculated server-side. The hotel does not yet see the math.
The reservation drops into the channel manager (SiteMinder, D-Edge, Cubilis, RateGain, Yanolja Cloud). The channel manager parses the OTA's reservation format, identifies the rate plan, and pushes the booking to the PMS. Any rate or restriction mismatch between channel manager configuration and OTA listing surfaces here as a routing problem, not as a financial one.
The PMS (Mews, Cloudbeds, Opera Cloud, Apaleo, Stayntouch, HotelKey) creates the reservation, holds the room, prepares the folio. If the OTA sends a virtual credit card (VCC) for prepayment, the PMS records the card number against the reservation. The PMS treats the booking as an internal stay, with limited visibility on the original commission structure.
When the hotel charges the guest (or the VCC), the transaction flows through the gateway (Adyen, Stripe, Worldpay, Elavon, FreedomPay). The gateway captures the gross amount, applies its processing fee, and prepares the settlement.
The bank receives the net settlement two to five business days later, usually batched. The line item in the bank statement does not identify which booking, which guest, or which OTA the settlement corresponds to. The hotel sees only the gross deposit and the batch reference.
Two to four weeks after the stay, the OTA sends a commission invoice or pushes commission data to the channel manager. The invoice lists the reservations the commission applies to, the rate applied, the adjustment for no-shows, the adjustment for cancellations, the credit notes for guest disputes resolved in the hotel's favor. The math behind the invoice is dense. Most hotels accept it as-is.
The finance team books the OTA commission as a cost in the ERP (Sage, NetSuite, Cegid, SAP, Pennylane). The commission gets categorized, allocated to the right cost center, and reconciled against the bank in monthly close. By this stage, three to six weeks have passed since the original booking, and any error in the chain has either been absorbed silently or noticed in passing.
The point of mapping the chain is not to demonize any single tool. Each one does its job. The point is that no one tool owns the audit between them, and the financial discrepancies live precisely in the gaps between systems.
The 6 error categories that quietly drain hotel revenue
Evention's analysis of multi-property portfolios identifies the six categories of OTA billing errors that compound silently across a typical hotel year. Each one individually is small enough to escape attention. Together, they drain six figures.
Virtual credit card underpayments. When the OTA pre-collects payment and issues a VCC, the card amount should match the reservation total minus the commission. If the OTA underpopulates the VCC (the card amount comes in lower than expected), the hotel charges less than it earned. The discrepancy is invisible unless the hotel reconciles each VCC against the booking it was issued for.
Commission overpayments on no-shows and short-stays. OTA commission rules typically allow the hotel to claim back commission when a guest no-shows or shortens their stay. Most hotels do not file these claims systematically because the work to identify, document, and submit them exceeds the marginal recovery per case. Multiplied across hundreds of no-shows per year, the unclaimed recovery is substantial.
Resort fee variances. Resort fees, destination fees, and similar surcharges may or may not be commissionable depending on the OTA's contract terms. When the OTA applies commission to a fee that should have been excluded, the hotel overpays. The error is detectable only by reading the commission invoice line by line and comparing each charge against the original contract.
Rate discrepancies. The rate on the OTA confirmation, the rate in the PMS, and the rate used to calculate commission should match. They often do not, because of rate parity issues, channel-specific promotions, or timing mismatches between rate updates and booking creation. When the commission is calculated on a higher rate than what the guest paid, the hotel pays commission on revenue it never earned.
Guest double-charges. When the OTA collects payment and the hotel also charges the guest's card (or vice versa), the guest disputes, and the hotel ends up issuing a refund. The hotel's revenue is reduced by the refund amount, but the OTA may still claim commission on the original booking. The double-charge is a guest experience problem and a finance problem at the same time, and the cleanup happens weeks after the stay.
Cancellation errors. When a guest cancels under a refundable rate, the commission should not apply. When the cancellation arrives late or in the wrong system, the OTA may invoice commission for a booking that never generated revenue. The hotel pays for a stay that did not happen.
The six categories overlap in real-world cases, which is why manual reconciliation drowns. The combinatorial complexity is exactly the kind of work agents handle natively, and exactly the kind of work humans cannot scale to.
Why your PMS was never going to solve this
The major PMS vendors (Mews, Cloudbeds, Opera Cloud, Apaleo) all advertise automated reconciliation as a feature. The feature is real, and it works for the slice each tool owns. None of them does cross-system reconciliation between channel manager, PMS, gateway, bank, and OTA invoice, for one structural reason: the PMS was built to manage the property, not to audit the financial chain around it.
A useful test: ask your PMS vendor to open any reservation from last month and show you (a) the rate confirmed on the OTA, (b) the rate booked in the PMS, (c) the VCC amount captured, (d) the gateway settlement amount, (e) the bank deposit line, (f) the commission invoiced by the OTA, (g) the journal entry posted in the ERP. The vendor will be able to show you items (b) and (c), maybe (d) if the gateway is embedded. The other four live in systems the PMS does not own.
This is also why dedicated channel reconciliation tools have started to emerge. Evention launched OTA Recon in May 2026 specifically for this gap. The fit for US chains is real. For mid-market European hotels and independent groups in France, the gap remains largely unaddressed because the existing offerings either require enterprise pricing or assume a US-centric stack.
The architectural answer is not a new vertical-specific tool. It is a layer of agents above the existing stack (PMS + channel manager + gateway + bank + ERP) that reads from all of them, runs the seven-system reconciliation continuously, and surfaces only the exceptions for human review. The agents are not a replacement for the PMS. They are the audit layer the PMS was never designed to be. Our AI agents for finance control analysis maps the broader pattern this fits into.
How an agentic layer runs the daily OTA reconciliation
Each Phacet agent structures the input (reads OTA confirmations, channel manager records, PMS folios, gateway settlements, bank statements, commission invoices), controls against a reference (the original booking terms, the contractual commission rate, the rate plan, the cancellation policy), and exposes its reasoning with a confidence score. Every step is timestamped in a native audit trail. Together, the agents make the OTA reconciliation reliable, controllable, and auditable for the first time.
The agents that map directly onto the seven-system OTA chain:
- The payment gateway, bank and ERP reconciliation agent handles the daily match between gateway settlement, bank deposit, and ERP journal entry. It identifies VCC underpayments, processing fee variances, and settlement timing mismatches the same morning they occur, not three weeks later. This is the continuous finance control pattern applied to revenue-side reconciliation.
- The ops tool and ERP reconciliation agent handles the match between the PMS and the ERP. In a hotel context, the PMS is the ops tool: the night audit closes the day in the PMS, the agent verifies that the room revenue and the OTA bookings that flowed through it appear correctly in the ERP. If the PMS shows 47 bookings for the night and the ERP only shows 45, the agent flags the gap before close.
- The supplier billing control agent handles the line-by-line variance check on the OTA commission invoice itself. Each line is checked against the contracted rate, the rate plan, the resort fee status, and the booking record. When the OTA charges commission on a non-commissionable fee or applies the wrong rate, the agent flags it before the invoice is paid.
- The bank reconciliation agent handles the daily reconciliation of bank deposits against expected OTA settlements. Booking deposits arrive batched, Expedia deposits arrive batched, Airbnb deposits arrive on their own schedule. The agent matches each batch back to the underlying bookings, not just to the gross deposit amount. The pattern of bank reconciliation automation extends here from supplier-side to OTA-side reconciliation.
- The POS and cash control agent handles the multi-site dimension. For a group of 18 hotels (the Astotel pattern), the same OTA reconciliation needs to run on every property simultaneously, with the results aggregated at the group level. The agent runs daily on every site without proportional human effort.
Each agent surfaces its results in Tables: a tabular view where each row is a booking, a settlement, or an invoice line, with its source documents attached, the variance from expected, the confidence score, and the resolution status. When the variance exceeds a confidence threshold (say 2%), the AI Match component surfaces the case for human review in the Vue Détail. The controller reviews exceptions, not transactions. The team at the finance office of a 10-property group can run the daily OTA check in 30 minutes, where it would have required a full-time person before.
What Astotel shows about the multi-site pattern
Astotel - 18 Parisian hotels
The group operates 18 Parisian hotels with continuous price variance checks on every supplier invoice. The recovery on a single supplier through line-by-line variance checks: 5,000 euros per year. The errors were always there. Manual sampling could not see them because the volume across 18 properties exceeded what humans could review. The agent does not need to sample. It reads every line of every invoice and surfaces only the variances. The same architectural pattern that recovers supplier billing errors applies directly to OTA commission invoices: every line, every booking, every property, every day.
"Je gagne jusqu'à deux jours par mois, et je repère des erreurs que je n'aurais jamais vues seule." -- Valérie, Directrice Achats
This is the operational signature of multi-site hospitality finance: the work scales linearly with property count, and the team does not. The unit economics of running 18 hotels with a 4-person finance team only work when the per-booking reconciliation work happens automatically. Multi-site groups that grow without that layer hit a hard wall around 8 to 12 properties, where the finance team is consumed by reactive reconciliation and the senior controllers stop doing the margin analysis that the group depends on. Our multi-site finance control analysis documents the operating-model implications for groups in this size range.
FAQ
What is hotel revenue reconciliation, exactly?
Hotel revenue reconciliation is the end-to-end process of matching every revenue event (bookings, settlements, commissions, refunds, cancellations) across all the systems that touch it: OTA platform, channel manager, PMS, payment gateway, bank, commission invoice, and ERP. It is distinct from PMS reconciliation (which closes the property's books for the day), from bank reconciliation (which matches deposits to expected settlements), and from supplier reconciliation (which matches AP invoices to POs). Hotel revenue reconciliation is the cross-system audit that ensures the seven systems agree on what the property actually earned.
How much money does a typical hotel lose to OTA reconciliation errors?
Evention's analysis of multi-property portfolios identifies six categories of OTA billing errors that drain over $130,000 per year from a typical 300-room hotel. The six categories are virtual credit card underpayments, commission overpayments on no-shows and short-stays, resort fee variances, rate discrepancies, guest double-charges, and cancellation errors. Smaller hotels and independent groups have proportionally similar exposure, scaled to their booking volume. The numbers compound when an OTA is misconfigured for several months before anyone notices.
Why can't my PMS handle this reconciliation?
The PMS is built to manage the property: reservations, folios, housekeeping, payments. It owns one slice of the chain. The OTA reconciliation requires reading data from the OTA platform, the channel manager, the gateway, the bank, the commission invoice, and the ERP. No PMS owns all seven systems. The major vendors (Mews, Cloudbeds, Opera Cloud) advertise automated reconciliation as a feature, but the feature handles the PMS-to-PMS slice, not the seven-system audit.
What's the difference between OTA reconciliation and night audit?
Night audit closes the day's transactions in the PMS: it reconciles the day's revenue, posts charges to folios, balances the cash drawer, and closes out the operational day. It is intra-PMS, runs at the property level, and concerns the property's own books. OTA reconciliation is cross-system, runs across the seven systems described above, and concerns the financial relationship between the property and the OTA. The two are complementary: night audit closes the property's day, OTA reconciliation audits the financial chain over the following weeks.
How does daily reconciliation differ from monthly close reconciliation?
Daily reconciliation surfaces variances the same morning they occur, while they are still recoverable. Monthly reconciliation surfaces variances three to six weeks later, after the recovery window has closed. Evention's data shows daily exception-based reconciliation recovers 10 to 40 times the platform cost in previously uncollected revenue, with a 96% reduction in manual reconciliation time and a 95% reduction in errors. The shift from monthly to daily is the structural change that converts an uncollected loss into a recovered revenue stream.
Can this work for a small or single-property hotel?
Yes, though the ROI scales with booking volume. A single 80-room urban hotel with significant OTA dependency typically has enough volume to justify automated reconciliation. The break-even is roughly where the manual reconciliation effort exceeds two hours per week, which most properties hit if they take OTA bookings seriously. For groups of 3+ properties, the case becomes straightforward, because the per-property setup cost is amortized and the multi-site aggregation surfaces patterns that no single property could see.
What systems does Phacet integrate with for this use case?
Phacet operates as a layer above the existing hospitality stack rather than as a replacement. The agents connect to the major PMS systems (Mews, Cloudbeds, Opera Cloud, Apaleo, Stayntouch), the channel managers (SiteMinder, D-Edge, Cubilis), the payment gateways (Adyen, Stripe, Worldpay, Elavon), the major French and European banks (BNP, Société Générale, Crédit Agricole, Qonto, Revolut), and the ERPs (Pennylane, Sage, NetSuite, Cegid). The integration model does not require migration: the agents read from each system and write the reconciliation results back to the ERP and the audit trail.
The question "how do we recover the money we are losing to OTA reconciliation errors?" has a simple answer that no PMS, no channel manager, and no ERP delivers by default: run the seven-system check every day, surface only the exceptions, and resolve them while recovery is still possible. The math works out the same way across hotel sizes and geographies. The reason it does not happen is structural: the work crosses too many systems for a human to do daily, and the existing tools were not built for cross-system audit.
The architectural answer is an agentic layer above the existing stack that reads from every system, runs the reconciliation continuously, and routes exceptions to human review. Phacet operates exactly in this layer. The 40+ specialized AI agents include the ones that map onto the OTA chain: payment gateway reconciliation, ops tool / ERP reconciliation, supplier billing variance (applied to commission invoices), bank reconciliation, and multi-site POS / cash control. Each agent ships in production in under two weeks. The full multi-system OTA reconciliation typically reaches steady state within one to two quarters.
For the hospitality finance team, this is not a vendor migration. It is a layer added above what already runs. The recovery shows up in monthly close as a line that was not there before: variance against OTA commission invoices, captured systematically. The errors that were never visible become visible, and the team that always sensed something was off finally has the evidence to act on it. The pattern of running finance controls continuously rather than at month-end is documented in our continuous finance control analysis. Our hospitality industry page details the broader use case footprint for hotel groups in segment B and C.
Latest Resources
Unlock your AI potential
Go further with your financial workflows — with AI built around your needs.
