Top-ups above the folio amount: why guests see a larger, longer-lasting hold

What this article covers

Sometimes a guest checks out, pays their bill in full, and still finds an amount blocked on their card that's larger than what they actually spent — and it stays blocked for longer than expected. This article explains one specific, fixable cause: a top-up during the stay that was set higher than the final folio balance.

If a guest's blocked amount roughly matches their final bill and they're just waiting for it to clear, that's normal release timing — see Pre-authorisations and top-ups: why released funds take time to appear instead.

How a pre-authorisation actually works

1. The hold is placed. When a card is pre-authorised (at check-in) or topped up (during the stay), the request passes through the card network — Visa or Mastercard — to the guest's card-issuing bank. The bank reserves that amount against the guest's available balance.
2. The hold is released. When the hotel closes it out, 934 AG's Gateway sends a release instruction back through the network to the issuing bank.
3. The bank decides when the funds reappear. Timing here is entirely up to the guest's own bank, and neither the hotel, the Gateway, nor the card schemes can speed it up.

That mechanism is unavoidable. What is avoidable is how large a hold is left sitting in that pipeline at checkout — which is what this article addresses.

The specific problem: top-up exceeds the folio

During a stay, a hotel system may top up the pre-authorisation to cover charges as they're added to the guest's folio (extra nights, room service, minibar, and so on). If that top-up is set to a round or estimated figure that's higher than what the guest's final folio actually comes to, the gap between the two doesn't just disappear at checkout.

Example: A guest's top-up is raised to €500 to comfortably cover expected incidentals, but their actual folio only comes to €310. At checkout, the €310 is settled — but the remaining €190 doesn't automatically fall away. It has to go through the normal release process, meaning the guest has €190 blocked on their card for money they never spent, on top of however long their bank takes to release it.

The larger the gap between the top-up and the actual folio, the larger the amount sitting unnecessarily blocked, and the more likely a guest is to notice and query it.

The workaround

Configure the hotel system so that top-ups only ever raise the pre-authorisation to match the current folio balance — not a round-number buffer above it. Done this way, the final top-up at or near checkout should already equal what the guest owes, so settling the folio consumes the hold in full and leaves nothing extra to release.

This is a PMS/hotel-system configuration, not something 934 AG's Gateway controls. 934 AG's Gateway processes whatever top-up amount and timing the hotel system sends — it has no way to cap or adjust that amount on its own. If a hotel is seeing this pattern regularly, they'll need to raise the top-up logic with their PMS provider or Oracle SI (Opera Cloud, Opera V5, or Simphony configuration is outside 934 AG's support scope) to have it adjusted so top-ups track the folio rather than a fixed estimate.

What to tell a guest

If a guest's blocked amount is clearly higher than their final bill:

"I can see that's larger than what you paid — that happens when the hold placed during your stay was set a bit higher than your final bill turned out to be. The extra amount isn't a charge, it's just an unused portion of that hold, and it'll be released the same way the rest of it is. I'll flag this with the team so we can look at how the top-up amount is being set for future stays."

What to raise internally

If you notice this pattern — guests with blocked amounts noticeably above their folio total — flag it to your PMS/SI contact as a configuration issue, not a one-off. It's the kind of thing that's easy to fix at the source but keeps generating guest queries until it is.

What's out of scope here

This article covers the top-up-exceeds-folio scenario only. It does not cover:

• Standard release timing once a hold matches the folio (see the related article above)
• Disputed or incorrect charge amounts
• Refunds for completed transactions
• PMS/SI configuration steps themselves (raise with the hotel's Oracle SI or PMS provider)