PMv2 - Booking status incorrect in owner statements

2 Votes Released
Alece
Jun 23, 2025 1:58 PM
Member for 6 years 343 posts

In the new PMv2, the Booking Status column for end of month bookings is now often incorrect. An example:

For the April statement on this property, the last booking's dates of stay are April 30-May 4th. Since the Owner Statement is run with the dates of April 1-30, that booking is included as it is partially within period. In PMv1, the Booking Status would show as Mid-Stay in this instance. However, now with PMv2 it shows as Pre-Arrival. This is both incorrect and incongruent with the underlying logic that is including the booking in the owner statement to begin with. By definition, "pre-arrival" implies that the booking did not begin during the period and therefore should not be included in the statement at all. 

Another example: 

In this instance, the last booking of the month was a one night stay, May 30-31. As the owner statement period is May 1-31, the booking is included here. In this case it is 100% within the period of the statement. However, the Booking Status column shows it as Mid-Stay. The In Period percentage column even shows that the stay 100% occurred in period. By that logic, Mid-Stay is incorrect as it's being reported and paid out in its entirety. In this instance, it should be listed as Post-Departure.

When I contacted OR about these logic incongruities in PMv2, I was told that "it's a feature not a bug" and operating as intended -- and encouraged to lodge a Feature Request in order to advocate for it to be changed. Please add your vote so we can get this fixed and return our owner statements back to having correct Booking Statuses shown.  

 

Bri
Dec 10, 2025 2:47 PM
OR Team Member Member for 4 years 689 posts

Hey Alece,

I think we've addressed this as of today. Next time you run your statements, please check it out and let us know.

Alece
Dec 10, 2025 3:13 PM
Member for 6 years 343 posts

Praise Be! Did a quick review of owner statements, and everything is correct now. Thank you, Bri and the rest of the OR team! 

Alece
Mar 5, 2026 1:55 PM
Member for 6 years 343 posts

Hey @Bri! This had been fixed, but there seems to have been a regression. 😩  I've got statuses showing as Mid-Stay again, while also displaying it as 100% in period. 

See the bottom row here as one example:

 

 

Bri
Mar 5, 2026 2:08 PM
OR Team Member Member for 4 years 689 posts

Hey @Bri! This had been fixed, but there seems to have been a regression. 😩  I've got statuses showing as Mid-Stay again, while also displaying it as 100% in period. 

See the bottom row here as one example:

 

 

by Alece – Mar 5, 2026 6:55 PM (UTC)

Thanks, Alece. Sorry for any frustration here. Let me pass this along to our escalation teams and see what's up.

Steven C
Mar 9, 2026 4:03 PM
OR Team Member Member for 4 years 55 posts

Hi Alece,

Thanks again for raising this and for the detailed examples. We spent some time internally reviewing the logic and talking it through.

The conclusion is that what you’re seeing is currently working as designed, even though I completely understand why it can feel inconsistent at first glance.

The key thing to keep in mind is that the Status column reflects the booking status as of midnight on the statement end date, while the “In Period %” column simply calculates how many nights of the stay fall within the statement range.

Another way to think about it is this:

  • Booking Status is determined using the actual check-in and checkout times.

  • In Period % is calculated based on the nights of the stay that fall within the statement period.

Using your first example:

Booking: April 30 – May 4
Statement period: April 1 – April 30

At midnight on April 30, the guest has not arrived yet, because check-in would normally occur later that day. Because of that, the system considers the booking Pre-Arrival from a status perspective.

However, the In Period % calculation is separate. It looks at which nights occur inside the statement range. Since the night of April 30 falls within the April statement period, the booking is included in the statement.

Your second example works similarly but on the departure side:

Booking: May 30 – May 31 (1 night)
Statement period: May 1 – May 31

At midnight on May 31, the guest has not checked out yet, since checkout would normally occur later that morning. Because of that, the system sees the booking as Mid-Stay at the moment the statement snapshot is taken.

At the same time, the In Period % column shows 100%, because the single night of the stay (May 30) occurs entirely within the May statement window.

So the two columns are answering slightly different questions:

Status
What was the booking status at midnight on the statement end date?

In Period %
What percentage of the booking’s nights fall inside the statement range?

It’s also worth noting that Booking Status is used in many other areas of the system, not just Owner Statements. Because of that, changing how this logic works is a bit more complex than it might initially appear and could have ripple effects elsewhere in the platform. As it currently stands, the status calculation is technically correct based on the check-in and checkout times.

That said, it’s also worth asking how important the Status column is on the statement itself. In many cases owners care more about how many nights fall in the statement period than whether the booking happened to be mid-stay or not at midnight on that date. If the Status column is creating confusion, you could simply remove it from the statement view.

Another idea we discussed internally would be adding a small help-text tooltip explaining that Status reflects the booking state as of the statement date, similar to how the In Period column already has help text indicating that it represents the percentage of nights occurring within the statement period.

I hope, the understanding of how these two columns work and represent different things, better explains why you are seeing this on your statements.

Appreciate you bringing thoughtful feedback like this. Conversations like this help us keep refining how these reports communicate the data.

Steve








Alece
Mar 16, 2026 2:27 PM
Member for 6 years 343 posts

Thanks for the clear explanation of the underlying logic, Steve — that helps clarify how the system is interpreting those values. Based on that explanation, I’ve added help text to the Status column title in my owner statements to provide some context for my owners.

For some additional context on why we need to use the Status column:

When a booking is canceled, the full number of nights from the original reservation still appears in the statement. The only way to indicate that the stay did not actually occur is through the Status column showing that the booking was canceled. That distinction is important for owners reviewing their statements. For example, an owner might see a booking that appears to span five nights, but only shows a small amount of revenue. Without the Status column indicating that it was canceled, it can look like the booking somehow generated unusually low income.

It’s already confusing that canceled bookings still (incorrectly) contribute to the occupied night totals on both the Owner Statements and the tax reports, so having the Status column helps provide at least some context for owners when reviewing those numbers.

At the moment, there isn’t another way on the Owner Statement to clearly signal that a booking was canceled. If there were a separate method to indicate a canceled booking, that would remove our need to rely on Status for that clarification.