Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Hotel revenue flows through OTA to channel manager to PMS to ledger to bank, with each interface having distinct data formats — Opera, IDS Next, eZee, Hotelogix on the PMS side; SiteMinder, STAAH, RateGain on the channel side; multiple OTAs with different settlement file shapes — making end-to-end folio-to-ledger reconciliation a multi-system matching problem rather than a single system query.
Build a chain index keyed on the OTA reference number plus the PMS folio number. Per booking, capture five events: OTA confirmation, channel manager push, PMS folio creation, PMS folio closure with final amount, and OTA settlement. Match each pair adjacently — confirmation to push, push to folio, folio to settlement, settlement to bank. Surface breakpoints at each interface as exceptions for finance team review.
PMS connectors for Opera, IDS Next, eZee, Hotelogix; channel manager log connectors for SiteMinder, STAAH, RateGain; OTA settlement file adapters; bank statement parser; folio-number plus OTA-reference-number composite key; exception handler per interface breakpoint type.
A folio-level audit trail per booking spanning OTA confirmation, channel push, PMS folio, settlement, and bank credit — with breakpoints flagged by interface type for finance team resolution and an end-to-end revenue ledger that ties to bank receipts.
A 200-room business hotel in Bengaluru runs Oracle Opera as its PMS, SiteMinder as its channel manager, and distributes inventory across MakeMyTrip, Goibibo, Booking.com, Agoda, and its own website. In a typical month it handles 5,000 bookings spanning these channels. The finance team must reconcile each booking from OTA confirmation through SiteMinder push, Opera folio, OTA settlement file, and bank credit. Any breakpoint in this chain produces revenue leakage, cash unreconciled, or an audit exception. This article is for hospitality finance teams operating multi-OTA distribution with PMS and channel manager infrastructure in India.
What PMS and Channel Manager Reconciliation Involves
PMS and channel manager reconciliation is the end-to-end commercial match across the hotel’s distribution stack. It differs from inventory parity reconciliation, which is a real-time function of the channel manager preventing the same room from being sold twice. PMS-channel-manager-OTA-bank reconciliation is the after-the-fact financial chain: did the booking that came in at OTA X end up as Opera folio Y, get settled in OTA settlement file Z, and land in bank credit W — at the right amount net of commission, GST, and TDS.
The reconciliation outputs are: a per-booking audit trail across five layers (OTA confirmation, channel manager push, PMS folio open, PMS folio close, OTA settlement, bank credit), an exceptions list categorised by interface breakpoint type, and a period-end revenue ledger that ties bottom-up from folios to top-down from bank receipts.
How PMS and Channel Manager Reconciliation Works
Building the Composite Key
Each booking carries multiple identifiers — OTA reference number (MMT-12345, BCN-67890), channel manager booking ID, PMS folio number. The reconciliation index keys on the OTA reference number first because it is the only identifier that appears in the OTA settlement file. The PMS folio number is the second key, used to anchor the financial close. A booking without an OTA reference stored on the folio is reconciliation-orphaned — finance teams must back-fill from check-in records or guest emails to repair the chain.
Matching OTA Confirmation to Channel Manager Log
The channel manager log records each inventory event: rate update pushed out, booking received, parity check passed or failed. The first reconciliation match is OTA confirmation timestamp against channel manager push timestamp — typically seconds apart. Lag of more than a few minutes indicates a channel manager bottleneck or queue. A confirmation with no corresponding channel manager log entry is a lost booking — the channel manager either failed to receive it or failed to forward it.
Matching Channel Push to PMS Folio Creation
The channel manager pushes the booking into the PMS, which creates a folio. The match here is on the OTA reference number stored on the folio, the room category, and the rate. Drift between the channel push (which carried the contracted rate) and the folio (which sometimes adopts the property’s local rate by mistake) is a recurring source of rate leakage — the OTA settlement will pay on the contracted rate while the folio shows a different rate, and the period close has to decide which one represents the truth.
Matching PMS Folio Close to OTA Settlement
At check-out, the folio closes at the final amount inclusive of incidentals. The OTA settlement file, received cycle-by-cycle, lists each booking with its room amount, commission, GST, TDS, and net payout. The match is folio-close room amount versus OTA settlement gross room amount. Incidentals charged at the property (mini-bar, room service) are typically not on the OTA settlement and must be settled separately through the property’s own POS or card terminal.
Matching Settlement to Bank Credit
Each OTA settlement cycle produces a single net bank credit. The reconciliation traces the bank credit back to the settlement file aggregate, factoring in GST on commission, TDS deducted, and any cycle-end adjustments. UTR-level matching at this layer is identical to standard payment-rail reconciliation — the OTA’s payout reference appears in the bank narration and links the cycle to the credit.
PMS and Channel Manager Stack Reference
| Layer | Common Indian Deployments | Typical Reconciliation Output |
|---|---|---|
| PMS | Oracle Opera, IDS Next, eZee Frontdesk, Hotelogix, Innkey | Folio-level revenue and incidentals |
| Channel Manager | SiteMinder, STAAH, RateGain, AxisRooms | Inventory pushes and parity log |
| OTAs | MakeMyTrip, Goibibo, Booking.com, Agoda, Yatra, OYO | Settlement files with commission, GST, TDS |
| Acquirer / Gateway | Property’s bank or Razorpay or PayU for direct bookings | Card and UPI settlements |
| Bank | Property’s operating account | Single net credits per OTA cycle |
India Compliance Angle: Folio as Source for GSTR-1 Invoice
For Indian hotels, the folio is the primary tax-invoice source document. GSTR-1 is filed on folio-level invoice data — not on the OTA settlement file. This means the PMS-to-ledger chain is the GST audit trail, with the OTA settlement layered on top for commission, GST on commission ITC, and TDS reconciliation. A scrutiny assessment will trace from a sampled folio to the GSTR-1 line, then test whether the OTA commission GST claimed in GSTR-2B matches the OTA’s tax invoice for the same period. Breakpoints in the PMS-OTA chain produce GSTR-1 versus GSTR-3B mismatches that are difficult to defend without a complete folio-level audit trail.
Hotel finance teams using payment gateway reconciliation tooling can ingest acquirer settlements for direct bookings alongside OTA settlement files. Broader reconciliation software India platforms add PMS connectors for Opera, IDS Next, eZee, and Hotelogix, channel manager log ingestion for SiteMinder and STAAH, and the composite-key indexing required to maintain a folio-level audit trail across the distribution stack. Industry guidance from FHRAI on PMS and channel manager architecture provides the operational reference for hotel finance teams.
For the broader hotel industry reconciliation surface, see the Hotels & Hospitality industry guide.
The following questions address the PMS and channel manager reconciliation issues hotel finance teams encounter most frequently.