E-shop: Γιατί δεν συμφωνούν οι πωλήσεις, οι courier και η τράπεζα;

Ένα ηλεκτρονικό κατάστημα πραγματοποιεί 2.000 παραγγελίες μέσα στον μήνα.

Το WooCommerce εμφανίζει ένα ποσό.

Ο payment provider άλλο.

Η courier στέλνει διαφορετική εκκαθάριση.

Η τράπεζα έχει διαφορετικές πιστώσεις.

Το ERP εμφανίζει διαφορετικό σύνολο.

Ποιο είναι σωστό;

Η απάντηση είναι:

ενδεχομένως όλα — αλλά το καθένα περιγράφει διαφορετικό στάδιο.

Σε ένα σύγχρονο e-shop η πραγματική δουλειά δεν είναι να συγκρίνουμε απλώς τα τελικά σύνολα.

Χρειάζεται να μπορούμε να ακολουθήσουμε:

παραγγελία → παραστατικό → αποστολή → πληρωμή → settlement → τράπεζα → λογιστική.

Και όταν υπάρχει επιστροφή:

return → refund → πιστωτική διαδικασία → stock → τελική συμφωνία.

1. Παραγγελία, πώληση και είσπραξη είναι τρία διαφορετικά γεγονότα

Μία παραγγελία μπορεί:

• να ακυρωθεί,
• να αποτύχει η πληρωμή,
• να αποσταλεί με αντικαταβολή,
• να παραδοθεί αλλά να αποδοθεί αργότερα η είσπραξη,
• να επιστραφεί,
• να γίνει partial refund,
• να αμφισβητηθεί με chargeback.

Γι’ αυτό πρέπει να διακρίνονται:

Εμπορική κατάσταση

Τι έχει συμβεί με την παραγγελία.

Φορολογική κατάσταση

Ποιο παραστατικό έχει εκδοθεί και ποια φορολογική διαδικασία έχει ακολουθηθεί.

Οικονομική κατάσταση

Τι ποσό εισπράχθηκε και τι παραμένει εκκρεμές.

Το completed στο WooCommerce ή στο Shopify δεν μπορεί να λειτουργεί ως απάντηση και για τα τρία.

2. Το Order ID πρέπει να ακολουθεί τη συναλλαγή

Για κάθε παραγγελία ιδανικά πρέπει να μπορούν να συσχετιστούν:

• Order ID,
• SKU,
• φορολογικό παραστατικό,
• payment transaction,
• settlement,
• courier voucher,
• refund,
• πιστωτικό,
• κίνηση αποθέματος.

Δεν χρειάζεται κάθε εφαρμογή να χρησιμοποιεί τον ίδιο αριθμό.

Χρειάζεται όμως αξιόπιστο mapping.

Σε 20 παραγγελίες τον μήνα ένα πρόβλημα μπορεί να βρεθεί χειροκίνητα.

Σε 5.000 παραγγελίες αυτό δεν είναι σύστημα.

3. Γιατί η κατάθεση του payment provider δεν είναι ο τζίρος

Παράδειγμα:

Τα 11.600 ευρώ που εμφανίζονται στην τράπεζα δεν είναι αυτομάτως οι πωλήσεις.

Αποτελούν το αποτέλεσμα:

εισπράξεις – refunds – fees = settlement.

Και υπάρχει επιπλέον χρονική διαφορά.

Settlement που πιστώνεται στις 2 Οκτωβρίου μπορεί να περιλαμβάνει συναλλαγές της 30ής Σεπτεμβρίου.

Η σωστή λύση είναι settlement reconciliation.

4. Η αντικαταβολή πρέπει να συμφωνείται ανά παραγγελία

Έστω ότι η courier καταθέτει 4.850 ευρώ.

Δεν αρκεί να γνωρίζουμε ότι «τα χρήματα μπήκαν».

Πρέπει να γνωρίζουμε από ποιες αποστολές προέκυψαν.

Η σωστή αλυσίδα είναι:

Order → voucher → delivery → collection → remittance.

Αυτό επιτρέπει να εντοπίζεται:

• παραδομένη αλλά μη αποδοθείσα αντικαταβολή,
• λανθασμένο ποσό,
• διπλή εγγραφή,
• επιστροφή που παρέμεινε ανοικτή.

Δύο σφάλματα μπορεί να αλληλοεξουδετερωθούν.

+100 ευρώ σε μία παραγγελία.

-100 ευρώ σε άλλη.

Το συνολικό ποσό συμφωνεί.

Οι συναλλαγές όμως παραμένουν λανθασμένες.

5. Settlement delay: μια χρονική διαφορά που μπορεί να γίνει πρόβλημα ρευστότητας

Ακόμη και όταν όλα είναι σωστά λογιστικά, ο χρόνος είσπραξης έχει σημασία.

Ένα e-shop μπορεί να πληρώνει:

• Google/Meta σήμερα,
• προμηθευτή σήμερα,
• courier αυτή την εβδομάδα,

αλλά να εισπράττει:

• cards μετά από settlement,
• COD αργότερα,
• marketplace σε συγκεκριμένο cycle.

Αυτό δημιουργεί ανάγκη κεφαλαίου κίνησης.

Πρακτικός έλεγχος με τα εργαλεία μας

Μπορείτε να ξεκινήσετε με «Υπολογισμός Κεφαλαίου Κίνησης» και «Πρόβλεψη Ρευστότητας 13 Εβδομάδων».

Τα εργαλεία δεν πραγματοποιούν τη λογιστική συμφωνία των transactions.

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

6. Refund δεν σημαίνει ότι έκλεισε η επιστροφή

Ένας πελάτης επιστρέφει προϊόν και το e-shop πραγματοποιεί refund.

Αυτό είναι μόνο ένα μέρος.

Πρέπει να εξεταστούν:

1. αρχική πώληση,
2. επιστροφή χρημάτων,
3. κατάλληλο παραστατικό,
4. φορολογική διαβίβαση όπου απαιτείται,
5. φυσική επιστροφή,
6. κατάσταση προϊόντος,
7. ενημέρωση αποθέματος,
8. τελική λογιστική συμφωνία.

Το επικίνδυνο automation

Αυτόματο:

refund → restock +1

δεν είναι πάντοτε σωστό.

Το προϊόν μπορεί να έχει ανοιχτεί, χρησιμοποιηθεί, υποστεί φθορά ή να απαιτεί έλεγχο.

Υπάρχει φυσικά στην αποθήκη.

Δεν σημαίνει ότι είναι διαθέσιμο προς νέα πώληση.

7. Chargeback και refund δεν είναι το ίδιο

Στο refund η επιχείρηση επιστρέφει χρήματα.

Στο chargeback η συναλλαγή αμφισβητείται μέσω του payment system.

Μπορεί να έχουμε:

• αρχική είσπραξη,
• δέσμευση,
• αφαίρεση σε επόμενο settlement,
• chargeback fee,
• μεταγενέστερη αντιστροφή.

Αν όλες οι αφαιρέσεις αντιμετωπίζονται σαν refund, χάνεται η πραγματική οικονομική αιτία.

Η λογιστική πρέπει να ακολουθεί το οικονομικό γεγονός και όχι απλώς το αρνητικό ποσό στο report.

8. Marketplace: άλλο gross sales και άλλο καθαρό αποτέλεσμα

Ένα marketplace μπορεί να παρακρατεί:

• ποσοστιαία προμήθεια,
• fixed fee,
• payment fee,
• advertising fees,
• refunds,
• άλλες συμβατικές χρεώσεις.

Γι’ αυτό πρέπει να διαχωρίζονται:

gross marketplace sales → refunds → fees → settlement.

Για να ελέγξετε αν μια marketplace πώληση είναι οικονομικά συμφέρουσα, χρησιμοποιήστε το εργαλείο «Κερδοφορία Πώλησης σε Marketplace».

Το reconciliation ελέγχει αν οι συναλλαγές είναι σωστές.

Το calculator εξετάζει αν αυτές οι συναλλαγές είναι οικονομικά συμφέρουσες.

Χρειαζόμαστε και τα δύο.

9. Η ίδια marketplace πώληση μπορεί να μετρηθεί δύο φορές

Παραγγελία marketplace εισάγεται αυτόματα στο ERP ή στο WooCommerce.

Στο τέλος του μήνα εξάγονται:

• marketplace report,
• WooCommerce report.

Και προστίθενται.

Η ίδια πώληση μπορεί να μετρηθεί δύο φορές.

Χρειάζεται διάκριση:

πραγματική συναλλαγή ≠ αριθμός εφαρμογών στις οποίες εμφανίστηκε.

Το channel πρέπει να αποτελεί χαρακτηριστικό της παραγγελίας, όχι δεύτερη πώληση.

Για το ποιος εκδίδει το παραστατικό σε πωλήσεις μέσω marketplace, δείτε το Marketplace: ποιος εκδίδει το παραστατικό.

10. Όταν το ίδιο προϊόν έχει τρεις κωδικούς

WooCommerce:

SHOE-BLACK-42

ERP:

00018843

Marketplace:

BLK42-01

Αν δεν υπάρχει mapping, δημιουργούνται αποκλίσεις σε:

• stock,
• κόστος,
• returns,
• reports,
• αγορές.

Το πρόβλημα γίνεται μεγαλύτερο με:

• variants,
• sizes,
• colors,
• bundles,
• multipacks.

Ένα bundle είναι χαρακτηριστικό παράδειγμα

Πωλείται:

SET-A = 1 × Χ + 2 × Ψ

Το e-shop αφαιρεί ένα SET-A.

Η πραγματική αποθήκη πρέπει να αφαιρέσει:

• Χ: -1
• Ψ: -2.

Αν το ERP δεν γνωρίζει αυτή τη σχέση, η διαφορά stock είναι αναμενόμενη.

11. Stock discrepancy: μη διορθώνετε απλώς το 12 σε 9

Το e-shop δείχνει 12 τεμάχια.

Η φυσική απογραφή δείχνει 9.

Το σωστό ερώτημα δεν είναι:

«Πώς θα το κάνουμε να γράφει 9;»

Αλλά:

«Πού πήγαν τα τρία;»

Μπορεί να υπάρχουν:

• pending orders,
• μη ενημερωμένες αποστολές,
• επιστροφές,
• damaged goods,
• marketplace order,
• λάθος mapping,
• φυσικό κατάστημα,
• πραγματικό έλλειμμα.

Για την οικονομική σημασία της διαχείρισης stock, χρησιμοποιήστε το εργαλείο «Πόσα Χρήματα Έχω Δεμένα στην Αποθήκη;».

Το calculator δεν διορθώνει τη διαφορά του ERP.

Βοηθά όμως να αποτιμηθεί η οικονομική σημασία της διαχείρισης stock.

Σχετικό: Αποτίμηση αποθέματος: πώς επηρεάζει το αποτέλεσμα.

12. «Το ERP έστειλε» δεν σημαίνει πάντα «ολοκληρώθηκε»

Ένα πρόγραμμα μπορεί να επιχειρήσει να διαβιβάσει ένα παραστατικό.

Χρειάζεται όμως exception monitoring για περιπτώσεις όπως:

• failed,
• rejected,
• pending,
• duplicate.

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

Είναι να εμφανίζονται άμεσα οι εξαιρέσεις.

Για τις συνηθέστερες περιπτώσεις, δείτε: myDATA: τα πιο συχνά λάθη διαβίβασης και η διόρθωσή τους.

13. Τι αλλάζει από 1 Οκτωβρίου 2026

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

Η υποχρεωτική ηλεκτρονική τιμολόγηση της Α.1128/2025 αφορά τις συναλλαγές που εμπίπτουν στο πεδίο εφαρμογής της απόφασης, ιδίως εγχώριες συναλλαγές χονδρικής (B2B), τις προβλεπόμενες συναλλαγές B2B προς τρίτες χώρες και συναλλαγές με φορείς της Γενικής Κυβέρνησης (B2G). Δεν πρέπει να συγχέεται με το σύνολο των αποδείξεων λιανικής B2C ενός ηλεκτρονικού καταστήματος.

Η μεταβατική εφαρμογή έως 31/12/2026 ισχύει υπό τις συγκεκριμένες προϋποθέσεις που έχει θέσει η ΑΑΔΕ.

Για ένα e-shop το πρακτικό ζήτημα είναι να είναι ξεκάθαρο:

• ποιο σύστημα δέχεται την παραγγελία,
• ποιο εκδίδει το φορολογικό στοιχείο,
• ποιο είναι υπεύθυνο για τη σχετική ηλεκτρονική διαδικασία,
• πώς ενημερώνονται ERP και e-shop.

Όταν δύο συστήματα θεωρούν ταυτόχρονα ότι είναι υπεύθυνα για την ίδια ενέργεια, αυξάνεται ο κίνδυνος duplicates.

14. Courier και Ψηφιακή Διακίνηση: μία λεπτομέρεια που αφορά άμεσα τα e-shop

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

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

Άρα:

courier voucher ή tracking number δεν σημαίνει από μόνο του ότι έχει καλυφθεί κάθε φορολογική απαίτηση της διακίνησης.

Αυτό είναι σημείο που πρέπει να εξετάζεται με βάση την πραγματική ροή του e-shop.

Αναλυτικά για το πλαίσιο: Ψηφιακό δελτίο αποστολής: τι αλλάζει στη διακίνηση.

15. Στις 12 Οκτωβρίου 2026 ενεργοποιείται η Φάση Β1

Η ισχύουσα αναφορά είναι:

Από 12/10/2026 ενεργοποιούνται για τις υπόχρεες οντότητες τα σχετικά δεδομένα της Φάσης Β1 της ψηφιακής διακίνησης.

Η επόμενη φάση για την Ενιαία Κωδικοποίηση Ειδών προβλέπεται από 01/01/2027.

Για το e-commerce αυτό ενισχύει την ανάγκη να συνδέονται σωστά:

order → stock → shipment → delivery/return.

16. Μία παραγγελία 124 ευρώ και πέντε διαφορετικές εγγραφές

Έστω πώληση 124 ευρώ με ΦΠΑ 24%.

Αν τα 122 ευρώ καταχωριστούν ως πώληση:

λάθος.

Αν τα 124 και τα 122 καταχωριστούν ως δύο έσοδα:

επίσης λάθος.

Υπάρχει μία πώληση.

Υπάρχουν όμως πολλαπλά records που εξηγούν διαφορετικά στάδια της ίδιας συναλλαγής.

Αυτό ακριβώς είναι το αντικείμενο της λογιστικής συμφωνίας.

17. Ένα σωστό month-end close για e-shop

Το month-end close δεν σημαίνει ότι όλα πρέπει να περιμένουν το τέλος του μήνα.

Σε e-shop σημαντικού όγκου, settlements, COD και exceptions μπορεί να χρειάζονται καθημερινό ή εβδομαδιαίο έλεγχο.

18. Το πιο χρήσιμο report μπορεί να είναι το Exception Report

Με 10.000 orders δεν χρειάζεται ένας άνθρωπος να ελέγχει 10.000 σωστές συναλλαγές.

Χρειάζεται να εμφανίζονται οι 30 που είναι λάθος.

Παραδείγματα:

• delivered αλλά όχι remitted,
• payment χωρίς order,
• order χωρίς παραστατικό,
• refund χωρίς αντίστοιχη διαδικασία,
• unmatched settlement,
• duplicate order,
• stock movement χωρίς αιτία,
• rejected transmission.

Αυτό μειώνει τον χρόνο ελέγχου και αυξάνει την πιθανότητα το πραγματικό πρόβλημα να εντοπιστεί εγκαίρως.

19. Πού βοηθούν τα εργαλεία μας και πού χρειάζεται λογιστικός έλεγχος;

Τα δύο δεν είναι ανταγωνιστικά.

Είναι διαφορετικές βαθμίδες της ίδιας διαδικασίας.

Τα Εργαλεία Επιχειρήσεων βοηθούν να απαντήσουμε:

• Είναι οικονομικά συμφέρουσα η τιμή;
• Τι κοστίζει πραγματικά μια έκπτωση;
• Ποιο είναι το break-even;
• Τι αφήνει μια marketplace sale;
• Πόσο κεφάλαιο βρίσκεται στο stock;
• Πόσο working capital απαιτείται;
• Πώς διαμορφώνεται το ταμείο των επόμενων 13 εβδομάδων;

Η λογιστική συμφωνία πρέπει να απαντήσει:

• Οι συναλλαγές έχουν καταγραφεί σωστά;
• Συμφωνούν orders, παραστατικά, settlements και τράπεζα;
• Οι επιστροφές έχουν ολοκληρωθεί σε όλα τα συστήματα;
• Υπάρχουν εκκρεμείς COD;
• Υπάρχουν duplicates;
• Υπάρχουν φορολογικές ή λογιστικές αποκλίσεις;

Για τα πρώτα ερωτήματα, μπορείτε να ξεκινήσετε από τα Εργαλεία Επιχειρήσεων.

Τα δωρεάν εργαλεία μπορούν να χρησιμοποιηθούν από τον επιχειρηματία για πρώτη επιχειρηματική ανάλυση και what-if σενάρια.

Όταν όμως η ερώτηση είναι:

«Γιατί το ERP, η courier, το WooCommerce και η τράπεζα δεν συμφωνούν;»

τότε χρειάζεται εξέταση των πραγματικών συναλλαγών.

20. Ποιος είναι υπεύθυνος για τι;

Λογιστής / φοροτεχνικός

Καθορίζει και ελέγχει:

• λογιστική και φορολογική απεικόνιση,
• απαιτούμενα δεδομένα,
• συμφωνίες,
• παραστατικά,
• σημαντικές αποκλίσεις,
• ελεγκτικά reports.

Επιχείρηση

Γνωρίζει:

• πραγματική εμπορική διαδικασία,
• contracts,
• returns,
• courier rules,
• ειδικούς επιχειρηματικούς κανόνες.

Developer / ERP provider

Υλοποιεί:

• APIs,
• mappings,
• integrations,
• webhooks,
• exports,
• automations.

Ο developer δεν πρέπει να αποφασίζει μόνος του τη λογιστική λογική.

Ο λογιστής δεν χρειάζεται να γράψει το API.

Χρειάζονται όμως σωστές προδιαγραφές και κοινή εικόνα του workflow.

Συμπέρασμα: η σωστή ερώτηση δεν είναι μόνο «πόσο πουλήσαμε;»

Χρειάζεται να μπορούμε να αποδείξουμε τη διαδρομή:

Order → Invoice → Shipment → Payment → Settlement → Bank → Accounting.

Και στην αντίστροφη ροή:

Return → Refund → Credit → Stock → Reconciliation.

Στο λογιστικό – φοροτεχνικό γραφείο Δρ. Χρήστος Χατζηχρήστος, στη Θεσσαλονίκη, υποστηρίζουμε επιχειρήσεις και ηλεκτρονικά καταστήματα στη λογιστική και φορολογική παρακολούθηση των πραγματικών συναλλαγών τους.

Παράλληλα, τα Εργαλεία Επιχειρήσεων του drcc.eu είναι διαθέσιμα ώστε ο επιχειρηματίας να μπορεί να εξετάζει βασικά οικονομικά σενάρια πριν λάβει αποφάσεις ή πριν συζητήσει τα αποτελέσματα με το γραφείο.

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

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