Skip to main content

Ein sauber abgestimmtes Zusammenspiel von Stornobedingungen und Zahlungsrichtlinien ist der schnellste Weg zu verlässlichen Abläufen, weniger Rückerstattungen und einer besseren Gästeerfahrung. Indem ihr klare Regeln für Bestätigung, Check In Zeit/Ankunftsdatum und Check Out Zeit/Abreisedatum definiert und mit Vorautorisierungen sowie automatischen Abbuchungen kombiniert, belastet ihr Karten rechtssicher und pünktlich. Das gilt auch in komplexen Fällen mit OTAs und VCC (virtuellen Kreditkarten), bei denen Aktivierungsdaten und Ausnahmen den Takt vorgeben. In diesem Leitfaden findet ihr praxisnahe Blueprints und Guardrails, mit denen ihr eure Richtlinien in Mews strukturiert, Ausnahmen steuert und Doppelbelastungen vermeidet – kurz: weniger manuelle Arbeit, mehr Planbarkeit beim Zahlungseingang. 

 

Warum Richtlinien das Rückgrat eurer Abläufe sind 

  • Stornobedingungen und Zahlungsrichtlinien legen fest, wann Gäste stornieren dürfen und wann bzw. wie ihr Gelder einzieht – die Basis für verlässliche Front-Office- und Finanzprozesse. 

  • Mews belastet automatisch nur eine an der Reservierung hinterlegte Karte (nicht Karten, die ihr manuell nur im Kundenprofil speichert) – eure Automatisierung hängt also davon ab, wie Karten erfasst und an Reservierungen angehängt werden (Buchungsmaschine, OTA/Channel, Online-Check-in). 

Fundament bauen: klare Struktur, der euer Team vertraut 

  • Erstellt eindeutige Stornobedingungen pro Rate Group; nutzt „Max. Perioden für Gebühr“, um Nächte bei prozentualen Gebühren zu begrenzen, und definiert Gebührentyp (Prozentsatz/Fixbetrag), Gebührenumfang (Nächte/Produkte) und Frist. 

  • Konfiguriert bis zu vier Zahlungsrichtlinien pro Rate Group für Anzahlungen, Restzahlungen und Vorautorisierungen; definiert Trigger („Bestätigung“/„Check In Zeit“/„Ankunftsdatum“/„Check Out Zeit“/„Abreisedatum“), Offset, Action (belasten vs. vorautorisieren) und Typ (Automatisch vs. Manuell). 

  • Nutzt Vorautorisierungen für Incidentals, wenn ihr nicht im Voraus belasten wollt; Vorautorisierungen werden 24 Stunden nach eurer konfigurierten Check-out-Zeit automatisch freigegeben. 

  • Pro Reservierung gilt genau eine Stornobedingung; Mews verwendet die Regel, die am ersten Aufenthaltsdatum aktiv ist – so bleiben Bedingungen für Gäste und Team vorhersehbar. 

Best‑Practice‑Blueprints zum Übernehmen 

Direkt – Flexible BAR 

  • Stornobedingungen: Frei bis X Tage vor Anreise; danach Gebühr; bei Prozentsätzen optional Nächte begrenzen. 

  • Zahlung: 100 % bei „Ankunftsdatum“ minus X Tage (spiegelt eure Storno‑Frist), plus Vorautorisierung am Anreisetag für Incidentals. 

Nicht erstattbar 

  • Stornobedingungen: 100 % ab „Bestätigung“. 

  • Zahlung: 100 % bei „Bestätigung“ einziehen. 

Corporate/Rechnung 

  • Stornobedingungen: Gemäß Vertrag. 

  • Zahlung: „Vorautorisierung erstellen“ zur Anreise mit Typ = Manuell; euer Team entscheidet, ob/ wann eine Belastung erfolgt (für Schäden/Incidentals). 

Tipp: Setzt in Zahlungsrichtlinien den Umfang (Extent) korrekt (Nächte, Produkte, Weitere Ausgaben), damit automatisierte Beträge zu eurer Absicht passen; ändert ihr später enthaltene Posten, storniert Mews verbleibende geplante Regeln und erstellt eine Aufgabe für den manuellen Restabgleich. 

OTA- und VCC‑Realität: automatisieren ohne Überraschungen 

  • Bei OTA‑Buchungen mit VCC (virtueller Kreditkarte) folgt Mews dem vom Partner gesendeten Aktivierungsdatum; fehlt es, plant Mews die Belastung um 06:00 Uhr am Anreisetag, um Fehlversuche vor Aktivierung zu vermeiden. 

  • Mit VCC belastet Mews den vollen belastbaren Betrag; jede Vorautorisierungs‑Regel wird als Belastung behandelt (da der OTA im Merchant‑Modell bereits kassiert hat). 

  • Wenn ihr eine VCC manuell belastet und Positionen schließt, storniert die geplante Zahlung, um Doppelbelastungen zu vermeiden – die Automatisierung „weiß“ sonst nichts von eurer manuellen Abbuchung. 

Automatisierung zum Laufen bringen: Karten richtig anhängen 

  • Stellt sicher, dass Karten auf Reservierungsebene angehängt sind – über die Mews Buchungsmaschine, den Online‑Check‑in oder den OTA/Channel; Karten, die ihr nur im Kundenprofil hinzufügt, sind für automatische Belastungen nicht zulässig. 

  • Nutzt Zahlungsanforderungen (Payment Requests), um Kartendaten und/oder Zahlungen sicher per Link einzusammeln; die Daten werden tokenisiert und können gemäß euren Richtlinien belastet werden, sobald sie an der Reservierung hängen. 

Saisonalität & Events: Regeln ändern ohne Chaos 

  • Verwendet Richtlinien‑Ausnahmen für Peak‑Zeiten oder Events (z. B. strengere Gebühren an stark nachgefragten Wochenenden); Mews wendet dennoch eine einzige Regel pro Reservierung an – basierend auf der ersten Übernachtung – und hält das Ergebnis vorhersagbar. 

Operative Leitplanken gegen Stolperfallen 

  • Prüft vor einer geplanten Belastung, ob eine gültige reservierungsgebundene Karte vorhanden ist – besonders bei manuell erstellten/angepassten Buchungen; andernfalls läuft die Automatisierung nicht. 

  • Bei OTA‑Prepaid‑Stays vermeidet es, Gäste kurz vor Anreise zum Hinterlegen einer persönlichen Karte aufzufordern, außer ihr wollt diese verwenden; habt ihr die VCC bereits belastet, storniert die geplante Regel, um Doppelbelastungen zu verhindern. 

So funktionieren Stornobedingungen in Mews (Kurzüberblick) 

  • Ihr konfiguriert Stornobedingungen unter Einstellungen > Richtlinien: wählt Prozentsatz oder Fixbetrag, den Gebührenumfang (Nächte/Produkte), eine Frist (z. B. X Tage vor Anreise) und optional maximale Nächte für prozentuale Gebühren. 

  • Pro Reservierung gilt genau eine Stornobedingung – jene, die am ersten Aufenthaltsdatum aktiv ist; Gäste sehen sie beim Buchen und im Guest Portal, euer Team in der Aktionschronik der Reservierung. 

Schnelle Checkliste 

  • Storno‑ und Zahlungs‑Timing angleichen (gleiche Cut‑off‑Logik), um Rückerstattungen und Streitfälle zu reduzieren. 

  • Extent in Zahlungsrichtlinien korrekt halten (Nächte, Produkte, Weitere Ausgaben) und Mid‑Stay‑Änderungen vermeiden, die geplante Regeln invalidieren. 

  • VCCs als eigenen Flow behandeln: Aktivierungsdatum zuerst, Fallback 06:00 am Anreisetag, Vollbetrags‑Belastung, Vorautorisierungen als Belastung behandeln. 

  • Karten über Buchungsmaschine/Online‑Check‑in/Zahlungsanforderungen einsammeln und an die Reservierung anhängen, damit Automatisierung rechtssicher und zuverlässig greift. 

Hallo!

Super Artikel, Danke für die Aufdröselung!

Bezüglich VCCs allerdings würde ich es begrüßen, wenn man einstellen könnte (je OTA am besten) dass VCCs gleich bei Buchungseingang belastet werden (so wie das bis 9/2024 war). So haben wir jede Menge manuelle Arbeit um die VCCs manuell zu belasten! Wir haben mit den OTAs mit VCCs ja mit Absicht vereinbart, dass wir gleich belasten dürfen - bis 9/2024 hat das auch bestens funktioniert - dann wurde das ohne Vorwarnung und Info umgestellt, was unseren CashFlow ganz schön durcheinander gebracht hat, bis wir das bemerkt haben…und nun täglich x-mal Abbuchungen und Deposits manuell bearbeiten dürfen :-(

 

LG,

JP.


Hi ​@povilas.juska,

gibt es diesen Artikel auch auf Englisch? 🙈

Danke dir und liebe Grüße
Svenja


Und: Gibt es mittlerweile eine Lösung dafür, dass in den Rate descriptions (was der Gast sieht, wenn er bucht und was auf der Reservierungsbestätigung steht) ein fixer Text mit den Infos zu Cancellation und Payment policies steht, welcher nicht reflektieren würde, wenn ich in der Ratengruppe zu bestimmten Zeitpunkten eine vom Standard abweichende Cancellation/Payment Policy festlege? Sonst steht im “Beherbergungsvertrag” ja was anderes, als wir im System haben und der Gast hat natürlich ein Anrecht auf das was er gebucht hat..


Hi ​@Svenja ,

 

ich habe dir gerade die englische Version des Artikels geschickt.

 

Zu deiner zweiten Frage: Leider sehe ich diese Entwicklung derzeit weder auf unserer Roadmap noch als Vorschlag im Mews Product Ideas Forum.

Ich möchte dich daher herzlich einladen, das Thema dort einzureichen, damit es für zukünftige Entwicklungen berücksichtigt werden kann.

 

Vielen Dank,

Povilas


@povilas.juska danke dir!

Das hatte ich damals bei der ersten Vorstellung zum Beta Testen schon an Nienke als Feedback gegeben und war der Grund, wieso das Feature bisher nicht nutzbar war.

Liebe Grüße
Svenja


Hello, Agree with Svenja.

We have also raised this to Mews from several properties so the feedback has been provided multiple times. Guests need to see the cancellation policy on their confirmations, entering this information in the rate description does not work if you use policy exceptions.

The cancellation tag that shows on the booking engine should also show on the email communication. 


And do I understand correctly, that so far, this can only be used, for Mews Booking Engine Bookings, right? Because rates that are mapped to CHM’s/OTA’s, don’t get the information, that the policy on this rate has changed either?


Hi ​@Svenja ,

 

ich habe dir gerade die englische Version des Artikels geschickt.

 

Zu deiner zweiten Frage: Leider sehe ich diese Entwicklung derzeit weder auf unserer Roadmap noch als Vorschlag im Mews Product Ideas Forum.

Ich möchte dich daher herzlich einladen, das Thema dort einzureichen, damit es für zukünftige Entwicklungen berücksichtigt werden kann.

 

Vielen Dank,

Povilas

 

Hallo ​@povilas.juska !

Es gibt im Product Feedback Forum sehr wohl Einträge zu dem Thema!

Ich denke was ​@Svenja meint ist ganz gut in diesem Eintrag beschrieben:

https://feedback.mews.com/forums/955598-guest-experience/suggestions/40307233-include-cancellation-policies-in-reservation-confi

Das ist allerdings als “released” markiert, da man ja im neuen Email Design Modul die Cancellation policy anzeigen lassen kann - Ich habe es nicht getestet, da wir die Funktion nicht verwenden, aber was manche Anwender meinen dürften ist, dass die Policy nicht korrekt angezeigt wird wen es eine zeitweises Überschreiben (Override) der mit der Rate verknüpften Default policy gibt … stimmt das?

Es gibt auch einen weiteren Eintrag unter https://feedback.mews.com/forums/918232-property-operations-pms/suggestions/50166651-cancellation-policy-overwrites-improvement-bug-f

Der das gleiche beschreinbt...

LG,

JP.

 


Vielen Dank für die Zusammenfassung


Hi ​@Sam.C, when using the new E-Mail templates, the cancellation policy is in fact mirrored on the confirmation letter. One thing to keep in mind, however, as ​@j.spiess mentioned, the Confirmation letter will pick up and display the Cancellation policy that is applicable on the day of arrival. 

When considering overlapping cancellation policies (exceptions) within a single reservation, as described in ​@j.spiess Ideas Forum example, it is certainly something to be explored further.

 

As for sending cancellation policies to OTAs, CHMs, this is not something that is supported. Those cancellation policies need to be mirrored directly within the configurations of each channel independently.