FLYR pulls data at a granular, transactional level — every individual booking — and aggregates those records to calculate totals and KPIs. Because data is ingested at this level of detail, small variances between FLYR and your PMS are possible. We consider data accurate within a threshold of 1% at the monthly level.
If you notice a difference, the first step is to make sure you're pulling the correct report from Opera — not all reports reflect the same data that FLYR receives via the integration. This article covers which reports to use for validation, as well as known data gaps specific to the Opera v5 integration, their causes, and suggested workarounds.
If any of these discrepancies were identified during your onboarding process, our team would have proactively flagged and discussed them with you.
Note:
The information in this article applies to Opera version 5.5.0.23 or higher. If your property is using an earlier version, functionality may differ, and additional limitations could apply.
Validating data against Opera v5 reports
Pull the History and Forecast Report by day to validate your data against FLYR. When selecting your date range, go slightly beyond the affected dates — for example, if the discrepancy appears around October 12–15, pull the full month of October. If you're raising a specific discrepancy with our support team, also include the Financial Transactions with Generates report pulled by day.
1. Postings to Account Receivable (AR)
Description Postings made directly to Accounts Receivable (AR) are not received via OXI and therefore do not appear in FLYR.
Suggested Workaround Post accommodation charges directly to PM reservations instead of AR.
2. Postings to Passer By Rooms
Description Postings made directly to Passer By rooms are not transmitted through OXI and will not appear in FLYR.
Suggested Workaround Post accommodation charges directly to PM reservations rather than Passer By rooms.
3. Accommodation Charges Manually Posted to Checked-In Reservations
Description Accommodation charges manually posted to checked-in reservations (e.g., early check-in charges) are only received via the STAY message upon check-out. This means interim updates will not reflect in FLYR until the reservation is checked out.
Suggested Workaround None. This is a standard behavior in Opera and a limitation of OXI.
4. Routings to PM Reservations
Description There are three routing-related scenarios that can impact data synchronization:
Scenario 1: All reservations routed to a PM Revenue remains on the individual reservations until the PM checks out. Upon PM check-out, the revenue is reverted from the PM to the original reservations.
Scenario 2: All reservations manually transferred to a PM Revenue is removed from individual bookings upon their check-out. When the PM checks out, OXI sends the revenue for the manually transferred postings — this revenue is not reverted to the original reservations, and the PM retains all revenue. Manual posting movements cannot be traced back to the original booking because routing instructions are missing.
Scenario 3: Mixed routed and manual transfers to a PM For routed bookings, revenue remains on individual reservations until PM check-out, at which point it's reverted appropriately. For manually transferred bookings, revenue is only received when the PM checks out and is not reverted.
Suggested Workaround Use Opera's routing functionality to manage routings efficiently and avoid manual transfers whenever possible.
5. Manual Postings to Future Reservations
Description Manual charges posted to future bookings are not received via OXI.
Suggested Workaround None. This is standard Opera behavior.
6. Manual Postings After Check-Out
Description Charges posted after a reservation's check-out date are not transmitted through OXI and will not appear in FLYR.
Suggested Workaround Post such charges to a PM reservation instead of a checked-out booking.
7. Manually Transferred Revenue Between Bookings
Description When revenue is manually transferred from one booking (A) to another (B) that has different stay dates (e.g., back-to-back reservations), the revenue from the first booking will only be received after the second booking checks out.
Suggested Workaround None. This is standard Opera functionality.
8. One-to-Many Routings Not Supported
Description FLYR supports only one-to-one routing instructions. If a reservation includes multiple routings (e.g., first night to Reservation A, second night to Reservation B), only the first routing is processed, and all revenue is allocated to the first reservation.
Suggested Workaround None. This aligns with standard Opera routing behavior.
9. Tax Codes for Service Charges
Description In certain configurations (notably observed in UAE properties), tax codes used for service charges may be set up to generate accommodation revenue. In such cases, this revenue is only received upon check-out, which causes a delay in reporting the associated accommodation revenue.
Suggested Workaround None. This is standard Opera behavior.
10. Revenue for Historically Cancelled Reservations
Description Revenue from cancelled reservations prior to the initial FLYR connection is tracked only if cancellation charges were actually posted. If no such charges exist, accommodation revenue for those historical cancelled bookings cannot be retrieved.
Suggested Workaround None. This is a limitation of Opera's export functionality.
Summary
While FLYR’s integration with Opera V5 (OXI) provides extensive coverage of reservation, revenue, and rate data, some scenarios remain unsupported due to the technical constraints of the OXI interface. For information on any other temporary discrepancies, check out this article.
By following Opera best practices — particularly around routing, PM usage, and rate plan setup — you can help minimize data inconsistencies between Opera and FLYR.
If you have questions about any of the above scenarios or notice discrepancies not covered here, please reach out to our support team for further guidance.