Revenue protection.
Built into daily operations.

Risk: A room being occupied without a valid booking creates both a security problem and a revenue-control gap.

How Staycore controls it: Room access requires an active booking. Access cannot simply be issued independently of the recognised stay.

Prevent: Blocks room access where there is no active booking.

Detect: An invalid booking/access relationship fails validation rather than silently proceeding.

Reconcile: The room being accessed is connected to the recognised stay.

Audit: Access remains attributable to the relevant booking and guest context.

Risk: Incorrect guest details being used to obtain access intended for another guest.

How Staycore controls it: Guest identity information is validated as part of the room-access process.

Prevent: Incorrect identity information is rejected.

Detect: Identity mismatches are recognised when access is requested.

Reconcile: The person requesting access is checked against the stay context.

Audit: The resulting access decision remains associated with the validated booking context.

Risk: A guest changes rooms but the previous access route remains active.

How Staycore controls it: The access relationship follows the current stay when a room move occurs.

Prevent: The obsolete room route is retired.

Detect: The previous room relationship is no longer treated as current.

Reconcile: The guest's access is aligned with the newly assigned room.

Audit: The stay maintains a coherent history of the room relationship.

Risk: Someone with limited information about a guest obtaining their mobile room key.

How Staycore controls it: A surname alone is insufficient to retrieve a mobile key.

Prevent: Weak verification cannot obtain the key.

Detect: Insufficient authentication is rejected.

Reconcile: Key entitlement is evaluated against the wider stay/session context.

Audit: Key issuance remains connected to an authorised stay.

Risk: Possession of a booking reference or token being treated as proof of guest identity.

How Staycore controls it: A booking token alone cannot retrieve a loyalty member's mobile key.

Prevent: Additional valid context is required.

Detect: Insufficient credentials fail the access check.

Reconcile: The request is checked against both booking and member context.

Audit: Successful key issuance remains attributable to the validated context.

Risk: Credentials from an earlier stay being reused to access a room later.

How Staycore controls it: Room credentials are tied to the relevant stay and cannot simply carry forward to another booking.

Prevent: Old credentials cannot authorise a later stay.

Detect: Stale credentials are recognised as invalid.

Reconcile: Credential entitlement is aligned with the current booking.

Audit: Credential usage remains associated with the stay for which it was issued.

Risk: One property accessing or controlling locks belonging to another property.

How Staycore controls it: Front-desk lock operations remain scoped to the appropriate property.

Prevent: Cross-property lock operations are blocked.

Detect: An incorrect property relationship fails validation.

Reconcile: Lock activity is evaluated within the correct property.

Audit: Activity remains attributable to that property.

Risk: Automated room assignment accidentally allocating a room already reserved for another guest.

How Staycore controls it: Reserved rooms are excluded from random room assignment.

Prevent: Conflicting room allocation is blocked.

Detect: Reservation state identifies unavailable rooms.

Reconcile: Assignment is performed against current reservation state.

Audit: The resulting room allocation remains connected to its booking.

Risk: Guests being offered online prepayment that the property cannot process.

How Staycore controls it: Online prepayment requires a configured payment processor.

Prevent: Stops an unconfigured property from offering online prepayment.

Detect: Identifies a missing processor configuration before the payment journey proceeds.

Reconcile: Keeps the offered payment route aligned with the property's processing configuration.

Audit: Provides the payment-route configuration as context for reviewing collection readiness; this control does not describe a separate audit event.

Risk: A prepaid booking condition existing without a way to collect payment.

How Staycore controls it: A non-refundable prepaid booking creates a payment link.

Prevent: Reduces the gap between requiring prepayment and providing a collection route.

Detect: Makes the collection route available for review; creating a link does not establish that payment was received.

Reconcile: Connects the booking's prepaid condition to its payment link.

Audit: The booking and associated collection route provide context for reviewing how prepayment was requested.

Risk: A transaction appearing payable when the property has no valid collection route.

How Staycore controls it: Pay-now requests are rejected when no payment processor is configured.

Prevent: Blocks pay-now without a configured processor.

Detect: Recognises the missing processor when pay-now is requested.

Reconcile: Checks the requested payment action against the property's processing configuration.

Audit: The configuration and rejected action explain the control decision; a separate audit record is not specified by this control.

Risk: Provider-reported money remaining disconnected from the originating payment.

How Staycore controls it: Payment-provider references are used to create matched settlement cases.

Prevent: Reduces unsupported settlement attribution by using the provider reference for matching.

Detect: Matching establishes whether a provider reference corresponds to a Staycore payment.

Reconcile: Connects the expected payment, provider transaction, and settlement.

Audit: The matched settlement case provides a record of the payment-to-settlement relationship.

Risk: Differences between expected payments and provider settlements being overlooked.

How Staycore controls it: Settlement imports are classified as matched or variance outcomes.

Prevent: Keeps a settlement difference from being treated as a matched outcome.

Detect: Surfaces settlement variances for management investigation.

Reconcile: Compares Staycore's expected payment information with the provider's settlement information.

Audit: The classified settlement case provides context for reviewing the exception; resolution audit is covered by control 15.

Risk: One external payment reference appearing as multiple independent payments.

How Staycore controls it: Duplicate payment-provider references are identified.

Prevent: Helps prevent a duplicate reference from being mistaken for an independent payment; this control describes detection, not rejection.

Detect: Identifies repeated provider references.

Reconcile: Enables repeated references to be checked against the originating provider transaction.

Audit: The identified duplicate provides a reference for investigating repeated payment entries.

Risk: A reconciliation exception being closed without evidence of its resolution.

How Staycore controls it: Resolving a reconciliation exception changes its status and writes an audit record.

Prevent: Prevents resolution from being an unrecorded status change.

Detect: Makes the resolved status and recorded action available for review.

Reconcile: Connects the exception's resolution to its reconciliation case.

Audit: Preserves the status change and audit evidence of the resolution.

Risk: Payment revenue being attributed to the wrong property.

How Staycore controls it: A payment reference belonging to another property remains unmatched.

Prevent: Prevents a reference from another property from creating an incorrect match.

Detect: Recognises that the reference does not belong to the property being reconciled.

Reconcile: Keeps payment matching within the correct property.

Audit: The unmatched outcome preserves the distinction needed to investigate attribution.

Risk: Duplicate corporate payment postings incorrectly reducing an account balance.

How Staycore controls it: Duplicate corporate invoice payment references are rejected.

Prevent: Blocks duplicate posting of the same corporate payment reference.

Detect: Identifies a duplicate reference when a corporate payment is submitted.

Reconcile: Keeps invoice payment posting aligned with distinct payment references.

Audit: The payment reference provides a basis for reviewing postings; this control does not specify a separate rejection audit event.

Risk: Corporate balances being changed through invisible credits, debits, or write-offs.

How Staycore controls it: Corporate credits, debits, and write-offs generate audit evidence.

Prevent: Discourages untraceable account adjustments by preserving evidence of the action.

Detect: Makes material account adjustments available for review.

Reconcile: Supports comparison of balance changes with the recorded financial actions.

Audit: Retains evidence of corporate credits, debits, and write-offs.

Risk: Old POS drafts being confused with current sales activity.

How Staycore controls it: Expired POS drafts are removed from the active work queue.

Prevent: Keeps expired drafts out of the current operational queue.

Detect: Recognises drafts whose active transaction window has expired.

Reconcile: Aligns the active queue with current transaction state.

Audit: Queue removal is not an audit guarantee; this control concerns active-work visibility.

Risk: An expired POS draft being revived and completed outside its intended context.

How Staycore controls it: Expired POS drafts cannot be completed.

Prevent: Blocks completion of a stale transaction.

Detect: Recognises expiry when completion is attempted.

Reconcile: Checks transaction eligibility against the draft's current state.

Audit: The expiry state explains why completion is invalid; a separate audit event is not specified by this control.

Risk: Staff reducing a bill while representing their own approval as manager authorisation.

How Staycore controls it: A waiter cannot create or self-approve the manager authority required for a protected discount.

Prevent: Blocks self-authorisation of a manager-protected discount.

Detect: Recognises that the operator lacks the required manager authority.

Reconcile: Checks the requested discount against the required approval boundary.

Audit: The authority boundary supports review of discount authorisation; this control does not specify a separate approval-history record.

Risk: Order amendments reopening completed activity or creating duplicate settlement.

How Staycore controls it: Kitchen Order Ticket amendments preserve completed tickets and settle the transaction once.

Prevent: Prevents amendments from duplicating settlement or reopening completed tickets.

Detect: Distinguishes completed tickets from activity that remains open to amendment.

Reconcile: Keeps the amended order, completed tickets, and single settlement consistent.

Audit: Preserves completed tickets as evidence of fulfilled order activity.

Risk: A restaurant transaction being financially closed while a kitchen order remains unresolved.

How Staycore controls it: A full-service restaurant tab cannot settle while a Kitchen Order Ticket remains open.

Prevent: Blocks settlement while an associated kitchen ticket is open.

Detect: Recognises unresolved kitchen tickets at settlement.

Reconcile: Checks fulfilment state before allowing the tab to settle.

Audit: The ticket and tab states provide context for reviewing why settlement was blocked.

Risk: Served but unpaid restaurant transactions disappearing from operational attention.

How Staycore controls it: Completed unpaid tabs are surfaced and can be returned to the operational workflow.

Prevent: Keeps an unpaid obligation from disappearing solely because service is complete.

Detect: Surfaces completed tabs that still require payment.

Reconcile: Separates fulfilment completion from payment completion and returns outstanding work to the team.

Audit: The visible unpaid tab provides transaction context for follow-up and investigation.

Risk: Another operator modifying or completing an offline draft they did not originate.

How Staycore controls it: Offline POS transactions remain tied to their originating operator.

Prevent: Blocks other operators from modifying or completing the draft.

Detect: Recognises an operator mismatch when the draft is acted on.

Reconcile: Checks the acting operator against the draft's ownership.

Audit: Preserves operator attribution while the transaction is offline.

Risk: A POS synchronisation channel being used to introduce sensitive refund or back-office actions.

How Staycore controls it: POS terminal synchronisation cannot inject refund or back-office events.

Prevent: Blocks sensitive event types from entering through ordinary terminal synchronisation.

Detect: Recognises events that are outside the channel's permitted scope.

Reconcile: Checks synchronised events against the actions allowed through the POS channel.

Audit: The channel boundary supports investigation of event origin; this control does not specify a separate rejection log.

Risk: Raw operator PINs being exposed while authenticating POS staff.

How Staycore controls it: Operator PINs are verified without storing the raw PIN.

Prevent: Avoids retaining raw PINs that could expose operator credentials.

Detect: Verifies whether the supplied PIN satisfies the operator authentication check.

Reconcile: Connects successful authentication to the relevant operator context.

Audit: Supports attribution of transactions to authenticated staff without retaining the raw credential.

Risk: Paid restaurant tabs disappearing from management visibility after completion.

How Staycore controls it: Paid tabs leave the active queue but remain in manager history.

Prevent: Prevents operational completion from erasing the tab's management history.

Detect: Allows managers to find completed paid tabs during review.

Reconcile: Separates active operational work from completed transaction history.

Audit: Retains paid tabs in manager history.

Risk: One employee exercising unrestricted authority across the purchasing lifecycle.

How Staycore controls it: Purchase-order transitions enforce separation of duties.

Prevent: Blocks transitions that breach the required authority boundaries.

Detect: Recognises when an actor does not meet a transition's authority requirements.

Reconcile: Checks the actor's authority against the purchase order's lifecycle transition.

Audit: The enforced boundaries support review of purchasing responsibility; this control does not specify a separate transition audit event.

Risk: Ordinary users bypassing purchasing controls to introduce stock.

How Staycore controls it: Goods received outside the normal purchase-order route require owner or administrator authority.

Prevent: Blocks unauthorised receipt through the unplanned stock route.

Detect: Recognises when the receiving user lacks the required authority.

Reconcile: Checks the receipt route against the authority required to use it.

Audit: The authorised receipt provides context for investigating stock received outside the normal purchasing route.

Risk: Actual purchase prices differing from management expectations without attention.

How Staycore controls it: Staycore applies purchase-price variance rules.

Prevent: Reduces the chance of a price difference remaining unnoticed; this control does not describe a purchasing block.

Detect: Surfaces differences between expected and actual purchase prices under the applicable variance rules.

Reconcile: Compares the purchasing price with the expected price.

Audit: The price difference provides context for reviewing purchasing decisions and recurring variances.

Risk: Supplier charges differing from what was ordered or received.

How Staycore controls it: Supplier invoices are reconciled against purchasing and goods-received records.

Prevent: Reduces the chance of discrepancies being overlooked during invoice review; this control does not describe an automatic payment block.

Detect: Makes differences between ordering, receiving, and invoicing visible.

Reconcile: Connects what was ordered, what arrived, and what the supplier asks to be paid.

Audit: The connected purchase, receipt, and invoice records provide evidence for investigating discrepancies.

Risk: Stock reductions being recorded without an explainable reason.

How Staycore controls it: Inventory wastage adjustments retain a standardised reason.

Prevent: Keeps wastage reductions from being recorded without the reason retained by this control.

Detect: Allows recurring wastage reasons to be reviewed for patterns.

Reconcile: Connects the stock reduction to its recorded wastage reason.

Audit: Preserves the standardised reason as part of the inventory record.

Risk: Inconsistent local permission checks granting unintended inventory authority.

How Staycore controls it: Inventory actions are evaluated against Staycore's central role model.

Prevent: Blocks inventory actions outside the user's centrally defined authority.

Detect: Recognises actions that do not satisfy the central permission model.

Reconcile: Aligns inventory permissions with the organisation's role definitions.

Audit: The central role model provides the authority context for reviewing inventory actions; this control does not specify a separate action log.

Risk: Hardware removal destroying bound access relationships or important history.

How Staycore controls it: Managers can decommission locks but cannot simply delete bound access points.

Prevent: Blocks deletion of bound access points through the manager's operational authority.

Detect: Distinguishes permitted decommissioning from restricted deletion.

Reconcile: Keeps hardware lifecycle actions aligned with existing access relationships.

Audit: Allows hardware to be taken out of service while protecting important relationships and history.

Risk: Deleting a lock erasing evidence of historical access activity.

How Staycore controls it: Lock deletion preserves relevant historical attendance and provider-resolution records.

Prevent: Prevents hardware deletion from erasing the historical records covered by this control.

Detect: Keeps historical activity available for investigation after hardware changes.

Reconcile: Retains the historical context needed to relate earlier activity to its records.

Audit: Preserves relevant attendance and provider-resolution history after lock deletion.

Risk: Repeated or interrupted hardware setup creating duplicate or inconsistent access state.

How Staycore controls it: Hardware provisioning is designed to complete consistently, tolerate repeated attempts, and avoid unnecessary secret exposure.

Prevent: Protects against duplicate or partial provisioning state and unnecessary exposure of secrets.

Detect: Interrupted or repeated setup is handled through provisioning safeguards; a separate exception alert is not specified.

Reconcile: Keeps the resulting access-control state consistent across setup attempts.

Audit: Consistent provisioning state supports later review; this control does not specify a separate provisioning audit record.

Risk: Mobile keys distributing sensitive hotel credentials that guests do not need.

How Staycore controls it: Mobile-key payloads contain only information required for the access process.

Prevent: Avoids unnecessarily distributing sensitive credentials with a mobile key.

Detect: Payload scope can be reviewed against access requirements; this control does not describe an exposure alert.

Reconcile: Aligns the information sent with the needs of the access process.

Audit: The limited payload scope supports review of what is distributed; this control does not specify a separate issuance log.

Risk: A senior operational title being treated as unrestricted system authority.

How Staycore controls it: Senior operational roles retain their defined permission boundaries.

Prevent: Blocks actions outside the authority granted by the organisation's permission model.

Detect: Recognises requests that exceed the senior role's defined permissions.

Reconcile: Checks each action against the applicable role boundaries.

Audit: The role definition provides context for reviewing authority; this control does not specify a separate permission-decision log.

Risk: Historical records losing reliable references to operational entities over time.

How Staycore controls it: Property-state snapshots retain stable audit identifiers.

Prevent: Prevents identifier instability from undermining the historical references covered by this control.

Detect: Stable identifiers support investigation across snapshots; this control does not describe automatic anomaly detection.

Reconcile: Allows records from different points in time to refer to the same operational entities.

Audit: Preserves stable identifiers so historical evidence remains traceable and useful.