API διπλογραφικού καθολικού για τη λογιστική marketplaces

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

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

Τι είναι στην πραγματικότητα ένα API διπλογραφικού καθολικού

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

Το τμήμα του «διπλογραφικού» βασίζεται στον τετρακοσίων ετών λογιστικό κανόνα ότι κάθε συναλλαγή επηρεάζει τουλάχιστον δύο λογαριασμούς. Το τμήμα του «API» σημαίνει ότι το προϊόν σας, και όχι ένας ανθρώπινος λογιστής, είναι αυτό που πραγματοποιεί την κλήση. Το τμήμα του «αμετάβλητου» (immutable) σημαίνει ότι οι διορθώσεις γίνονται μέσω αντιστροφής εγγραφών και όχι με την τροποποίηση του ιστορικού. Συνδυαστικά, αυτές οι τρεις ιδιότητες καθιστούν τα τελικά βιβλία έτοιμα για έλεγχο αντί απλώς τακτοποιημένα.

Ένας χρήσιμος ορισμός εργασίας:

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

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

Γιατί τα marketplaces χρειάζονται συγκεκριμένα αυτή τη λύση

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

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

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

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

Πώς λειτουργεί το API, βήμα προς βήμα

Η μηχανική της διαδικασίας είναι λιγότερο εξotic από όσο ακούγεται. Μια τυπική ροή για μια παραγγελία marketplace μοιάζει ως εξής:

1. Η πλατφόρμα σας εκπέμπει ένα χρηματοοικονομικό συμβάν. Ένας αγοραστής ολοκληρώνει την αγορά του. Το backend σας καλεί το API του καθολικού με στοιχεία όπως: αναγνωριστικό παραγγελίας, αγοραστής, πωλητής, ακαθάριστο ποσό, συντελεστής ΦΠΑ, προμήθεια πλατφόρμας, νόμισμα και ένα κλειδί ταυτότητας (idempotency key).

2. Το καθολικό κατασκευάζει μια ημερολογιακή εγγραφή. Το API μεταφράζει αυτό το συμβάν σε χρεώσεις και πιστώσεις. Για μια απλή πώληση σε marketplace, αυτό μπορεί να σημαίνει χρέωση ενός λογαριασμού ταμείου σε διέλευση (cash-in-transit), πίστωση ενός λογαριασμού υποχρεώσεων προς πωλητή για το καθαρό ποσό, πίστωση ενός λογαριασμού εσόδων πλατφόρμας για την προμήθεια και πίστωση ενός λογαριασμού ΦΠΑ πληρωτέου για το τμήμα του φόρου. Όλα ισοσκελισμένα. Όλα καταχωρισμένα ατομικά.

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

4. Οι επακόλουθες αναφορές ενημερώνονται σε πραγματικό χρόνο. Το ισοζύγιο, τα υπόλοιπα υποχρεώσεων προς πωλητές, οι περιλήψεις ΦΠΑ και η κατάσταση αποτελεσμάτων χρήσης (P&L) αντικατοπτρίζουν τη νέα εγγραφή αμέσως. Δεν υπάρχει νυχτερινή εργασία, καμία εξαγωγή, κανένα παράθυρο συμφωνισμών όπου οι αριθμοί βρίσκονται σε φάση «διευθέτησης».

5. Τα webhooks ειδοποιούν το σύστημά σας. Συμβάντα όπως sale_invoice.paid ή bank_transaction.matched αποστέλλονται στα τελικά σημεία σας, επιτρέποντας στο προϊόν σας να αντιδρά χωρίς επαναλαμβανόμενα αιτήματα (polling). Σε συνδυασμό με τα κλειδιά ταυτότητας, αυτό διασφαλίζει ότι οι επαναλήψεις είναι ασφαλείς και δεν εισχωρούν διπλότυπες εγγραφές όταν υπάρξουν διακοπές στο δίκτυο.

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

Το σχέδιο λογαριασμών είναι το σημείο όπου γίνεται ο σχεδιασμός

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

Ορισμένα πρότυπα επαναλαμβάνονται σε διάφορα marketplaces:

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

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

Αμετάβλητο, κλείδωμα περιόδου και γιατί ενδιαφέρονται οι ελεγκτές

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

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

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

ΦΠΑ στην ΕΕ: το ζήτημα που καταναλώνει χρόνο μηχανικών

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

Ένα σοβαρό API καθολικού για την ΕΕ διαχειρίζεται τουλάχιστον τα εξής:

• Επικύρωση μέσω VIES για τους αριθμούς ΦΠΑ πωλητών και αγοραστών, ιδανικά με τα αποτελέσματα αποθηκευμένα στην προσωρινή μνήμη (cache) και αποτυπωμένα στη συναλλαγή
• Λογική συντελεστών ΦΠΑ ανά χώρα, συμπεριλαμβανομένων μειωμένων συντελεστών και απαλλαγών
• Παραγωγή μητρώου i.SAF για λιθουανικές δηλώσεις και ισοδύναμες δομημένες εξόδους όπου άλλα κράτη μέλη το απαιτούν
• Ηλεκτρονική τιμολόγηση Peppol BIS 3.0 για δικαιοδοσίες που μεταβαίνουν σε υποχρεωτική ηλεκτρονική τιμολόγηση
• Διαχείριση OSS/IOSS για διασυνοριακές πωλήσεις B2C

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

Ο συμφωνισμός λογαριασμών ως πηγή εξοικονόμησης χρόνου

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

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

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

Κατασκευή έναντι αγοράς έναντι ενσωμάτωσης

Οι ομάδες των marketplaces τείνουν να εξετάζουν τρεις δρόμους. Δείτε πώς συγκρίνονται στους άξονες που έχουν σημασία.

Προσέγγιση	Χρόνος έως την παραγωγή	Ετοιμότητα ελέγχου	Χειρισμός ΦΠΑ ΕΕ	Ενσωμάτωση στο προϊόν σας
Κατασκευή δικού σας καθολικού	12 έως 24+ μήνες	Εξαρτάται αποκλειστικά από την ομάδα σας	Το χτίζετε εσείς, ανά χώρα	Ναι
Συγχρονισμός σε Xero/QuickBooks	Εβδομάδες	Καλός για τη λογιστική πλευρά, αδύναμος για ροές marketplace	Μερικός, απαιτούνται πρόσθετα	Όχι, βρίσκεται σε ξεχωριστό εργαλείο
Ενσωμάτωση API καθολικού (π.χ. Nordlet)	Εβδομάδες	Ενσωματωμένη μέσω αμετάβλητου καθολικού και κλειδώματος περιόδου	Ενσωματωμένος για την ΕΕ, συμπεριλαμβανομένων VIES και i.SAF	Ναι, μέσω API και SDKs

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

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

Τι να προσέχετε όταν αξιολογείτε ένα API καθολικού

Ένας σύντομος κατάλογος ελέγχου που αξίζει να έχετε ανοιχτό κατά τη διάρκεια κλήσεων με προμηθευτές:

• Αμετάβλητη διπλογραφική αποθήκευση με διορθώσεις μέσω αντιστροφής εγγραφών, όχι γραμμές που μπορούν να επεξεργαστούν
• Κλείδωμα περιόδου με καταγεγραμμένες ενέργειες επαναλήψεως
• Κλειδιά ταυτότητας (idempotency keys) σε κάθε τελικό σημείο εγγραφής
• Webhooks για τα συμβάντα στα οποία πρέπει να αντιδρά το προϊόν σας, όχι απλώς ένα API polling
• Πληκτρολογημένα SDKs (typed SDKs) στις γλώσσες που χρησιμοποιεί πραγματικά η ομάδα σας
• Λογική ΦΠΑ ανά χώρα συμπεριλαμβανομένων των VIES, i.SAF ή ισoδύναμων, και OSS/IOSS
• Υποστήριξη πολλαπλών εταιρειών εάν διαχειρίζεστε πολλές οντότητες ή σκοπεύετε να το κάνετε
• Πρόσβαση βάσει ρόλων αρκετά λεπτομερή ώστε να διαχωρίζονται οι προγραμματιστές, οι λογιστές και οι θεατές
• Εξαγωγές αναφορών σε XLSX, PDF και JSON, με ειδοποιήσεις webhook όταν μεγάλες αναφορές είναι έτοιμες
• Ένα περιβάλλον sandbox που αντικατοπτρίζει τη συμπεριφορά της παραγωγής, όχι μια περιορισμένη επίδειξη

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

Τι θα έκανα πρώτα

Εάν ένα marketplace ξεκινά αυτό το έργο από το μηδέν, η ακολουθία που εξοικονομεί τον περισσότερο κόπο είναι η εξής:

1. Αποτυπώστε τις πραγματικές ροές χρημάτων σε έναν λευκοπίνακα πριν γράψετε οποιονδήποτε κώδικα. Ποιος χρωστάει σε ποιον, σε ποια στιγμή, με ποιο νόμισμα, με ποια φορολογική μεταχείριση ΦΠΑ.
2. Συντάξτε το σχέδιο λογαριασμών από αυτόν τον χάρτη. Υποχρεώσεις προς πωλητές, έσοδα πλατφόρμας, ΦΠΑ πληρωτέος ανά χώρα, αποθεματικά. Ζητήστε από έναν λογιστή να το ελέγξει πριν περάσει στην παραγωγή.
3. Επιλέξτε το επίπεδο του καθολικού. Κατασκευή, συγχρονισμός ή ενσωμάτωση. Νίνεστε ειλικρινείς σχετικά με το ποια επιλογή μπορεί πραγματικά να παραδώσει και να συντηρήσει η ομάδα σας.
4. Υλοποιήστε μία ροή από άκρη σε άκρη: παραγγελία προς τιμολόγιο προς πληρωμή προς συμφωνισμός. Αποδείξτε ότι ισοσκελίζεται. Στη συνέχεια, προχωρήστε σε κλίμακα.
5. Ενεργοποιήστε το κλείδωμα περιόδου μόλις κλείσει καθαρά ο πρώτος μήνας. Η πειθαρχία αυτή λειτουργεί σωρευτικά.

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

FAQ

Είναι ένα API διπλογραφικού καθολικού το ίδιο με μια λογιστική ενσωμάτωση;

Όχι. Μια ενσωμάτωση συγχρονίζει δεδομένα από το προϊόν σας σε ένα εξωτερικό λογιστικό εργαλείο, συνήθως με καθυστέρηση. Ένα API καθολικού είναι το ίδιο το λογιστικό σύστημα, στο οποίο γράφετε απευθείας, σε πραγματικό χρόνο. Η διάκριση έχει σημασία διότι οι ενσωματώσεις χάνουν την πιστότητα στα άκρα: μερικές πληρωμές, πολλαpλά νομίσματα, επιμερισμοί marketplaces. Ένα API καθολικού τα καταγράφει αυτά εγγενώς.

Δεν μπορούμε απλώς να χρησιμοποιήσουμε τις αναφορές της Stripe ή της Adyen;

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

Πόσο αμετάβλητο είναι το αμετάβλητο στην πράξη;

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

Τι γίνεται με τα marketplaces εκτός ΕΕ;

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

Πόσος χρόνος απαιτείται πραγματικά για την υλοποίηση;

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