Skip to main content

Understanding Data Discrepancies Between Opera Cloud and FLYR Reporting

Explanation on known limitations and data discrepancies between Opera Cloud and FLYR

Laya Janssens avatar
Written by Laya Janssens
Updated over 3 weeks ago

At FLYR, we aim to ensure a seamless integration and data synchronization experience between Opera Cloud and FLYR. However, due to certain limitations in Opera Cloud’s API and data structures, there may be instances where reported data between the two systems does not fully align.

If any of these discrepancies were identified during your onboarding process, rest assured that our team would have proactively flagged and discussed them with you.

Note:
The information in this article applies to an Opera Cloud version of 22.4 or higher. If your property is using an earlier version, functionality may differ, and additional limitations could apply.

Below is a detailed overview of known data gaps, their causes, and suggested workarounds.


1. Postings on Account Receivables (AR) Are Not Supported

Description
Opera allows retrieval of revenue posted to Accounts Receivables (AR) via the API, but it does not provide detailed transaction code breakdowns.
As a result, while total revenue can be accessed, transaction-level details cannot — meaning these postings will not appear in FLYR.

Suggested Workaround
Post accommodation charges directly to PM reservations instead of Accounts Receivables (AR).


2. Postings on Passer Rooms Are Not Supported

Description
FLYR does not currently support retrieving postings made on Passer rooms through the Opera API. Consequently, any revenue posted to Passer rooms will not be reflected in FLYR.

Suggested Workaround
Post accommodation charges directly to PM reservations rather than Passer rooms.


3. Manual Transaction Routings Cannot Be Traced Back to the Original Bookings

Description
When postings are manually moved between reservations without using Opera’s routing instructions, those transactions cannot be linked back to the original booking. As a result, the original reservation’s revenue traceability is lost.

Suggested Workaround
Use the routing functionality in Opera to manage routings efficiently and maintain traceability.


4. Occupancy for Groups Under Contract or Forecast Is Not Supported

Description
Room allocations under “Contract” or “Forecast” statuses in the Group Room Grid are not retrieved via the API and will not appear in FLYR.

Suggested Workaround
Add tentative or definite room blocks under the “Current” field in the Room and Rate grid to ensure inclusion.


5. Block Deletion Is Not Supported

Description
Opera does not send a business event when a block is deleted. As a result, deleted blocks remain marked as Confirmed in FLYR and continue showing revenue and occupancy.

Suggested Workaround
Instead of deleting blocks, cancel them. This ensures the block status and associated data are correctly updated in FLYR.


6. Revenue Cannot Be Traced for Block Reservations Without Routings

Description
If reservations have postings routed to a PM or another reservation without visible routing instructions in Opera, the associated revenue cannot be traced back to the original reservations in FLYR.

Suggested Workaround
Always include routing instructions in Opera and avoid manual routings whenever possible.


7. FLYR Supports Only One-to-One Revenue Routings

Description
Currently, FLYR supports only a single routing instruction per reservation. If a reservation has multiple routings (e.g., first night to Reservation A, second night to Reservation B), only the first routing will be processed — all revenue will be allocated to the first reservation.

Suggested Workaround
None available. This behavior aligns with standard Opera functionality.


8. Reservation Deletion Is Not Supported

Description
If a reservation is deleted (instead of canceled), Opera returns a “Not Found” error. This prevents FLYR from updating the status to “Canceled,” leaving the reservation incorrectly marked as Confirmed.

Suggested Workaround
Cancel reservations instead of deleting them to ensure accurate reflection in both systems.


9. Only Daily Rate Plans Are Supported for Price Updates

Description
For FLYR to push price updates successfully, the Base Rate Plan must be a daily rate plan. Non-daily rate structures are not supported.

Suggested Workaround
If your property uses a non-daily rate plan, create a daily rate plan and set up dependencies for other rates accordingly.


10. Pick-Up Revenue for Adjustments on Past Reservations

Description
Revenue adjustments for past stay dates are generally reflected correctly in FLYR as long as they are non-overnight. However, overnight adjustments may cause pick-up discrepancies between FLYR and Opera.

Suggested Workaround
None required — this is a known timing discrepancy that typically resolves once both systems process the overnight adjustment.


11. Pick-Up Revenue for Routed Bookings

Description
For routed bookings, pick-up revenue may temporarily display on different dates than the actual posting.
Revenue may initially appear as removed from the origin booking (often on the check-in date) and later reappear under the destination booking on the correct stay date. This can cause temporary inflation until both bookings are updated, usually upon check-out.

Suggested Workaround
None. This is a limitation related to how Opera updates booking modification timestamps.


Summary

While FLYR’s integration with Opera Cloud captures the majority of operational and financial data, a few structural differences and API limitations can lead to persistent discrepancies. For more information on temporary discrepancies, check out this article.


By following the suggested workarounds above and adhering to Opera best practices (such as using routing instructions and canceling rather than deleting records), properties can significantly minimize data inconsistencies.

If you have any questions or encounter discrepancies not listed here, please reach out to our support team! We’re here to help ensure your reporting remains as accurate as possible.

Did this answer your question?