At FLYR, we work to ensure a reliable and accurate integration between Apaleo and FLYR. That said, certain structural characteristics of how Apaleo organises and exposes data can result in instances where figures between the two systems don't fully align.
If any of these discrepancies were identified during your onboarding process, our team would have proactively flagged and discussed them with you.
Below is a detailed overview of known data gaps, their causes, and suggested workarounds.
1. Revenue posted via 3rd 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 PMS–FLYR data discrepancy: data not matching.
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.