When choosing a PMS, do not judge an after-midnight entry by its displayed time alone. Follow the same fictional event through two reports using calendar date, business day and service consumption date. Then ask which period changes after a correction the next day. Acceptance means explaining differences through records and filters, rather than requiring identical report totals. Independent hotels, boutique properties and apartment operators can use this three-event scenario under the same conditions with each supplier, comparing an explainable daily closing process rather than an attractive report screen.
Write a date dictionary and report scope first
Specify the property's local time zone for calendar dates. Ask the supplier to document the business-day definition, transition conditions and authorized role. Consumption date identifies when the service belongs in this scenario. Do not assume these are one field. Record the filtered date field, period boundaries, currency and included record statuses beside each report name. If one report counts reservations and another counts processed entries, separate those scopes before comparing totals.
The public documents provide context: Oracle OPERA Cloud 24.1 conditions business-date advancement; Mews distinguishes consumption and accounting dates. Both were checked on 22 October 2026 and concern their respective products. They do not establish another candidate's behavior or a Stayax capability. Record the demonstrated version and active settings. Where terminology differs, add the supplier's labels to the dictionary; decide from demonstrated behavior.
A three-event demo acceptance card
All dates, times and amounts below are fictional. This exercise models no tax, payment or statutory accounting practice. Use one reservation and one service entry at a time in an empty training environment to isolate date behavior. Ask which actions are supported before trying them. Keep both selected reports' filters visible and save results after each step.
- Event A — 21 October, 23:50: record a service worth 100 units belonging to 21 October. Note the record ID, local time, service date, displayed business day and row in each report. Preserve the initial output.
- Event B — 22 October, 00:10: try adding a second service worth 40 units for 21 October to the same reservation. If rejected, record the rejection and permitted route. If accepted, show which day receives it in each report; do not assume the previous day.
- Event C — 22 October, 10:00: request a correction of A from 100 to 90. Record the permitted method, affected record, correction date and before/after results in both reports. Do not require deletion or overwriting of the original row.
For each event, add the acting role, filter, observed result and unresolved question. A missing permission is not proof that a feature is absent: request another demonstration with an authorized role. Keep separate results where a repeat before and after business-day advancement is needed. These times are test inputs, not a recommended closing schedule; adapt them to your property's shifts.
Check the total and explain the period separately
With only these two accepted services, the fictional total before correction is 100 + 40 = 140 units. Reducing A by 10 produces 90 + 40 = 130. This assumes both services were accepted and no other entries exist. Adjust the expected total if an action was rejected. The 130 need not fall on the same day in both reports: request a bridge showing each row's date filter. Keep amount reconciliation separate from period reconciliation.
Ask to compare the changed output with the saved original. The explanation should identify the record, date field and correction route. Choose which report management will use for daily operations instead of forcing undocumented equality. Assess local accounting and legal period requirements separately with your authorized adviser.
Make a decision in three categories
Accept when all three events are shown, dates are defined and amount/period differences are explained at record level. Accept conditionally when the behavior is understood but a setting, permission or repeat demonstration remains open; assign an owner and due date. Hold the decision when differences remain unexplained or only verbal assurances are offered. A tick on a feature list cannot replace this evidence.
Keep the version, settings, report names, event results and remaining dependencies on one decision sheet. Compare candidates with the same scenario and equivalent report detail. Use the PMS outage-and-return demo guide to examine reporting continuity, and the room-move demo guide to test the trace of an in-stay change. The next meeting can then resolve the exact date or report discrepancy still open on the card.