Πώς Θα Έχτιζα ένα Σύστημα Λογιστικής που Κρύβει το Καθολικό

Άμεση απάντηση

Ένα σύστημα συντονισμού λογιστικής είναι ένα επίπεδο που μετατρέπει εισερχόμενα εμπορικά έγγραφα σε αποδεκτές διαβιβάσεις myDATA και σε έναν φάκελο που μπορεί να υπογράψει ένας λογιστής. Ένα PDF σε inbox, ένα τιμολόγιο προμηθευτή, μια τραπεζική κίνηση, γίνεται μια ταξινομημένη εγγραφή ή ένα κενό με όνομα, όχι ένα chat που «κάνει τα βιβλία». Αυτό είναι ένα σχεδιασμένο σύστημα, όχι ένα ανεπτυγμένο έργο.

Βασικά σημεία

• Το πρόβλημα του πελάτη δεν είναι λογιστική θεωρία. Είναι ότι τα έγγραφα ακόμα ταξιδεύουν μέσω email πριν γίνουν βιβλία.
• Το myDATA ήδη δημοσιεύει REST API. Η σύνδεση με την ΑΑΔΕ δεν είναι το προϊόν. Το προϊόν είναι το matching.
• Ο νόμος 4308/2014 κρατά τη διοίκηση υπεύθυνη για το λογιστικό σύστημα. Ένα εργαλείο τρίτου δεν τους την αφαιρεί.

Ποιο πρόβλημα κατέχει στην πραγματικότητα αυτό το σύστημα;

Μια ελληνική ΜμΕ ήδη εκδίδει και λαμβάνει τιμολόγια. Κάποιος ακόμα φωτογραφίζει μια χάρτινη απόδειξη, προωθεί ένα PDF, ή αφήνει ένα statement προμηθευτή σε inbox μέχρι την Παρασκευή. Ο λογιστής ανοίγει το αρχείο, αποφασίζει τι είναι, το πληκτρολογεί στο λογισμικό, και αργότερα μαθαίνει ότι το myDATA απέρριψε τη διαβίβαση ή ότι το έγγραφο του αντισυμβαλλόμενου δεν ταιριάζει.

Σήμερα η διαδρομή συνήθως είναι αυτή:

1. Τα έγγραφα φτάνουν ως συνημμένα email, εικόνες WhatsApp, ή ένας φάκελος σε desktop.
2. Κάποιος προωθεί τον σωρό στον λογιστή, συχνά ελλιπή.
3. Ο λογιστής ταξινομεί κάθε γραμμή: έσοδο, έξοδο, μεταχείριση ΦΠΑ, αντισυμβαλλόμενος.
4. Το λογισμικό διαβιβάζει ό,τι μπορεί μέσω ERP, provider, τιμολόγιο, ή φόρμας.
5. Απορρίψεις και αναντιστοιχίες επιστρέφουν ως ακόμα ένα email.

Τίποτα από αυτά δεν είναι το δύσκολο κομμάτι της λογιστικής. Είναι πληροφορία που κινείται ανάμεσα σε μια επιχείρηση, έναν προμηθευτή, την ΑΑΔΕ, και έναν λογιστή, που ο καθένας κρατά ένα κομμάτι της. Αυτό είναι το επίπεδο συντονισμού, και είναι το προϊόν.

Η υπάρχουσα ροή εργασίας που θα χαρτογραφούσα πρώτα

Πριν από οποιαδήποτε κλήση σε μοντέλο, θα καθόμουν με έναν λογιστή και έναν πελάτη και θα διέτρεχα έναν ολόκληρο μήνα από την αρχή ως το τέλος.

Αν αυτός ο πίνακας είναι λάθος, το σύστημα είναι λάθος. Θα προτιμούσα να ξοδέψω μια εβδομάδα στον πίνακα παρά έναν μήνα σε ένα chatbot που καταχωρεί σε καθολικό.

Πώς θα έτρεχε το σύστημα

Πάρτε ένα τιμολόγιο. Ένας προμηθευτής στέλνει invoice.pdf. Το σύστημα το διαβάζει σε πεδία που μπορεί να ελέγξει ένας άνθρωπος: επωνυμία προμηθευτή, ΑΦΜ, ημερομηνία, καθαρό 820 €, ΦΠΑ 196,80 € στον κανονικό συντελεστή 24%. Το ταιριάζει με τον προμηθευτή που ο λογιστής ήδη κρατά στο αρχείο του, και προτείνει μια ταξινόμηση από τους δημοσιευμένους πίνακες χαρακτηρισμού, όχι από ένα λογιστικό σχέδιο που εφηύρα εγώ. Ο λογιστής το αποδέχεται ή το αλλάζει. Τότε το υπάρχον κανάλι διαβιβάζει.

Αν το myDATA απορρίψει το payload, ο λόγος δεν μένει σε ένα log. Το σύστημα ονοματίζει το κενό. Αν το RequestDocs δείξει αργότερα ότι ο προμηθευτής διαβίβασε διαφορετικό καθαρό ποσό, ρωτά έναν άνθρωπο: τα ποσά δεν ταιριάζουν — ζητάμε διόρθωση από τον προμηθευτή, ή το αφήνουμε στον λογιστή; Αποφασίζει άνθρωπος. Μόνο τότε, μια νέα προσπάθεια.

Δομημένο intake

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

Ταξινόμηση

Το σύστημα προτείνει μια μεταχείριση με το σκεπτικό και τη βεβαιότητά του. Οι τρέχουσες τεχνικές προδιαγραφές της ΑΑΔΕ περιλαμβάνουν μια αναβαθμισμένη μέθοδο SendExpensesClassification και συνδυασμούς χαρακτηρισμού δημοσιευμένους ως πίνακες, όχι ως εικασία. Θα χρησιμοποιούσα αυτούς τους δημοσιευμένους συνδυασμούς ως περιορισμό, όχι θα εφηύρα ένα λογιστικό σχέδιο που δεν αναγνωρίζει η εφορία.

Διαβίβαση

Οι αποδεκτές εγγραφές βγαίνουν μέσα από το κανάλι που η επιχείρηση ήδη έχει: REST API ERP, αδειοδοτημένος πάροχος ηλεκτρονικής τιμολόγησης, ή τιμολόγιο. Δεν θα έστηνα δεύτερο σετ διαπιστευτηρίων «επειδή ο agent χρειάζεται δικό του login». Η εγγραφή για το REST API είναι ήδη μια διαδικασία με πύλη Taxisnet στην πλατφόρμα myDATA.

Απόρριψη και διαχείριση αντισυμβαλλόμενου

Ο ενδιαφέρων βρόχος είναι αυτός μετά το SendInvoices. Οι προδιαγραφές περιγράφουν τα RequestDocs / RequestTransmittedDocs να επιστρέφουν πληροφορίες απόκλισης και απόρριψης από τον αντισυμβαλλόμενο. Αυτή είναι μια επιφάνεια προϊόντος: δείξε την αναντιστοιχία, πες τι λείπει, και περίμενε έναν άνθρωπο. Μια επανάληψη που ξαναστέλνει τυφλά το ίδιο payload είναι ο τρόπος να πάρεις ένα σίγουρο λάθος δύο φορές.

Έλεγχος λογιστή

Η περίοδος κλείνει όταν ένας κατονομαζόμενος λογιστής αποδέχεται τον φάκελο. Το σύστημα προσχεδιάζει. Δεν γίνεται τα βιβλία.

Τι μένει υπό ανθρώπινο έλεγχο;

Ο νόμος 4308/2014 είναι σαφής. Η διοίκηση είναι υπεύθυνη για ένα αξιόπιστο λογιστικό σύστημα και για τις οικονομικές καταστάσεις. Η χρήση τρίτου — λογισμικού ή εξωτερικού λογιστή — δεν τους απαλλάσσει. Οι καταστάσεις εγκρίνονται από το διοικητικό όργανο και υπογράφονται από εξουσιοδοτημένο μέλος και από τον υπεύθυνο λογιστή.

Άρα το σύστημα δεν:

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

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

Πώς θα μετρούσα τη διαδρομή

Μόνο baselines, πριν χτιστεί οτιδήποτε:

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

Καμία αξίωση μετατροπής ή εξοικονόμησης ωρών μέχρι να υπάρξουν αυτά τα νούμερα.

Πότε είναι λάθος αυτό το build

• Τα βιβλία ήδη ζουν σε ένα ERP που διαβιβάζει καθαρά. Τότε διακοσμείς έναν σωλήνα που ήδη δουλεύει.
• Ο όγκος είναι μια χούφτα τιμολόγια τον χρόνο. Δεν υπάρχει επίπεδο συντονισμού να απορροφήσει.
• Τα έγγραφα δεν φτάνουν ψηφιακά. Αν η είσοδος είναι ένα κουτί παπουτσιών, το σύστημα είναι ένας σαρωτής με έξτρα βήματα.
• Κανείς εσωτερικά δεν μπορεί να ελέγξει ταξινομήσεις. Χωρίς αυτόν τον ελεγκτή δεν υπάρχει εποπτευόμενος βρόχος, μόνο έκθεση σε κίνδυνο.
• Το πλεονέκτημα του λογιστή είναι η κρίση σε οριακές περιπτώσεις, όχι η επανακαταχώρηση. Τότε χτίζεις λογισμικό ενάντια στο κομμάτι της δουλειάς που δεν είναι προς πώληση.

Πώς συνδέεται αυτό με το engagement

Αυτή η περίπτωση έχει το ίδιο σχήμα με το μοντέλο προσφοράς-σε-κράτηση φορτίου: ένας πελάτης που ήδη καταλαβαίνει το αποτέλεσμα αναγκάζεται να μάθει τη γραφειοκρατία του κλάδου. Η διαφορά είναι στην πλευρά προσφοράς. Οι μεταφορείς συχνά αρνούνται να συνδεθούν. Η ΑΑΔΕ ήδη δημοσίευσε το interface. Το σημείο συμφόρησης μετακινείται στο matching και στο άτομο που επιτρέπεται να υπογράψει, κάτι πιο κοντά στη σήμανση CE.

Το σύστημα που έχω πραγματικά χτίσει είναι ο βρόχος πωλήσεων με AI μέσα σε CRM. Το μοτίβο απόρριψης που θα επαναχρησιμοποιούσα στις διαβιβάσεις είναι πιο κοντά σε τον βρόχο έρευνας που ξέρει πότε να μην τρέξει.

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

Το build ξεκινά από τον λογιστή, όχι από το API

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