myDATA και ηλεκτρονική τιμολόγηση: τι σημαίνουν για το λογισμικό της επιχείρησής σου

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

Η σύντομη απάντηση χωράει σε τρεις προτάσεις. Ένα ηλεκτρονικό τιμολόγιο, θεσμικά, δεν είναι αρχείο για να το διαβάσει άνθρωπος — είναι διαρθρωμένα δεδομένα για να τα διαβάσει μηχανή. Το myDATA, όπως το καταγράφει η Ευρωπαϊκή Επιτροπή, χρησιμοποιεί REST API για τη διαβίβαση δεδομένων, άρα κάτι στην αλυσίδα σου πρέπει να μιλάει μαζί του. Και για να γίνει αυτό έχεις τρεις δρόμους, με διαφορετικά πράγματα να αναλαμβάνεις σε καθέναν.

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

Τι είναι «ηλεκτρονικό τιμολόγιο» όταν το λέει ο νόμος

Ο ορισμός δεν είναι δικός μας ούτε κάποιου προμηθευτή. Είναι στο επίσημο ελληνικό κείμενο της ευρωπαϊκής οδηγίας για την ηλεκτρονική τιμολόγηση, και λέει: «ηλεκτρονικό τιμολόγιο»: τιμολόγιο που έχει εκδοθεί, διαβιβαστεί και παραληφθεί σε διαρθρωμένη ηλεκτρονική μορφή, η οποία επιτρέπει την αυτόματη και ηλεκτρονική επεξεργασία του (Οδηγία 2014/55/ΕΕ, άρθρο 2).

Διάβασέ τον δύο φορές, γιατί έχει δύο απαιτήσεις και όχι μία: διαρθρωμένη μορφή και αυτόματη επεξεργασία. Ένα PDF κόβεται σίγουρα στη δεύτερη, και δεν είναι ερμηνεία δική μας. Η Ευρωπαϊκή Επιτροπή, σε σελίδα ενημερωμένη στις 6 Μαρτίου 2026, γράφει: «Digital images, PDF and other visual digital forms of invoices remove the physical element and allow the invoices to be handled and archived in a more efficient way than paper. These formats however still require the invoice to be manually viewed and their data to be manually read and entered into AP systems.» (What is eInvoicing)

Η OpenPeppol το λέει ακόμα πιο κοφτά, στον οδηγό της για την ηλεκτρονική τιμολόγηση: «It is important to recognise that an eInvoice is not a PDF, a digital image, or a digital document created in a spreadsheet. While these formats are human readable, they cannot be processed without manual intervention.» Και συμπληρώνει κάτι που ξενίζει την πρώτη φορά: «To achieve its function, the data contained in an eInvoice does not need to be human readable.» (eInvoicing: Discovering Peppol, Μάιος 2024)

Εδώ ξεκολλάει η κουβέντα με τον προγραμματιστή σου. Η ερώτηση δεν είναι «στέλνουμε τα τιμολόγια ηλεκτρονικά;» — με email τα στέλνεις χρόνια. Είναι αν αυτό που φεύγει από το σύστημά σου μπαίνει στο σύστημα του παραλήπτη χωρίς να το πληκτρολογήσει άνθρωπος. Η Επιτροπή ορίζει το eInvoicing ακριβώς έτσι: «eInvoicing is the structured electronic exchange of invoice data between a supplier and a buyer, enabling full automation of processing without manual input.» (eInvoicing, σελίδα ενημερωμένη στις 31 Μαρτίου 2026).

Νόημα και γλώσσα: τα δύο επίπεδα που μπερδεύονται συνέχεια

Η ίδια οδηγία ορίζει χωριστά δύο πράγματα που οι περισσότερες κουβέντες τα κάνουν ένα. Το πρώτο είναι το «υπόδειγμα σημασιολογικών δεδομένων»: διαρθρωμένο σύνολο λογικά αλληλένδετων όρων και των εννοιών τους που προσδιορίζουν τα βασικά στοιχεία ενός ηλεκτρονικού τιμολογίου. Το δεύτερο είναι η «συντακτική δομή»: μηχαναγνώσιμη γλώσσα ή διάλεκτος που χρησιμοποιείται για να αναπαριστά τα στοιχεία δεδομένων που περιέχονται στο ηλεκτρονικό τιμολόγιο (Οδηγία 2014/55/ΕΕ, άρθρο 2).

Με απλά λόγια: το ένα επίπεδο λέει τι σημαίνει κάθε πεδίο — ποιος πουλάει, ποιος αγοράζει, τι είναι καθαρή αξία, τι είναι ΦΠΑ. Το άλλο λέει πώς γράφεται αυτό το πεδίο μέσα σε ένα αρχείο. Η Επιτροπή το διατυπώνει σε μία γραμμή: «The semantic eInvoicing standard does not define the structure of that electronic message. The message structure is called syntax.» (Required syntaxes, σελίδα ενημερωμένη στις 2 Φεβρουαρίου 2026).

Γιατί σε νοιάζει αυτή η διάκριση; Γιατί καθορίζει το σχήμα της ερώτησης που θα κάνεις. Το ευρωπαϊκό πρότυπο EN 16931 δουλεύει στο επίπεδο του νοήματος, και στο επίπεδο της γλώσσας υπάρχουν δύο συμβατές επιλογές: το UBL 2.1 και το UN/CEFACT CII. Οι φορείς που εμπίπτουν στην οδηγία, γράφει η Επιτροπή, παραλαμβάνουν τιμολόγια που συμμορφώνονται με το σημασιολογικό μοντέλο «and which are delivered by using either of these two syntaxes». Άρα το «ποια από τις δύο βγάζεις;» έχει σωστές απαντήσεις, και είναι δύο.

Το πρότυπο δεν είναι, επίσης, ένα αρχείο που κατεβάζεις. Η Επιτροπή απαριθμεί χωριστά μέρη με διακριτούς ρόλους: το σημασιολογικό μοντέλο, τον κατάλογο των συμβατών συντακτικών δομών και τις δεσμεύσεις για UBL 2.1 και για UN/CEFACT XML (Obtaining a copy of the European standard on eInvoicing). Το ίδιο το κείμενο ανήκει στη CEN, και αντίγραφό του «may be obtained free of charge from any CEN member».

Πού κάθεται το δικό σου σύστημα: το μοντέλο των τεσσάρων γωνιών

Πριν φτάσουμε στους τρεις δρόμους, χρειάζεσαι μία εικόνα. Η OpenPeppol εξηγεί γιατί τα παλιότερα μοντέλα δεν έφταναν: «Whilst these two and three corner data exchange methods remain in widespread use, they either do not provide automation, or they require the seller and buyer to use the same system or service provider.» Ή δεν αυτοματοποιούσαν τίποτα, ή σε ανάγκαζαν να είσαι στο ίδιο σύστημα με τον πελάτη σου.

Η λύση είναι τέσσερις γωνίες: «Peppol has led the way in establishing a four-corner model, where eInvoices can be created in one system and received in another, through a network of connected service providers, where the senders and receivers choose their service provider independently of each other.» Οι ρόλοι είναι ονομασμένοι: ο πωλητής είναι η γωνία 1, ο αγοραστής η γωνία 4, και οι δύο πάροχοι κάθονται στις γωνίες 2 και 3, ο καθένας διορισμένος από τη δική του πλευρά (eInvoicing: Discovering Peppol).

Και τώρα η πρόταση που απαντά ευθέως στο «τι σημαίνει για το λογισμικό μου»: «Note that both C1 and C4 operate in a non-standardised environment, which means that they can retain their existing systems and processes.» Η γωνία 1 είσαι εσύ. Το ότι μπαίνεις σε τυποποιημένο δίκτυο δεν σημαίνει ότι πρέπει να τυποποιηθεί το δικό σου σύστημα — σημαίνει ότι κάποιος μεταφράζει ανάμεσα σε αυτό και στο δίκτυο. Ποιος είναι αυτός ο κάποιος, είναι όλη η απόφαση.

Το δεύτερο επιχείρημα υπέρ αυτής της δομής χωράει σε μία φράση: «only one point of connection is needed to reach the whole network». Συνδέεσαι μία φορά, όχι μία φορά ανά πελάτη. Από κάτω υπάρχουν συγκεκριμένοι μηχανισμοί: το SMP είναι αποκεντρωμένο μητρώο που το λειτουργούν οι πάροχοι, ενώ το SML «is a central component in the Peppol Network, and is operated by the European Commission». Και η μεταφορά ανάμεσα στις δύο μεσαίες γωνίες γίνεται με AS4, με υπογραφή και κρυπτογράφηση σε επίπεδο μηνύματος και δυναμική ανακάλυψη μέσω SMP/SML (Peppol AS4 Profile). Το δίκτυο, δηλαδή, δεν είναι «email με άλλο όνομα».

Δύο λεπτομέρειες που λύνουν παρεξηγήσεις. Δεν χρειάζεται να γίνεις μέλος πουθενά: «buyers and suppliers do not need to become members of OpenPeppol to use the Peppol Network and Specifications» (For End Users). Και υπάρχει δημόσιος κατάλογος συμμετεχόντων, δωρεάν στην αναζήτηση, που δείχνει τις δυνατότητες του καθενός — αλλά ο ίδιος ο OpenPeppol προειδοποιεί ότι «not every registered Peppol receiver can be found in the Directory» (Peppol Directory), οπότε μην τον χρησιμοποιήσεις ως απόδειξη ότι κάποιος δεν μπορεί να παραλάβει.

Υπάρχει και μια πέμπτη γωνία στην περιγραφή της OpenPeppol, που είναι το γεφύρι προς τη φορολογική διοίκηση: «By adding a fifth corner to the model… the eInvoicing model can simply be extended to meet the reporting requirements of tax administrations at the same time as meeting the needs of businesses.» Η ίδια ροή που εκδίδει το παραστατικό μπορεί να τροφοδοτεί και την αναφορά. Πώς γίνεται αυτό στην Ελλάδα και πότε, δεν το λέμε εμείς — το λέει η ΑΑΔΕ.

Το myDATA είναι REST API — άρα κάτι στη ροή σου πρέπει να μιλάει

Η μοναδική δομική δήλωση για το myDATA που καταφέραμε να διαβάσουμε στις 2 Σεπτεμβρίου 2026 σε πηγή που φορτώνει είναι μία, και είναι αρκετή: «MyDATA utilizes a REST API for data transmission.» Βρίσκεται στο country factsheet της Ευρωπαϊκής Επιτροπής για την Ελλάδα, και εκείνη η σελίδα φέρει ημερομηνία ενημέρωσης 14 Αυγούστου 2025 — πάνω από έναν χρόνο πριν (eInvoicing in Greece).

Βάζουμε την ημερομηνία μπροστά επίτηδες, γιατί η ίδια η Επιτροπή δηλώνει για αυτά τα δελτία: «The European Commission does not guarantee the accuracy of the information and data included in the eInvoicing Country Factsheets…legislation and policies are subject to changes as a process of continuous evolution.» (eInvoicing Country Factsheets). Άρα το χρησιμοποιούμε μόνο για δομικά στοιχεία, ποτέ για κανόνα που θα σε δεσμεύσει.

Ότι το API υπάρχει και έχει περιβάλλον δοκιμών φαίνεται και ζωντανά: η φόρμα εγγραφής στο myDATA REST API για δοκιμές φόρτωνε κανονικά στα ελληνικά τη μέρα του ελέγχου και ζητάει Όνομα Χρήστη, ΑΦΜ και Κλειδί εισόδου. Αποδεικνύει δύο πράγματα και σταματάει εκεί: ότι ο απευθείας δρόμος περνάει από διαπιστευτήρια, και ότι υπάρχει δοκιμαστικό περιβάλλον πριν την παραγωγή.

Το ίδιο δελτίο, με την ίδια παλιά ημερομηνία, περιγράφει και τον δημόσιο τομέα: «The National Interoperability Centre (KE.D) is a central IT system that acts as the single access point for receiving B2G e-invoices», που «plays a central role by receiving eInvoices through certified service providers on the Peppol network». Εκεί κουμπώνει η Ελλάδα με το ευρωπαϊκό δίκτυο. Στην ίδια σελίδα καταγράφεται και η επιλογή σε επίπεδο προδιαγραφής: «Peppol BIS Billing CIUS 3.0 is used in Greece» — μια συγκεκριμένη υποπερίπτωση του ευρωπαϊκού προτύπου, όχι κάτι εθνικά εφευρεμένο.

Ότι η χώρα συμμετέχει θεσμικά φαίνεται και από πηγή που ενημερώνεται: στον κατάλογο των Peppol Authorities, η Ελλάδα εκπροσωπείται από τη Γενική Γραμματεία Πληροφοριακών Συστημάτων (Peppol Authorities). Υπάρχει και δημόσιος κατάλογος πιστοποιημένων παρόχων με ελληνικές εγγραφές· δεν καρφώνουμε αριθμό, γιατί ο κατάλογος αλλάζει και φέρει δική του ημερομηνία ενημέρωσης.

Οι τρεις δρόμοι, και τι αναλαμβάνεις σε καθέναν

Ό,τι κι αν σου προτείνουν, είναι παραλλαγή τριών δρόμων. Δεν υπάρχει σωστός και λάθος· υπάρχει «ποιος κρατάει τι», και αυτό είναι δική σου απόφαση, όχι του προγραμματιστή.

Δρόμος 1: μέσω παρόχου

Το σύστημά σου συνεχίζει να κάνει ό,τι κάνει, και ο πάροχος αναλαμβάνει τη μετατροπή, την αποστολή και την επικύρωση. Είναι η περίπτωση της γωνίας 1 που «can retain their existing systems and processes». Κερδίζεις ένα σημείο σύνδεσης για όλο το δίκτυο· αναλαμβάνεις μια εξάρτηση, γιατί ο πάροχος γίνεται μέρος της ροής έκδοσης τιμολογίων σου.

Δύο πράγματα πριν το θεωρήσεις λυμένο. Ο πάροχος του πελάτη σου δεν σε δεσμεύει: αποστολέας και παραλήπτης διαλέγουν ανεξάρτητα. Και η πιστοποίηση δεν είναι μόνιμη — ο κατάλογος του OpenPeppol προειδοποιεί: «Certified as Service Providers may be removed from this list if they are subject to non-compliance penalties.»

Δρόμος 2: μέσω του εμπορικού ή λογιστικού σου προγράμματος

Πολλά έτοιμα προγράμματα το κάνουν ήδη μόνα τους, και το καταγράφει η OpenPeppol: «as many software vendors supply systems that natively produce and consume Peppol eInvoices, their customers at C1 and C4 are already able to send and receive Peppol eInvoices through C2 and C3, without the need for transformation, thereby achieving straight-through processing.» Αν είσαι σε αυτή την κατηγορία, η δουλειά σου είναι ερωτήσεις και ρυθμίσεις, όχι κώδικας.

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

Δρόμος 3: απευθείας από δικό σου σύστημα

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

Τι αναλαμβάνεις: διαπιστευτήρια και δοκιμές· την ορθότητα κάθε πεδίου· την επικύρωση σε όλες της τις στρώσεις· και τη συντήρηση όταν αλλάξει η προδιαγραφή. Το τελευταίο δεν είναι θεωρητικό: η τεκμηρίωση φέρει τίτλο «Peppol BIS Billing 3.0 - May 2026 Release» και το ίδιο κείμενο δηλώνει έκδοση 3.0.21 — ένα έγγραφο, δύο ετικέτες, μια προδιαγραφή που εξελίσσεται (Peppol BIS Billing 3.0).

Αν αυτό που στήνεις είναι e-shop, η τιμολόγηση είναι μία μόνο από τις αποφάσεις που παίρνονται πριν γραφτεί κώδικας· οι υπόλοιπες είναι εδώ.

Τι πρέπει να μπορεί να παράγει το σύστημά σου

Η οδηγία απαριθμεί τα «βασικά στοιχεία του ηλεκτρονικού τιμολογίου», και η λίστα κάνει μια χαρά για λίστα ελέγχου απέναντι σε ό,τι βγάζει σήμερα το πρόγραμμά σου (Οδηγία 2014/55/ΕΕ, άρθρο 6):

• αναγνωριστικά της επεξεργασίας και του τιμολογίου
• χρονική περίοδος του τιμολογίου
• στοιχεία του πωλητή και στοιχεία του αγοραστή
• στοιχεία του δικαιούχου πληρωμής
• στοιχεία του φορολογικού αντιπροσώπου του αγοραστή
• στοιχεία αναφοράς της σύμβασης
• λεπτομερή στοιχεία παράδοσης
• οδηγίες για την πληρωμή
• στοιχεία που αφορούν απαλλαγή ή επιβάρυνση
• πληροφορίες για το συγκεκριμένο στοιχείο του τιμολογίου
• συνολικά ποσά του τιμολογίου και ανάλυση του ΦΠΑ

Διάβασέ τη μία φορά και μετά κοίτα την οθόνη σου. Τα «στοιχεία αναφοράς της σύμβασης» και τα «λεπτομερή στοιχεία παράδοσης» λείπουν πιο συχνά από συστήματα που κατά τα άλλα τυπώνουν μια χαρά τιμολόγια — γιατί μέχρι σήμερα τα έγραφε κάποιος στο πεδίο «παρατηρήσεις», και ένα πεδίο παρατηρήσεων δεν είναι δομημένο δεδομένο.

Ένα επίπεδο πιο κάτω, στο αρχείο, η προδιαγραφή γίνεται πολύ συγκεκριμένη. Κάθε μήνυμα κουβαλάει δύο αναγνωριστικά: «All messages contains Business process type (BT-23, ProfileID in UBL) and Specification identifier (BT-24, CustomizationID in UBL)… Specification identifier identifies the kind of message and the rules applied.» Δεν είναι διακοσμητικά: λένε στον παραλήπτη με ποιους κανόνες να διαβάσει ό,τι του έστειλες.

Αν σου φαίνεται υπερβολικά τεχνικό για να το ρωτήσεις, δες το ανάποδα: είναι πέντε γραμμές που τις απαντά αμέσως όποιος το έχει όντως υλοποιήσει, και δεν τις απαντά καθόλου όποιος δεν το έχει (δομή τιμολογίου UBL).

Γιατί το «βγάζω XML» δεν σημαίνει «συμμορφώνομαι»

Είναι η πιο συχνή παρανόηση, και τη διαψεύδει η ίδια η προδιαγραφή. Η επικύρωση γίνεται σε στρώσεις, με αυτή τη σειρά: «Validation of syntax… Validation against EN 16931… CIUS - General rules… CIUS - Country qualified validation rules». Η τελευταία ενεργοποιείται από τη χώρα του πωλητή: «The rule is triggered by the given country code of the seller (BT-40).»

Πρακτικά: ένα αρχείο μπορεί να είναι έγκυρο XML χωρίς τα σωστά αναγνωριστικά· ή να τα έχει και να παραβιάζει κανόνα του ευρωπαϊκού προτύπου· ή να είναι εντάξει με το πρότυπο και να κόβεται σε κανόνα χώρας. Τέσσερα διαφορετικά «όχι», με τέσσερις διορθώσεις. Γι’ αυτό η ερώτηση δεν είναι «βγάζεις XML;» αλλά «περνάει επικύρωση, και με τι το ελέγχεις;».

Υπάρχει και αντικειμενική απάντηση σε αυτό. Η Επιτροπή διατηρεί μητρώο που δίνει «direct access to different technical resources (validation artefacts, code lists, etc.) that are used in eInvoicing implementations when using the eInvoicing standard» (Registry of supporting artefacts). Δηλαδή το «περνάει επικύρωση» δεν είναι θέμα γνώμης — ελέγχεται με εργαλεία που δεν τα φτιάχνει ούτε ο προμηθευτής σου ούτε εμείς.

Και μια υπενθύμιση ότι η δουλειά δεν είναι μόνο κώδικας: το πλαίσιο διαλειτουργικότητας του Peppol απαιτεί «a set of rules and specifications» που εφαρμόζονται με συνέπεια από τις αρχές και τους πιστοποιημένους παρόχους (Peppol Interoperability Framework).

Οι ερωτήσεις που κάνεις στον προμηθευτή του λογισμικού σου

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

1. Ποια συντακτική δομή παράγετε; Οι συμβατές είναι δύο, UBL 2.1 και UN/CEFACT CII. Μια απάντηση τύπου «XML» δεν είναι απάντηση.
2. Ποιο CustomizationID και ποιο ProfileID βγαίνει στα παραστατικά μου; Είναι δύο συγκεκριμένες τιμές, όχι περιγραφή. Ζήτησε ένα δείγμα αρχείου και κοίταξέ τες.
3. Περνάει επικύρωση, και σε ποιες στρώσεις; Σύνταξη, EN 16931, γενικοί κανόνες, κανόνες χώρας. Ζήτησε να δεις το αποτέλεσμα του ελέγχου, όχι να σου το πουν.
4. Πώς ενημερώνεται η υλοποίηση όταν βγαίνει νέα έκδοση της προδιαγραφής; Η τεκμηρίωση φέρει έκδοση 3.0.21 και ετικέτα κυκλοφορίας του Μαΐου 2026. Θα υπάρξει επόμενη.
5. Ποιος μιλάει με το REST API και με ποια διαπιστευτήρια; Το δικό μου σύστημα, το δικό σας, ή ένας τρίτος; Και σε ποιο περιβάλλον δοκιμάζεται πριν πάει σε παραγωγή;
6. Αν αύριο αλλάξω πάροχο ή πρόγραμμα, τι από αυτά μένει δικό μου; Τα δεδομένα, τα αρχεία των παραστατικών και οι ρυθμίσεις. Η απάντηση πρέπει να είναι γραπτή.

Δύο πράγματα που δεν θα κάνουμε εδώ. Δεν θα σου προτείνουμε προμηθευτή: ο ίδιος ο OpenPeppol βάζει ρητή αποποίηση στον κατάλογο λογισμικού του — «The software has not been accredited by OpenPeppol.» (Links to Software). Και δεν θα σου πούμε πόσο «κρατάει» καμία από τις τρεις υλοποιήσεις: εξαρτάται από το τι έχεις ήδη δομημένο, και όποιος δίνει αριθμό χωρίς να έχει δει τη ροή σου, τον μαντεύει.

Τι δεν λέει αυτό το κείμενο, και πού πας γι’ αυτό

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

Πήγαινε στην ΑΑΔΕ για το τι ισχύει, και στον λογιστή σου για το τι σημαίνει αυτό για τη δική σου επιχείρηση. Έλα σε εμάς με το επόμενο ερώτημα: τι πρέπει να κάνει το λογισμικό σου για να το υποστηρίξει. Είναι δύο διαφορετικές δουλειές, και μπερδεύονται τόσο συχνά που η μία περιμένει την άλλη.

Αν κρατήσεις τρία πράγματα, κράτα αυτά. Το PDF δεν είναι ηλεκτρονικό τιμολόγιο, και το λέει η πηγή, όχι εμείς. Το σύστημά σου δεν χρειάζεται απαραίτητα να αλλάξει — χρειάζεται να αποφασίσεις ποιος μεταφράζει ανάμεσα σε αυτό και στο δίκτυο. Και το «βγάζω αρχείο» δεν είναι «περνάω επικύρωση».