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 Apaleo — 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 Apaleo 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.
Validating data against Apaleo reports
Pull the General Manager Report in Apaleo, using net values throughout, 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 discrepancy with our support team, also include the Revenues Report pulled for the specific day in question.
1. Revenue posted via third-party interfaces
Description
Some properties use third-party interfaces — such as Make or similar automation tools — that automatically route postings between folios in Apaleo. When charges are posted to a folio by one of these interfaces rather than directly via a standard reservation flow, FLYR may not capture that revenue unless a specific configuration flag is enabled on the adapter side.
This has been confirmed as a recurring cause of revenue discrepancies, where Apaleo shows a higher total than FLYR because charges routed to secondary folios (e.g., Folio 2 for OTA reservations) are not being picked up.
Suggested workaround
If your property uses a third-party interface that routes postings between folios, contact our support team. We can configure your property to make sure these charges are captured correctly. A data resync will typically be required after the configuration is applied.
2. Channel data is not available for group blocks
Description
In Apaleo, channel information is only available at the individual reservation level, not at the group block level. As a result, group blocks themselves will not carry a channel name in FLYR. Channel data only becomes visible once rooms from the block are picked up and individual reservations are created.
This means that for any revenue or occupancy attributed to a group block before pickup, the channel will appear as blank or unknown in FLYR — even if the block has a channel assigned in Apaleo.
Suggested workaround
This is a structural limitation in how Apaleo exposes group data via the API. No workaround is currently available. Channel attribution for group business will be visible in FLYR once individual reservations are picked up from the block.
3. Day use bookings on night use rate codes cause occupancy discrepancies
Description
Apaleo and FLYR calculate occupancy differently for day use stays. In FLYR, a unit is counted as occupied for a night if it is used at any point during that night. In Apaleo, if a day use booking and a night use booking occur in the same unit on the same night, Apaleo counts it as one occupied unit — because the unit was occupied, regardless of how many guests used it.
If a property books day use reservations on a night use rate code instead of a dedicated day use rate code, this discrepancy becomes systematic and will cause occupancy figures to differ between the two systems.
Suggested workaround
Ensure that day use reservations are booked against a dedicated day use rate code in Apaleo. This allows both systems to calculate occupancy consistently and avoids persistent discrepancies in unit counts.
Summary
FLYR's integration with Apaleo captures the majority of operational and financial data accurately. The scenarios above reflect specific structural characteristics of Apaleo that can produce persistent discrepancies. Following the suggested workarounds will significantly reduce data differences between the two systems.
For information on temporary discrepancies, see Data Validation against PMS Reports. If you have any questions or encounter a discrepancy not listed here, reach out to our support team. We're here to keep your reporting as accurate as possible.