Αυτοματοποίηση της συμμόρφωσης με τον ΦΠΑ στην ΕΕ μέσω ενός cloud accounting API

Ένας πρακτικός οδηγός για πλατφόρμες και αγορές (marketplaces) που χρειάζονται πραγματικά λογιστικά βιβλία, σωστό ΦΠΑ και ένα ελεγκτικό ίχνος (audit trail) που αντέχει στον χρόνο.

Ο ΦΠΑ στην ΕΕ δεν αποτελεί πλέον πρόβλημα υπολογισμού. Αποτελεί πρόβλημα τεκμηρίωσης. Οι συντελεστές είναι δημοσιευμένοι, τα όρια (thresholds) είναι γνωστά και οι δηλώσεις OSS είναι καλά τεκμηριωμένες. Αυτό που αποτυγχάνει στους ελέγχους και αυτό που καταρρέει στις πλατφόρμες σε μεγάλη κλίμακα είναι η αδυναμία ανακατασκευής του τρόπου με τον οποίο ελήφθη μια συγκεκριμένη απόφαση για τον ΦΠΑ σε ένα συγκεκριμένο τιμολόγιο, χρησιμοποιώντας τους κανόνες και τα δεδομένα εισόδου που υπήρχαν εκείνη τη στιγμή. Ένα cloud accounting API μπορεί να το αυτοματοποιήσει αυτό από άκρη σε άκρη, αλλά μόνο εάν έχει σχεδιαστεί γύρω από το γράφημα αποφάσεων και όχι απλώς γύρω από τον συντελεστή.

Αυτή η διάκριση διαμορφώνει τα πάντα παρακάτω.

Τι σημαίνει πραγματικά «αυτοματοποίηση του ΦΠΑ στην ΕΕ»

Για μια πλατφόρμες που πραγματοποιεί πωλήσεις σε πολλές χώρες της ΕΕ, η αυτοματοποίηση του ΦΠΑ αποτελεί μια αλυσίδα εξαρτημένων αποφάσεων:

Είναι ο πελάτης B2B ή B2C και πού βρίσκεται;
Ο συντελεστής ποιας χώρας εφαρμόζεται, σε ποια φορολογική κατηγορία, την ημερομηνία έκδοσης του τιμολογίου;
Η παράδοση υπόκειται σε αντίστροφη επιβάρυνση (reverse charge), σε δήλωση OSS, σε δήλωση IOSS ή είναι εγχώρια;
Η αγορά (marketplace) θεωρήθηκε ως ο προμηθευτής (deemed supplier) ή ο έμπορος;
Ποια αποδεικτικά στοιχεία υποστηρίζουν καθεμία από αυτές τις απαντήσεις και μπορούν να αναπαραχθούν αργότερα;

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

Ένα cloud accounting API αποτελεί το φυσικό μέρος για τη διατήρηση αυτού του ίχνους, επειδή αποθηκεύει ήδη το τιμολόγιο, την εγγραφή στο καθολικό (ledger) και τον αντισυμβαλλόμενο. Το Nordlet είναι χτισμένο γύρω από αυτήν την ιδέα: ένα αμετάβλητο διπλογραφικό καθολικό (immutable double-entry ledger), λογική ΦΠΑ ανά χώρα, επικύρωση VIES και παραγωγή μητρώου i.SAF, τα οποία είναι όλα προσβάσιμα μέσω μιας ενιαίας επιφάνειας REST με τυπωμένα SDK και webhooks. Το API δεν αποτελεί μια απλή επικάλυψη πάνω στην τήρηση βιβλίων. Αποτελεί το σύστημα καταγραφής για την ίδια την απόφαση.

Οι τρεις δυνατότητες του API που σηκώνουν το βάρος

Οι περισσότερες εργασίες αυτοματοποίησης του ΦΠΑ καταλήγουν σε τρεις δυνατότητες τις οποίες το accounting API πρέπει να εκθέτει με καθαρό τρόπο.

1. Περιεχόμενο συντελεστών και φορολογικές κατηγορίες, συνδεδεμένες με ημερομηνία. Οι συντελεστές αλλάζουν. Οι κατηγορίες αλλάζουν. Οι μειωμένοι συντελεστές προστίθενται και αφαιρούνται. Το εφαρμόσιμο πρότυπο, όπως υποστηρίζει η καθοδήγηση προγραμματιστών της Sage σχετικά με τη μεταρρύθμιση του ΦΠΑ στην ΕΕ και τα accounting APIs, είναι η αντιστοίχιση των ειδών σε φορολογικές κατηγορίες και στη συνέχεια η αντιστοίχιση των φορολογικών κατηγοριών σε κωδικούς συγκεκριμένης χώρας με ημερομηνίες ισχύος. Η σκληρή κωδικοποίηση (hard-coding) ενός συντελεστή ανά είδος ανά χώρα αποτελεί το αντι-πρότυπο που συσσωρεύεται σιωπηρά μέχρις ότου μια αλλαγή συντελεστή χαλάσει κάτι ένα χρόνο αργότερα.

2. Επικύρωση ΑΦΜ/ΦΠΑ (VAT ID) με ομαλή υποβάθμιση (graceful degradation). Το VIES αποτελεί την κανονική πηγή για διασυνοριακή επικύρωση B2B. Παράλληλα, είναι και κατά διαστήματα αναξιόπιστο. Οι λογικές υλοποιήσεις αποθηκεύουν στην κشή (cache) τις επικυρώσεις με μικρά TTLs, επαναλαμβάνουν την προσπάθεια σε περίπτωση αποτυχίας και δρομολογούν τις αμφίβολες περιπτώσεις σε μια ουρά αναθεώρησης αντί να εμποδίζουν μια πώληση. Η ιδέα ότι το VIES πρέπει να επιτυγχάνει συγχρονισμένα για κάθε συναλλαγή είναι το σημείο όπου οι πλατφόρμες δημιουργούν διακοπές λειτουργίας για τον εαυτό τους.

3. Συλλογή αποδεικτικών στοιχείων και αμετάβλητο (immutability). Κάθε απόφαση για τον ΦΠΑ πρέπει να αποθηκεύει τα δεδομένα εισόδου της: σήματα τοποθεσίας πελάτη, ΑΦΜ/ΦΠΑ και χρονική σήμανση επικύρωσης, φορολογική κατηγορία, έκδοση πίνακα συντελεστών, ισχύον καθεστώς (εγχώριο, OSS, IOSS, αντίστροφη επιβάρυνση) και ρόλο αγοράς. Αυτό το αρχείο πρέπει να επιβιώνει από αλλαγές συντελεστών και τροποποιήσεις διαμόρφωσης. Ένα αμετάβλητο καθολικό με κλείδωμα περιόδου (period locking), το οποίο το Nordlet επιβάλλει σε επίπεδο API, σημαίνει ότι ένας κλειστός μήνας δεν μπορεί να ξαναγραφτεί σιωπηρά για να κάνει έναν μεταγενέστερο έλεγχο να φαίνεται πιο τακτοποιημένος.

Αυτές οι τρεις δυνατότητες αποτελούν τη βάση. Τα υπόλοιπα, συμπεριλαμβανομένης της υποβολής OSS, της παραγωγής i.SAF και της συμφωνίας (reconciliation), βρίσκονται από πάνω.

Μοντελοποίηση της απόφασης ΦΠΑ και όχι μόνο του συντελεστή

Ο πιο συνηθισμένος τρόπος αποτυχίας στην ενσωματωμένη λογιστική (embedded accounting) είναι η αντιμετώπιση του φορολογικού πεδίου σε ένα τιμολόγιο ως το αποτέλεσμα μιας αναζήτησης. Δεν είναι. Αποτελεί το αποτέλεσμα ενός μικρού γράφηματος αποφάσεων και αυτό το γράφημα είναι που πρέπει να αποθηκευτεί.

Ένα εφαρμόσιμο μοντέλο:

Ταξινόμηση αντισυμβαλλομένου. B2B ή B2C. Εάν είναι B2B, επικύρωση του ΑΦΜ/ΦΠΑ έναντι του VIES και αποθήκευση της απάντησης, συμπεριλαμβανομένης της χρονικής σήμανσης και της κατάστασης. Εάν είναι B2C, καταγραφή τουλάχιστον δύο σημάτων τοποθεσίας: διεύθυνσης χρέωσης, IP ή γεωεντοπισμού και χώρας μέσου πληρωμής, όπου είναι διαθέσιμη.
Καθορισμός τόπου παράδοσης (place of supply). Για τις ψηφιακές υπηρεσίες, ο ΦΠΑ ακολουθεί την τοποθεσία του πελάτη και όχι του προμηθευτή. Για τα αγαθά, οι κανόνες διαφέρουν ανάλογα με την προέλευση και τον προορισμό της αποστολής. Το API πρέπει να επισημαίνει κάθε γραμμή τιμολογίου με τον προέρχοντα τόπο παράδοσης και τα σήματα που χρησιμοποιήθηκαν.
Επιλογή καθεστώτος. Εγχώριο, OSS (διασυνοριακό B2C εντός της ΕΕ), IOSS (εισαγωγές χαμηλής αξίας) ή αντίστροφη επιβάρυνση. Η λογική των ορίων, ιδίως το διασυνοριακό όριο B2C των 10.000 € για τις ψηφιακές υπηρεσίες, πρέπει να υπολογίζεται έναντι ενός κυλιόμενου παραθύρου (rolling window) και όχι έναντι του τρέχοντος τιμολογίου μεμονωμένα.
Επίλυση συντελεστή. Αναζήτηση του συντελεστή της χώρας για τη φορολογική κατηγορία την ημερομηνία του τιμολογίου. Αποθήκευση της έκδοσης του πίνακα συντελεστών που χρησιμοποιήθηκε.
Καταχώριση στο καθολικό. Εγγραφή διπλογραφικής εγγραφής με πληρωτέο ΦΠΑ κατανεμημένο ανά χώρα και καθεστώς, ώστε οι δηλώσεις OSS και οι εγχώριες δηλώσεις ΦΠΑ να μπορούν να παραχθούν χωρίς την εκ νέου εξαγωγή των δεδομένων.

Κάθε βήμα πρέπει να είναι παρατηρήσιμο μέσω του API. Τα webhooks όπως το sale_invoice.paid επιτρέπουν στα συστήματα下游 (downstream) να αντιδρούν στις αλλαγές κατάστασης χωρίς polling. Τα κλειδιά ταυτοσημίας (idempotency keys) αποτρέπουν τις διπλότυπες εγγραφές στο καθολικό όταν μια επανάληψη δικτύου ενεργοποιείται τη λάθος στιγμή. Κανένα από τα δύο δεν είναι εξotic, αλλά και τα δύο είναι αδιαπραγμάτευτα σε κλίμακα πλατφόρμας.

OSS, IOSS και το όριο των 10.000 €

Για το SaaS και τις ψηφιακές υπηρεσίες, το πρακτικό πρόβλημα αυτοματοποίησης είναι το OSS. Ένας προμηθευτής που πραγματοποιεί διασυνοριακές B2C πωλήσεις εντός της ΕΕ εφαρμόζει τον συντελεστή της χώρας καταγωγής του έως ότου ξεπεραστεί το όριο των 10.000 € στο τρέχον ή το προηγούμενο ημερολογιακό έτος, και στη συνέχεια εφαρμόζει τον συντελεστή του κράτους μέλους του πελάτη και υποβάλλει τριμηνιαία δήλωση μέσω OSS. Η πρακτική καθοδήγηση σχετικά με τη συμμόρφωση με τον ΦΠΑ για SaaS και ψηφιακές υπηρεσίες πλαισιώνει αυτό το ζήτημα ως πρόβλημα αγωγού δεδομένων (data pipeline) και όχι ως πρόβλημα εγγραφής.

Ο αγωγός που πρέπει να υποστηρίζει το accounting API:

Παρακολούθηση των διασυνοριακών εσόδων B2C έναντι του ορίου σε κυλιόμενη βάση, ανά ημερολογιακό έτος.
Αυτόματη εναλλαγή της επίλυσης συντελεστών από τη χώρα καταγωγής στη χώρα προορισμού όταν ξεπεραστεί το όριο, χωρίς αναδρομική αλλαγή προηγούμενων τιμολογίων.
Ομαδοποίηση συναλλαγών ανά κράτος μέλος, καθεστώς και νόμισμα για την τριμηνιαία δήλωση OSS.
Κανονικοποίηση ποσών σε EUR την κατάλληλη ημερομηνία συναλλαγματικής ισοτιμίας για την υποβολή αναφορών OSS.
Εξαγωγή του συνόλου δεδομένων που είναι έτοιμο για δήλωση σε μορφή που μπορεί να καταναλώσει ο υποβάλλων ή η υπηρεσία υποβολής.

Το Nordlet διαχειρίζεται αυτό το ζήτημα μέσω της λογικής ΦΠΑ ανά χώρα στο καθολικό και της αναφοράς που ομαδοποιεί ανά καθεστώς και κράτος μέλος: οι δηλώσεις OSS υπολογίζονται από τα ίδια τα τιμολόγια, με διορθώσεις προηγούμενων περιόδων, και το όριο των 10.000 € παρακολουθείται αυτόματα. Η δήλωση προέρχεται από το καθολικό και δεν ανακατασκευάζεται από την αρχή κάθε τρίμηνο. Αυτός είναι ο σκοπός της τοποθέτησης του γραφήματος αποφάσεων μέσα στο λογιστικό σύστημα και όχι σε ξεχωριστό υπολογιστικό φύλλο.

Το IOSS ακολουθεί την ίδια μορφή για εισαγωγές χαμηλής αξίας, με διαφορετικό σύνολο ορίων και διαφορετική δήλωση.

Οι ροές αγορών και πλατφορμών αποτελούν δική τους κατηγορία

Η αντιμετώπιση μιας αγοράς (marketplace) ως κανονικού καναλιού B2C αποτελεί το σημείο όπου ένας εκπληκτικός αριθμός υλοποιήσεων αποτυγχάνει. Σε πολλά σενάρια της ΕΕ, η πλατφόρμα θεωρείται ως ο προμηθευτής (deemed supplier) και είναι υπεύθυνη για την είσπραξη και την απόδοση του ΦΠΑ. Η δική του λογιστική του εμπόρου πρέπει να αντικατοπτρίζει ότι η πλατφόρμα και όχι ο τελικός πελάτης είναι ο σχετικός με τον ΦΠΑ αντισυμβαλλόμενος για αυτές τις συναλλαγές.

Εδώ είναι που ένα ενσωματωμένο accounting API αξίζει τα χρήματά του. Η πλατφόρμα γνωρίζει, κατά τη στιγμή της πώλησης, εάν ενήργησε ως θεωρούμενος προμηθευτής. Αυτό το γεγονός πρέπει να καταγραφεί στο αρχείο του τιμολογίου και να μεταφερθεί στο καθολικό, ώστε τα βιβλία του εμπόρου να μην διπλομετρούν τον ΦΠΑ που η πλατφόρμα έχει ήδη διαχειριστεί. Η αποστολή δεικτών φορολογικού ρόλου μέσω του API και η αντύπωσή τους στις αναφορές αποτελεί τη διαφορά μεταξύ καθαρών βιβλίων και μιας συμφωνίας που ποτέ δεν ταιριάζει ακριβώς.

Για πλατφόρμες που χτίζονται πάνω στο Nordlet, αυτό είναι πρωτοκλασάτο: τα τιμολόγια φέρουν ένα vatScheme (συμπεριλαμβανομένου του marketplace_deemed) και μια σημαία deemedSupplier, και ο επίλυτης μεταχείρισης (treatment resolver) επιστρέφει το ισχύον καθεστώς μαζί με τη νομική του βάση σύμφωνα με την Οδηγία 2006/112/EK. Σε συνδυασμό με την υποστήριξη πολλαπλών εταιρειών (multi-company support), η λογιστική της πλατφόρμας και η λογιστική του εμπόρου μπορούν να συνυπάρχουν κάτω από το ίδιο API, με διαφορετικές εταιρείες και διαφορετικούς ρόλους, χωρίς διαρροή καταχωρίσεων ΦΠΑ μεταξύ τους.

Τι αλλάζει το ViDA και τι δεν αλλάζει

Ο ΦΠΑ στην Ψηφιακή Εποχή (ViDA) μετατοπίζει τη μορφή της αυτοματοποίησης από το «υπολογισμός και καταχώριση» στο «υπολογισμός, καταχώριση και διαβίβαση». Η ηλεκτρονική τιμολόγηση και η αναφορά σχεδόν σε πραγματικό χρόνο προς τις φορολογικές αρχές γίνονται μέρος του αγωγού. Αυτό δεν αντικαθιστά το accounting API. Κάνει τα δομημένα δεδομένα τιμολογίων του accounting API την πηγή που αντικατοπτρίζεται στην πύλη αναφοράς (reporting gateway).

Δύο πρακτικές επιπτώσεις:

Τα μεταδεδομένα τιμολογίων πρέπει να είναι πλουσιότερα από ό,τι επιτρέπουν τα περισσότερα παλαιά σχήματα. Τα πεδία Peppol BIS 3.0, η δομημένη ανάλυση ΦΠΑ ανά γραμμή και τα αναγνωριστικά καθεστώτος πρέπει να είναι πρωτοκλασάτα στο accounting API, και όχι προσκολλημένα ως σημειώσεις ελεύθερου κειμένου.
Το λογιστικό έγγραφο και το αναφερόμενο έγγραφο πρέπει να παραμένουν συγχρονισμένα. Εάν εκδοθεί πιστωτικό τιμολόγιο, η πύλη αναφοράς πρέπει να δει τη διόρθωση με τα ίδια αναγνωριστικά. Τα αμετάβλητα καθολικά και η σαφής γενεαλογία εγγράφων το καθιστούν απλό. Η χαλαρή τήρηση βιβλίων το καθιστά οδυνηρό.

Η προετοιμασία για το ViDA αφορά λιγότερο τα νέα χαρακτηριστικά και περισσότερο την ενίσχυση της πειθαρχίας αυτού που ήδη υπάρχει.

Μια σύντομη σύγκριση προσεγγίσεων αυτοματοποίησης

Προσέγγιση	Αποδεικτικά στοιχεία απόφασης ΦΠΑ	Διαχείριση OSS/IOSS	Μοντελοποίηση ρόλου αγοράς (marketplace)	Καταλληλότητα για ενσωματωμένες πλατφόρμες
Χειροκίνητη τήρηση βιβλίων με υπολογιστικά φύλλα	Αδύνατα, ανακατασκευασμένα εκ των υστέρων	Χειροκίνητη, επιρρεπής σε λάθη	Συνήθως αγνοούνται	Φτωχή
Παλαιό λογιστικό λογισμικό με πρόσθετη φορολογική ενότητα	Μερική, συχνά εκτός του καθολικού	Υποστηριζόμενη αλλά απομονωμένη	Περιορισμένη	Φτωχή έως μέτρια
Γενικό accounting API (τύπου Xero, QuickBooks)	Εξαρτάται από την πειθαρχία ενοποίησης	Διαφέρει ανά αγορά και πρόσθετο	Δεν επιβεβαιώνεται δημόσια για ροές θεωρούμενου προμηθευτή στο πλαίσιο της ΕΕ	Μέτρια
Nordlet (API-first, με επίκεντρο την ΕΕ)	Αμετάβλητο καθολικό, μεταδεδομένα φόρου ανά τιμολόγιο, κλείδωμα περιόδου	Εγγενής ΦΠΑ ανά χώρα, i.SAF, VIES, ομαδοποίηση έτοιμη για OSS	Πρωτοκλασάτα: `vatScheme`, `deemedSupplier` ανά τιμολόγιο	Ισχυρή

Ο πίνακας αντικατοπτρίζει τα διαθέσιμα δεδομένα εισόδου για αυτό το άρθρο. Όπου η δυνατότητα ενός ανταγωνιστή δεν τεκμηριώνεται στο ερευνητικό σημείωμα (research brief), αφήνεται ως μη δημόσια επιβεβαιωμένη αντί να θεωρηθεί δεδομένη.

Τι να χτίσετε πρώτα εάν ξεκινάτε τώρα

Εάν μια ομάδα στήνει ενσωματωμένη αυτοματοποίηση ΦΠΑ στην ΕΕ σε ένα cloud accounting API, η ακολουθία που τείνει να εξοικονομεί τις περισσότερες επαναλήψεις:

Μοντελοποίηση του αντισυμβαλλομένου και των σημάτων της χώρας του πριν από οτιδήποτε άλλο. Κάθε απόφαση下游 εξαρτάται από αυτό. Αποθήκευση των σημάτων και όχι μόνο της προέρχουσας χώρας.
Δόμηση του επιπέδου φορολογικών κατηγοριών. Αντιστοίχιση προϊόντων και υπηρεσιών σε κατηγορίες. Αντιστοίχιση κατηγοριών σε κωδικούς χωρών. Ποτέ μην αντιστοιχίζετε προϊόντα απευθείας σε συντελεστές.
Σύνδεση της επικύρωσης VIES με caching και ουρά αναθεώρησης. Μην αφήνετε τη διαθεσιμότητα του VIES να εμποδίζει το ταμείο σας.
Εκπομπή και κατανάλωση webhooks για αλλαγές κατάστασης τιμολογίων. Χρησιμοποιήστε κλειδιά ταυτοσημίας σε κάθε εγγραφή.
Κλείδωμα περιόδων μόλις κλείσουν. Επιβάλετε το στο API και όχι στην πολιτική.
Εξαγωγή δηλώσεων OSS από το καθολικό. Εάν η δήλωση απαιτεί ξεχωριστό υπολογιστικό φύλλο, το καθολικό δεν μεταφέρει αρκετά μεταδεδομένα.
Μόνο τότε, προσθήκη ηλεκτρονικής τιμολόγησης και ενοποίησης πύλης αναφοράς. Τα δεδομένα των ανάντη (upstream) πρέπει να είναι σωστά πρώτα.

Τα περισσότερα από αυτά αποτελούν εφάπαξ επενδύσεις που αποδίδουν σιωπηρά κάθε τρίμηνο. Μια απεριόριστη εταιρεία sandbox αποτελεί το φθηνότερο μέρος για να αποδείξετε την ακολουθία από άκρη σε άκρη.

FAQ

Είναι αρκετή η επικύρωση VIES για να αποδείξει ότι μια B2B πώληση απαλλάχθηκε ορθώς από τον ΦΠΑ (zero-rated);

Όχι από μόνη της. Το VIES επιβεβαιώνει ότι ένα ΑΦΜ/ΦΠΑ είναι έγκυρο σε μια δεδομένη χρονική στιγμή. Το αρχείο που είναι υπερασπίσιμο σε έλεγχο περιλαμβάνει επίσης τη χρονική σήμανση του ελέγχου, το payload της απάντησης, τη δηλωμένη χώρα του πελάτη και τα αποδεικτικά στοιχεία ότι τα αγαθά ή οι υπηρεσίες παραδόθηκαν σε αυτήν την οντότητα που διαθέτει ΑΦΜ/ΦΠΑ. Αποθηκεύστε τα όλα έναντι του τιμολογίου.

Μπορεί μια πλατφόρμα να βασιστεί στην αγορά (marketplace) για τη διαχείριση του ΦΠΑ και να παραλείψει τη δική της λογική;

Μόνο για τις συγκεκριμένες συναλλαγές όπου η αγορά θεωρείται ως ο προμηθευτής (deemed supplier) σύμφωνα με τους κανόνες της ΕΕ. Η λογιστική του εμπόρου εξακολουθεί να πρέπει να αντικατοπτρίζει σωστά αυτές τις συναλλαγές και τυχόν πωλήσεις εκτός αυτού του πεδίου εφαρμογής, συμπεριλαμβανομένων των άμεσων πωλήσεων και των ροών B2B, παραμένουν ευθύνη του εμπόρου. Η ασφαλέτερη προεπιλογή είναι η ρητή μοντελοποίηση του ρόλου ανά συναλλαγή.

Πόσο συχνά αλλάζουν πραγματικά οι συντελεστές ΦΠΑ στην ΕΕ ώστε να έχουν σημασία;

Αρκετά συχνά ώστε οι σκληρά κωδικοποιημένοι συντελεστές να προκαλούν πραγματικά προβλήματα. Οι κατηγορίες μειωμένων συντελεστών μετατοπίζονται, οι προσωρινοί συντελεστές εισάγονται και λήγουν, και εμφανίζονται νέοι κανόνες κρατών μελών. Ένα επίπεδο περιεχομένου συντελεστών με ημερομηνίες ισχύος δεν αποτελεί υπερβολικό σχεδιασμό. Αποτελεί τη βασική γραμμή (baseline).

Ποια είναι η διαφορά μεταξύ OSS και IOSS στην πράξη;

Το OSS καλύπτει διασυνοριακές B2C πωλήσεις αγαθών και ψηφιακών υπηρεσιών εντός της ΕΕ, οι οποίες αναφέρονται τριμηνιαία μέσω ενός ενιαίου κράτους μέλους. Το IOSS καλύπτει εισαγωγές χαμηλής αξίας στην ΕΕ, συνήθως καταναλωτικά αγαθά κάτω των 150 €. Και τα δύο προέρχονται από τα ίδια λογιστικά δεδομένα εάν το καθολικό επισημαίνει κάθε συναλλαγή με το καθεστώς της.

Σημαίνει ένα αμετάβλητο καθολικό ότι οι διορθώσεις είναι αδύνατες;

Όχι. Οι διορθώσεις γίνονται μέσω νέων εγγραφών και όχι με την επεξεργασία παλαιών. Ένα πιστωτικό τιμολόγιο αντιστρέφει ένα τιμολόγιο, μια αντιστρεφόμενη εγγραφή διορθώνει μια εσφαλμένη καταχώριση. Αυτό που αποτρέπει το αμετάβλητο είναι η σιωπηρή επανεγγραφή της ιστορίας, η οποία αποτελεί ακριβώς τη συμπεριφορά που αναζητούν οι ελεγκτές.