Τιμολόγια OTA σε ελληνικά ξενοδοχεία: καταχώρηση

Τα τιμολόγια προμήθειας OTA από Booking.com, Expedia και Airbnb για ελληνικά ξενοδοχεία δεν αντιμετωπίζονται όπως ένα συνηθισμένο ελληνικό τιμολόγιο προμηθευτή. Στην πράξη, καταχωρούνται ως έξοδο προμήθειας ή διανομής, ελέγχονται για reverse charge ΦΠΑ όταν ο εκδότης είναι αλλοδαπή πλατφόρμα, εξετάζονται για VIES όπου απαιτείται και συμφωνούνται ανά κράτηση με το PMS πριν ο λογιστής οριστικοποιήσει την εγγραφή.

Αυτό είναι το σημείο που κάνει την καταχώρηση τιμολογίων OTA ξενοδοχείου διαφορετική από μια απλή εγγραφή εξόδου. Το ποσό του statement δεν είναι αρκετό από μόνο του. Κάθε γραμμή προμήθειας αντιστοιχεί σε συγκεκριμένη κράτηση, με reservation number, ημερομηνίες διαμονής, μικτή αξία διαμονής, ποσοστό προμήθειας, adjustments, πιθανή ακύρωση ή no-show. Αν μία από αυτές τις γραμμές δεν συμφωνεί με το PMS ή το channel manager, το λογιστικό ποσό μπορεί να είναι σωστό μαθηματικά αλλά λάθος επιχειρησιακά.

Ο μηνιαίος κύκλος είναι συνήθως πιεσμένος. Στις αρχές του μήνα ο λογιστής παίρνει το invoice ή statement της Booking.com για τον προηγούμενο μήνα, μαζί με αντίστοιχα reports από Expedia ή Airbnb όπου υπάρχουν. Ο controller θέλει να ξέρει πόση προμήθεια χρεώθηκε το ξενοδοχείο, ποιες κρατήσεις την δημιούργησαν, αν υπάρχει ποσό για αμφισβήτηση στο partner portal και πώς θα εμφανιστεί η συναλλαγή στην Περιοδική Δήλωση ΦΠΑ, στο VIES και στο myDATA.

Το ασφαλές workflow έχει τρία επίπεδα. Πρώτα διαβάζεται ο εκδότης και το VAT status του παραστατικού, γιατί άλλο πράγμα είναι ελληνική υπηρεσία και άλλο αλλοδαπή πλατφόρμα που χρεώνει υπηρεσίες διαμεσολάβησης. Μετά εξάγονται οι γραμμές κρατήσεων σε σταθερή μορφή, ώστε η προμήθεια να ελεγχθεί απέναντι στο PMS export. Μόνο στο τέλος γίνεται η λογιστική εγγραφή, με το καθαρό ποσό προμήθειας, τον ΦΠΑ αντίστροφης χρέωσης όπου εφαρμόζεται και την τεκμηρίωση που χρειάζεται για μεταγενέστερο έλεγχο.

Ο στόχος δεν είναι να γίνει ο λογιστής revenue manager ούτε να αξιολογήσει αν οι direct bookings συμφέρουν περισσότερο. Το θέμα είναι πιο πρακτικό: το OTA invoice είναι ταυτόχρονα παραστατικό εξόδου, αρχείο συμφωνίας κρατήσεων και σημείο φορολογικού ελέγχου. Αν λείπει ένα από τα τρία, το μηνιαίο κλείσιμο του ξενοδοχείου μένει ανοιχτό, ακόμη και αν το συνολικό ποσό του τιμολογίου έχει περαστεί στα βιβλία.

Τι περιέχουν τα statements Booking.com, Expedia και Airbnb

Ένα OTA statement πρέπει να διαβαστεί πρώτα ως αρχείο γραμμών και μετά ως τιμολόγιο συνολικού ποσού. Στο header εμφανίζονται συνήθως ο αριθμός τιμολογίου, η περίοδος αναφοράς, το hotel ή property ID, η επωνυμία του καταλύματος, ο εκδότης, το VAT ID του εκδότη και το συνολικό ποσό προμήθειας. Στο footer ή στο summary μπορεί να υπάρχουν modifications, refunds, παλαιότερες διαφορές και το net payable.

Η δουλειά του λογιστή αρχίζει στις γραμμές. Εκεί φαίνεται το reservation number, το guest name ή masked guest name, οι ημερομηνίες check-in και check-out, ο τύπος δωματίου, η μικτή αξία διαμονής, το ποσοστό προμήθειας, το commission amount και τυχόν adjustment reason. Για την καταχώρηση, αυτά τα πεδία δεν είναι απλή λεπτομέρεια. Είναι η γέφυρα ανάμεσα στο παραστατικό OTA και στην κράτηση που έχει καταγραφεί στο PMS.

Στην Booking.com το ξενοδοχείο βλέπει συνήθως μηνιαίο invoice ή statement προμήθειας με booking-level γραμμές. Στις γραμμές αυτές μπορούν να εμφανιστούν προμήθειες που επηρεάζονται από Genius rate, Mobile Rate, ακυρώσεις ή no-shows. Το τιμολόγιο Booking.com ξενοδοχείου για καταχώρηση πρέπει να ελεγχθεί με βάση την εμπορική κατάσταση κάθε κράτησης, όχι μόνο με βάση το subtotal που εμφανίζεται στο τέλος.

Στην Expedia ο λογιστικός χειρισμός επηρεάζεται περισσότερο από το payment model. Στο Hotel Collect, το ξενοδοχείο εισπράττει από τον επισκέπτη και πληρώνει την προμήθεια στην πλατφόρμα. Στο Expedia Collect, η πλατφόρμα εισπράττει και αποδίδει στο ξενοδοχείο το καθαρό ποσό ή εμφανίζει remittance report. Το λογιστικό ερώτημα δεν είναι απλώς "πόση είναι η προμήθεια", αλλά αν το report συμφωνεί με τις κρατήσεις, τις εισπράξεις και τα ποσά που ήδη έχουν αναγνωριστεί ως έσοδο.

Στην Airbnb η δομή μπορεί να είναι ακόμη λιγότερο οικεία για ξενοδοχειακό λογιστήριο, ειδικά όταν υπάρχουν host fee, service fee και διαφορετικό timing ανά κράτηση ή summary. Για Expedia Airbnb προμήθειες ξενοδοχείου λογιστική, ο κοινός κανόνας είναι ότι ο λογιστής πρέπει να απομονώνει την πραγματική χρέωση της πλατφόρμας, το σχετικό VAT status και την κράτηση που τη δημιούργησε.

Αυτή η ροή διαφέρει από την καταχώρηση TDA προμηθευτών ξενοδοχείου, όπου ο λογιστής συνήθως ελέγχει ελληνικό παραστατικό αγοράς με εγχώριο ΦΠΑ, προμηθευτή εσωτερικού και κατηγορίες κόστους όπως τρόφιμα ή αναλώσιμα. Το OTA invoice είναι υπηρεσία διανομής ή διαμεσολάβησης από πλατφόρμα, με γραμμές κρατήσεων και φορολογικό χειρισμό που πρέπει να επιβεβαιωθεί πριν την εγγραφή.

Reverse charge, VIES και myDATA πριν την οριστική εγγραφή

Στα OTA invoices το πρώτο compliance ερώτημα είναι ποιος παρέχει την υπηρεσία και από ποια χώρα. Όταν μια αλλοδαπή πλατφόρμα παρέχει υπηρεσία διαμεσολάβησης, προβολής ή διανομής προς ελληνικό υποκείμενο στον ΦΠΑ, ο λογιστής εξετάζει αν η συναλλαγή εμπίπτει σε ενδοκοινοτική λήψη υπηρεσιών και αν εφαρμόζεται reverse charge ΦΠΑ στην Ελλάδα. Το πρακτικό σημείο εκκίνησης είναι ο κανόνας τόπου παροχής υπηρεσιών του Ν. 2859/2000, ιδίως το Άρθρο 14 για B2B υπηρεσίες, πάντα σε συνδυασμό με τον πραγματικό εκδότη και τη σύμβαση. Η απάντηση δεν πρέπει να βγαίνει μόνο από το brand της πλατφόρμας. Βγαίνει από τον πραγματικό εκδότη, το VAT ID, τη σύμβαση και τη φύση της χρέωσης.

Για την Booking.com, ο λογιστής θα δει συχνά Booking B.V. ή άλλη σχετική οντότητα στο παραστατικό. Για την Airbnb, πολλά ευρωπαϊκά παραστατικά συνδέονται με Airbnb Ireland UC. Στην Expedia χρειάζεται ακόμη μεγαλύτερη προσοχή, γιατί η οντότητα και το payment model μπορεί να διαφέρουν ανά σύμβαση και αγορά. Αν ο εκδότης, το VAT ID ή η χώρα δεν στηρίζουν ενδοκοινοτική αντιμετώπιση, η εγγραφή δεν πρέπει να βασιστεί σε συνήθεια προηγούμενων μηνών.

Ο πρακτικός έλεγχος πριν από την εγγραφή είναι σύντομος αλλά ουσιαστικός:

1. Επιβεβαίωση επωνυμίας εκδότη και VAT ID στο παραστατικό.
2. Έλεγχος VIES για το VAT ID, όπου η συναλλαγή στηρίζεται σε ενδοκοινοτικό χειρισμό.
3. Συμφωνία περιόδου, invoice number και ποσού προμήθειας με το OTA statement.
4. Έλεγχος αν υπάρχουν credit notes, refunds ή adjustments που ανήκουν σε προηγούμενο μήνα.
5. Απόφαση για reverse charge και για τις σχετικές κινήσεις output VAT και input VAT, σύμφωνα με τον χειρισμό της επιχείρησης.

Για πλήρως εκπιπτόμενη δραστηριότητα, το reverse charge είναι συνήθως ταμειακά ουδέτερο: ο ΦΠΑ της λήψης υπηρεσίας εμφανίζεται και ως οφειλόμενος και ως εκπιπτόμενος στην ίδια περίοδο. Αυτό δεν το κάνει προαιρετικό. Η καταχώρηση πρέπει να στηρίζει σωστά την Περιοδική Δήλωση ΦΠΑ, τον Ανακεφαλαιωτικό Πίνακα όπου απαιτείται και το myDATA record του λήπτη.

Οι προθεσμίες ΦΠΑ και VIES της ΑΑΔΕ αναφέρουν ότι οι Περιοδικές δηλώσεις ΦΠΑ υποβάλλονται εμπρόθεσμα μέχρι την τελευταία εργάσιμη ημέρα του επόμενου μήνα ή τριμήνου αναφοράς, ενώ οι Ανακεφαλαιωτικοί Πίνακες Ενδοκοινοτικών Συναλλαγών (Φ4/Φ5) μέχρι την 26η του επόμενου μήνα της συναλλαγής. Αυτός ο χρονισμός έχει σημασία για OTA invoices που φτάνουν μετά το τέλος του μήνα αλλά αφορούν προηγούμενη περίοδο κρατήσεων.

Στο myDATA, ο λογιστής πρέπει να αντιμετωπίσει το OTA invoice ως παραστατικό εξωτερικού που χαρακτηρίζεται και διαβιβάζεται από την πλευρά του λήπτη, ανάλογα με τον χειρισμό που ακολουθεί η επιχείρηση. Το αναλυτικό θέμα των τιμολόγια εξωτερικού στο myDATA είναι ξεχωριστό, αλλά εδώ το κρίσιμο σημείο είναι να μη γίνει η καταχώρηση προμήθειας χωρίς να έχει τελειώσει ο έλεγχος VAT ID, περιόδου και reverse-charge treatment.

Συμφωνία κάθε κράτησης με PMS και channel manager

Η σωστή συμφωνία αρχίζει με κοινό κλειδί. Ιδανικά, αυτό είναι το reservation number που εμφανίζεται και στο OTA statement και στο PMS. Όταν το κλειδί δεν είναι καθαρό, ο λογιστής ή ο controller χρειάζεται δεύτερα πεδία: guest name ή masked guest name, check-in, check-out, μικτή αξία διαμονής, channel, commission amount και status κράτησης. Χωρίς αυτά, η συμφωνία γίνεται με το μάτι και δύσκολα αφήνει ίχνος ελέγχου.

Η πρακτική ροή είναι συγκεκριμένη. Πρώτα βγαίνουν οι γραμμές του OTA invoice σε Excel ή CSV. Μετά εξάγεται από το PMS ή το channel manager η λίστα κρατήσεων της ίδιας περιόδου. Οι δύο πίνακες ενώνονται με reservation number και ελέγχονται οι αποκλίσεις σε μικτή αξία, ημερομηνίες, status και προμήθεια. Οι γραμμές που δεν συμφωνούν δεν περνούν απλώς ως "διαφορά". Πηγαίνουν σε variance review, τεκμηριώνονται και, αν χρειάζεται, ανοίγεται dispute στο partner portal πριν κλειδώσει το τελικό ποσό.

Η συμφωνία κρατήσεων Booking με PMS είναι πιο απαιτητική από μια σύγκριση subtotal. Ένα no-show μπορεί να χρεωθεί με βάση την πολιτική της πλατφόρμας. Μια τροποποίηση διαμονής μπορεί να αλλάξει τη βάση προμήθειας αλλά να εμφανιστεί με καθυστέρηση. Ένα Genius ή mobile discount μπορεί να εξηγεί γιατί η αξία που βλέπει ο revenue manager δεν ταιριάζει με την αξία στο statement. Στην Expedia, το Expedia Collect ή Hotel Collect αλλάζει το πώς ο λογιστής συνδέει προμήθεια, είσπραξη και remittance. Στην Airbnb, το fee split μπορεί να θέλει ξεχωριστή ανάγνωση από την απλή μικτή αξία κράτησης.

Εδώ έχει νόημα η αυτοματοποίηση. Η χειροκίνητη εξαγωγή δεδομένων από τιμολόγιο Booking PDF Excel κουράζει γρήγορα όταν ένα property έχει δεκάδες ή εκατοντάδες κρατήσεις τον μήνα. Το Invoice Data Extraction μπορεί να μετατρέψει OTA PDFs και αποθηκευμένα PDF statements σε Excel, CSV ή JSON με οδηγία τύπου "μία γραμμή ανά κράτηση" και με στήλες όπως invoice_number, ota_name, reservation_number, check_in, check_out, gross_value, commission_rate, commission_amount, adjustment_reason, source_file και source_page. Η εξαγωγή δεδομένων από τιμολόγια σε Excel δεν αντικαθιστά την κρίση του λογιστή, αλλά αφαιρεί το μηχανικό πληκτρολόγημα από το σημείο όπου χρειάζεται να αρχίσει ο έλεγχος.

Το source_file και source_page δεν είναι διακοσμητικές στήλες. Όταν μια διαφορά αμφισβητείται στο partner portal ή όταν ο controller ζητά απόδειξη πριν εγκρίνει την εγγραφή, ο χρήστης πρέπει να γυρίσει αμέσως στη γραμμή του statement που δημιούργησε τη χρέωση. Αυτό μετατρέπει το Excel από πρόχειρο φύλλο εργασίας σε audit trail του μήνα.

Ακυρώσεις, no-shows και τροποποιήσεις που αλλάζουν την προμήθεια

Οι περισσότερες πραγματικές διαφορές στα OTA statements δεν κρύβονται στο subtotal. Κρύβονται στις γραμμές που φαίνονται συνηθισμένες μέχρι να συγκριθούν με την κατάσταση της κράτησης στο PMS. Μια ακύρωση που έγινε έγκαιρα μπορεί να έχει μείνει ως commission charge. Ένα no-show μπορεί να χρεώνεται πλήρως ή μερικώς, ανάλογα με την πολιτική της πλατφόρμας και τους όρους της κράτησης. Μια πρόωρη αναχώρηση μπορεί να έχει μειώσει την πραγματική αξία διαμονής χωρίς να έχει ενημερωθεί σωστά η βάση προμήθειας.

Ο λογιστής πρέπει να διαβάζει κάθε γραμμή σαν claim προς έλεγχο. Η γραμμή λέει ότι η πλατφόρμα δικαιούται προμήθεια για συγκεκριμένη κράτηση. Το PMS ή το partner portal πρέπει να απαντήσει αν η κράτηση εκπληρώθηκε, ακυρώθηκε, τροποποιήθηκε ή μεταφέρθηκε σε διαφορετική χρέωση. Αν δεν υπάρχει αυτός ο έλεγχος, η εγγραφή προμήθειας μπορεί να ενσωματώσει ποσά που θα έπρεπε να αμφισβητηθούν.

Στην Booking.com, οι διαφορές εμφανίζονται συχνά γύρω από no-shows, cancellations, Genius discounts και αλλαγές ημερομηνιών. Αν το ξενοδοχείο δεν δήλωσε σωστά no-show ή αν η ακύρωση δεν περάστηκε εγκαίρως στο σύστημα, το statement μπορεί να χρεώσει προμήθεια που χρειάζεται διόρθωση μέσα από το partner portal. Στην Expedia, το payment model παίζει μεγαλύτερο ρόλο: σε Expedia Collect, το remittance και η προμήθεια πρέπει να συμφωνήσουν με τα ποσά που αποδόθηκαν, ενώ σε Hotel Collect ο έλεγχος μοιάζει περισσότερο με χρέωση προμήθειας επί κρατήσεων που εισέπραξε το ξενοδοχείο. Στην Airbnb, ο λογιστής πρέπει να ξεχωρίσει host fee, guest-facing service fee όπου εμφανίζεται και timing της κράτησης ή του payout.

Το dispute workflow χρειάζεται τεκμηρίωση, όχι μόνο σχόλιο σε Excel. Για κάθε αμφισβητούμενη γραμμή, κρατιούνται το OTA invoice line, το PMS status, το partner-portal screenshot ή export και η απόφαση: αποδοχή, dispute, αναμονή credit note ή μεταφορά ελέγχου στον επόμενο μήνα. Αυτό έχει σημασία και για το accounting close. Αν μια διαφορά αναμένεται να πιστωθεί στο επόμενο statement, ο λογιστής πρέπει να ξέρει αν θα περάσει την αρχική προμήθεια, αν θα σχηματίσει αναμονή ή αν θα κρατήσει την εγγραφή μέχρι να υπάρξει τεκμηρίωση.

Η πειθαρχία αυτή προστατεύει και τα μικρά ποσά. Σε ένα μόνο property, μια λάθος προμήθεια σε ακυρωμένη κράτηση μπορεί να φαίνεται αμελητέα. Σε λογιστικό γραφείο με πολλά ξενοδοχεία, επαναλαμβανόμενες μικρές αποκλίσεις γίνονται πραγματικό κόστος και θολώνουν την εικόνα του distribution expense ανά κανάλι.

Η λογιστική εγγραφή της προμήθειας και το μηνιαίο κλείσιμο

Η Booking.com προμήθεια λογιστική εγγραφή πρέπει να ξεκινά από το συμφωνημένο ποσό, όχι από το πρώτο subtotal που εμφανίστηκε στο PDF. Μετά τη συμφωνία γραμμών, το καθαρό ποσό της προμήθειας περνά συνήθως ως έξοδο διανομής, προμήθειας πωλήσεων ή προβολής, ανάλογα με το σχέδιο λογαριασμών και την πολιτική της επιχείρησης. Σε ορισμένα λογιστικά σχέδια θα χρησιμοποιηθούν λογαριασμοί τύπου 64.07 ή 64.98, αλλά αυτό είναι ενδεικτική πρακτική, όχι καθολική οδηγία για κάθε ξενοδοχείο.

Η προμήθεια OTA δεν είναι κόστος πωληθέντων του εστιατορίου ούτε προμήθεια αγοράς υλικών. Αν το ξενοδοχείο παρακολουθεί ξεχωριστά το μηνιαίο κλείσιμο F&B και COGS ξενοδοχείου, οι OTA commissions πρέπει να μείνουν σε διαφορετική ροή εξόδων. Αυτό βοηθά και στο management reporting: η προμήθεια προς OTA δείχνει κόστος διανομής του δωματίου, όχι κόστος παραγωγής της διανυκτέρευσης ή της εστίασης.

Για παραστατικό αλλοδαπής πλατφόρμας όπου εφαρμόζεται reverse charge, η εγγραφή περιλαμβάνει και τη φορολογική κίνηση. Το έξοδο προμήθειας αναγνωρίζεται στο καθαρό ποσό. Ο ΦΠΑ της λήψης υπηρεσίας υπολογίζεται στην ελληνική δήλωση ως οφειλόμενος ΦΠΑ και, όπου η επιχείρηση έχει πλήρες δικαίωμα έκπτωσης, ταυτόχρονα ως εκπιπτόμενος ΦΠΑ. Η καθαρή ταμειακή επίπτωση μπορεί να είναι μηδενική, αλλά η λογιστική και δηλωτική απεικόνιση πρέπει να είναι καθαρή.

Η πληρωμή ή ο συμψηφισμός εξαρτάται από το OTA model. Αν το ξενοδοχείο εισπράττει από τον πελάτη και πληρώνει προμήθεια, η εγγραφή δημιουργεί payable προς την πλατφόρμα μέχρι την εξόφληση. Αν η πλατφόρμα κρατά την προμήθεια και αποδίδει καθαρό ποσό, ο λογιστής πρέπει να συμφωνήσει το receivable ή remittance με τις κρατήσεις και να εμφανίσει χωριστά το έσοδο και την προμήθεια, σύμφωνα με την πολιτική αναγνώρισης εσόδων της επιχείρησης.

Τα credit notes και refunds θέλουν ιδιαίτερη προσοχή στο cut-off. Μια προμήθεια Μαρτίου μπορεί να πιστωθεί στο statement Απριλίου λόγω dispute ή τροποποίησης. Αν ο λογιστής κλείσει τον μήνα χωρίς πίνακα διαφορών, η πίστωση θα φαίνεται σαν νέα κίνηση αντί για διόρθωση συγκεκριμένης κράτησης. Το ίδιο ισχύει για σπάνια non-EUR invoices ή παλαιότερες συμβάσεις με άλλο νόμισμα: η μετατροπή πρέπει να γίνεται με τεκμηριωμένη ισοτιμία και να συνδέεται με την περίοδο της συναλλαγής.

Σε μικρή μονάδα, όλα αυτά μπορεί να καταλήγουν σε μία μηνιαία εγγραφή. Σε λογιστικό γραφείο ή αλυσίδα, η ίδια εγγραφή χρειάζεται cost center, property ID, OTA channel και status συμφωνίας. Αλλιώς το μηνιαίο κλείσιμο δείχνει ότι "πέρασε το τιμολόγιο", αλλά δεν απαντά αν το ξενοδοχείο πλήρωσε σωστή προμήθεια για σωστές κρατήσεις.

Έλεγχοι για λογιστικά γραφεία με πολλά καταλύματα

Το πρόβλημα αλλάζει κλίμακα όταν το ίδιο λογιστικό γραφείο χειρίζεται πολλά καταλύματα. Ένα ξενοδοχείο μπορεί να έχει τρεις βασικές πλατφόρμες, δεκάδες ή εκατοντάδες γραμμές κρατήσεων ανά μήνα και διαφορετικά cutoff ανά OTA. Πέντε ή δέκα πελάτες με τέτοια ροή δημιουργούν εκατοντάδες γραμμές που πρέπει να συμφωνηθούν πριν από τις προθεσμίες ΦΠΑ, VIES και reporting.

Η λύση δεν είναι περισσότερα ad hoc φύλλα Excel. Χρειάζεται σταθερό control file ανά μήνα και property. Σε αυτό μπαίνουν το αρχικό OTA invoice ή report, οι extracted rows, το PMS export, το variance review, τα disputes, το τελικό posting amount, το VAT/VIES status και το πρόσωπο που ενέκρινε την εγγραφή. Η αξία του αρχείου είναι ότι κάθε πελάτης κλείνει με την ίδια λογική, ακόμη και αν οι πλατφόρμες χρησιμοποιούν διαφορετικές ονομασίες πεδίων.

Οι στήλες πρέπει να είναι ομοιόμορφες. OTA name, property ID, invoice number, invoice period, reservation number, stay dates, gross value, commission amount, adjustment reason, PMS status, variance amount, dispute status και final accounting amount αρκούν για να φανεί η εικόνα. Αν το statement της Booking.com γράφει διαφορετικό label από την Expedia ή την Airbnb, η στήλη του control file δεν πρέπει να αλλάζει. Αυτό δίνει συγκρίσιμο αρχείο μήνα με μήνα.

Η τεκμηρίωση έχει ιδιαίτερη σημασία σε έλεγχο ή σε εσωτερική ερώτηση controller. Για κάθε γραμμή πρέπει να μπορεί να απαντηθεί από ποιο αρχείο προήλθε, ποια κράτηση τη στηρίζει, αν ελέγχθηκε σε VIES όπου χρειαζόταν και γιατί η διαφορά εγκρίθηκε ή αμφισβητήθηκε. Αν η απάντηση βρίσκεται μόνο στη μνήμη του χειριστή ή σε σχόλιο χωρίς source reference, το γραφείο δεν έχει πραγματικό audit trail.

Η τυποποίηση των extraction prompts βοηθά σε αυτή τη ροή, επειδή ζητά από κάθε OTA statement τα ίδια πεδία με τους ίδιους κανόνες. Για παράδειγμα, το γραφείο μπορεί να ζητά πάντα μία γραμμή ανά κράτηση, ημερομηνίες σε μορφή YYYY-MM-DD, ποσά σε αριθμητικές στήλες και χωριστή στήλη για adjustment reason. Έτσι ο έλεγχος γίνεται λογιστική διαδικασία και όχι επαναλαμβανόμενη χειροκίνητη ανάγνωση ξένων portal reports.

Πρακτικό closing sequence για κάθε μήνα

1. Συγκεντρώστε τα OTA invoices και reports του μήνα από Booking.com, Expedia, Airbnb και όποια άλλη πλατφόρμα χρησιμοποιεί το κατάλυμα. Κρατήστε το αρχικό PDF, HTML export ή portal report, όχι μόνο το Excel εργασίας.

2. Ελέγξτε εκδότη, χώρα, VAT ID, invoice period και property ID. Αν ο εκδότης είναι αλλοδαπή πλατφόρμα και η συναλλαγή στηρίζεται σε ενδοκοινοτικό χειρισμό, κάντε τον VIES έλεγχο πριν την εγγραφή.

3. Εξάγετε τις booking-level γραμμές σε σταθερή μορφή. Οι ελάχιστες στήλες είναι reservation number, check-in, check-out, gross value, commission rate, commission amount, adjustment reason και source reference.

4. Πάρτε PMS ή channel-manager export για την ίδια περίοδο. Προτιμήστε export που περιλαμβάνει status κράτησης, κανάλι, μικτή αξία, ημερομηνίες και τυχόν τροποποιήσεις.

5. Αντιστοιχίστε OTA lines με PMS lines. Ξεκινήστε από reservation number και χρησιμοποιήστε ημερομηνίες, ποσό και guest data μόνο όπου το reservation number δεν αρκεί.

6. Ελέγξτε τις αποκλίσεις πριν από την καταχώρηση. Ακυρώσεις, no-shows, early departures, rate modifications, refunds και credit notes πρέπει να έχουν απόφαση: αποδοχή, dispute, αναμονή ή διόρθωση σε επόμενο statement.

7. Οριστικοποιήστε το ποσό προμήθειας που θα περαστεί στα βιβλία. Ξεχωρίστε το expense, το payable ή remittance treatment και τον reverse-charge ΦΠΑ όπου εφαρμόζεται.

8. Κλείστε τα VAT, VIES και myDATA σημεία ελέγχου. Το παραστατικό πρέπει να στηρίζει την Περιοδική Δήλωση ΦΠΑ, τον Ανακεφαλαιωτικό Πίνακα όπου απαιτείται και τη διαβίβαση ή χαρακτηρισμό του λήπτη.

9. Αρχειοθετήστε evidence ανά μήνα και property: source invoice, extracted rows, PMS export, variance review, disputes και τελική εγγραφή. Αν μια διαφορά επιστρέψει ως credit note τον επόμενο μήνα, πρέπει να μπορεί να συνδεθεί με την αρχική κράτηση.

Η οριστική εγγραφή της προμήθειας πρέπει να γίνεται μετά τη booking-level συμφωνία, όχι πριν. Το OTA invoice είναι παραστατικό προμήθειας, compliance item και αρχείο συμφωνίας κρατήσεων μαζί. Όταν το μηνιαίο close το αντιμετωπίζει έτσι, η εγγραφή στα βιβλία στηρίζεται σε πραγματικά ελεγμένες κρατήσεις και όχι σε ένα συνολικό ποσό που απλώς έφτασε από την πλατφόρμα.