Paymaster reservations — often called PM rooms or pseudo rooms — are one of the most common reasons revenue in FLYR looks different from what you expect. This article explains what they are, how FLYR handles them, and what to check when numbers don't line up.

Opera requires every charge to sit on a reservation, and it won't let you check a guest out with an unpaid bill. But hotel life doesn't always cooperate: a guest leaves early and settles later, a company pays a group's invoice at month end, or a minibar charge turns up after check-out.

That's what PM rooms are for. A PM is a placeholder room type with no physical inventory. When charges need to wait for payment, staff move them to a reservation on a PM room, where they sit until the bill is settled. Moving revenue this way is called routing.

FLYR identifies PM reservations by their room type. Each property's PM room type codes are configured during onboarding, so the integration knows which reservations are placeholders rather than real stays.

Revenue on a PM reservation is treated in a specific way: it counts as revenue, but never as occupancy. A PM has no room and no guest, so it must never inflate your occupancy or dilute your ADR. This applies to room revenue moved onto PMs — the revenue type FLYR focuses on, because room revenue is what drives forecasting and pricing.

FLYR's goal is simple: show real room revenue on the room that earned it. Revenue sitting on a PM tells you nothing about which room type, rate plan, or segment produced it — so wherever possible, FLYR puts it back.

One thing matters more than anything else in this article: restoring routed revenue is a reconstruction, not a replay. Opera doesn't tell FLYR exactly which charge came from which night on which reservation. FLYR works from the routing links and reservation history it receives, and rebuilds the most accurate picture possible.

In the great majority of cases, that picture matches Opera. In edge cases — revenue moved several times, reservations changed after routing, or links removed in Opera — the reconstruction lands close but not identical. Your totals stay right; the split across rooms, dates, or dimensions may be approximate.

This is the most common PM question, and it comes down to timing. Opera sends FLYR updates about the original reservation and the PM separately, and they don't always arrive together.

Both situations resolve on their own once the other side's update arrives, which often happens at the next nightly audit or at check-out. If a mismatch persists, contact FLYR support — a data refresh for the affected reservations resolves most cases within the day.

PM reservations are placeholders, so they rarely carry meaningful dimensions of their own. Revenue moved onto a PM often arrives without a rate plan, segment, or channel — which is why it appears as undefined or unmapped in Insights.

Dimensions can also appear to change. When FLYR traces routed revenue back to its origin, that revenue leaves the undefined bucket and reappears under the original reservation's dimensions. That's the system working as intended: the revenue didn't disappear, it moved home.

Pickup compares what was on the books at two points in time — so anything that changes revenue for past dates changes pickup too.

When routed revenue is restored to its origin, or arrives late from a PM, revenue for dates that already passed can be restated. You may see pickup for a closed period shift days after the fact. This is expected: FLYR is incorporating information Opera delivered late, and the restated figures are the more accurate ones.

Properties that keep PMs open for long periods see this most. The longer a PM accumulates charges after the original stay dates, the more history gets restated when those charges finally resolve.

Opera's routing feature creates a traceable link. Manual transfers and manual postings don't. When revenue is moved by hand — from a room to a PM, between rooms, or between PMs — Opera records no connection to the origin. FLYR receives the revenue, keeps it in your totals, but has no way to restore it to the reservation that earned it. It stays under Undefined room type permanently.

No data refresh can fix this, because the information never existed. This is the one category of PM discrepancy that prevention solves and nothing else does.

Four habits keep PM-related noise close to zero:

Still seeing something that doesn't add up? Share the reservation numbers and dates with FLYR support and we'll trace it with you.