Payment reconciliation σε e-shop: συμφωνούν παραγγελίες, πάροχος πληρωμών και ERP;
Μια παραγγελία εμφανίζεται ως πληρωμένη στο e-shop. Αυτό δεν σημαίνει απαραίτητα ότι το ίδιο ποσό κατατέθηκε στην τράπεζα ή καταχωρίστηκε σωστά στο ERP. Μεσολαβούν προμήθειες, refunds, chargebacks, καθυστερήσεις και ομαδοποιημένα payouts.
Το payment reconciliation, δηλαδή η συμφωνία πληρωμών, είναι η διαδικασία που συνδέει κάθε επιχειρηματική συναλλαγή με την οικονομική της κίνηση. Είναι απαραίτητη όταν ο όγκος μεγαλώνει και το χειροκίνητο ταίριασμα αρχίζει να κρύβει λάθη.
Γιατί το ποσό της παραγγελίας δεν είναι το ποσό του payout
Ένας payment provider μπορεί να συγκεντρώνει πολλές πληρωμές σε μία κατάθεση. Από το συνολικό ποσό μπορεί να αφαιρούνται:
- προμήθειες συναλλαγών
- refunds
- chargebacks και σχετικά fees
- κρατήσεις ή adjustments
- μετατροπές νομίσματος
- αρνητικό υπόλοιπο προηγούμενης περιόδου
Άρα δεν αρκεί να συγκρίνετε μια τραπεζική κατάθεση με μία παραγγελία. Χρειάζεται ανάλυση των balance transactions που συνθέτουν κάθε payout.
Τα IDs που ενώνουν τα συστήματα
Η συμφωνία γίνεται πολύ ευκολότερη όταν αποθηκεύονται σταθερά αναγνωριστικά:
- order ID του e-shop
- payment intent ή transaction ID του παρόχου
- charge ID όπου υπάρχει
- refund ID
- payout ID
- invoice ή παραστατικό ERP
- merchant reference που περνά από το e-shop στον πάροχο
Αυτά τα IDs πρέπει να παραμένουν διαθέσιμα σε logs και exports. Το όνομα πελάτη ή το ποσό μόνο του δεν είναι ασφαλής τρόπος αντιστοίχισης.
Payment status και order status δεν είναι το ίδιο
Μια παραγγελία μπορεί να είναι:
- σε αναμονή πληρωμής
- εξουσιοδοτημένη αλλά όχι captured
- πληρωμένη
- μερικώς επιστραφείσα
- πλήρως επιστραφείσα
- υπό αμφισβήτηση
- ακυρωμένη πριν την είσπραξη
Το order fulfillment έχει δικό του lifecycle: προετοιμασία, αποστολή, παράδοση, επιστροφή. Η εφαρμογή πρέπει να συνδέει τα δύο χωρίς να τα συγχέει. Για παράδειγμα, μια επιστροφή προϊόντος δεν συνεπάγεται ότι ολοκληρώθηκε ήδη και το refund.
Από τα webhooks στη λογιστική συμφωνία
Τα webhooks ενημερώνουν γρήγορα το e-shop για αλλαγές, αλλά δεν είναι από μόνα τους reconciliation. Μπορεί να καθυστερήσουν, να επαναληφθούν ή να αποτύχουν προσωρινά.
Μια αξιόπιστη ροή περιλαμβάνει:
- επαλήθευση και idempotent επεξεργασία webhooks
- περιοδικό sync με το API του παρόχου
- αποθήκευση gross ποσού, fee και net ποσού
- αντιστοίχιση refunds και disputes
- σύνδεση συναλλαγών με payout
- export ή API ενημέρωση προς ERP
- report εξαιρέσεων που δεν ταιριάζουν αυτόματα
Το exception report είναι κρίσιμο. Ο στόχος δεν είναι να κρύβονται οι διαφορές, αλλά να περιορίζεται η ανθρώπινη εργασία στις λίγες περιπτώσεις που απαιτούν έλεγχο.
Refunds, μερικές επιστροφές και chargebacks
Τα refunds μπορεί να αφορούν ολόκληρη ή μέρος της παραγγελίας και να γίνονται διαφορετική ημέρα από την αρχική πληρωμή. Τα chargebacks ακολουθούν άλλη διαδικασία και μπορεί να αλλάξουν οικονομικά δεδομένα αρκετό καιρό αργότερα.
Για κάθε μεταβολή χρειάζεται σύνδεση με την αρχική συναλλαγή και σαφής κατάσταση στο e-shop και το ERP. Αν ένα refund αποτύχει, δεν πρέπει να εμφανίζεται ως ολοκληρωμένο μόνο επειδή ο χρήστης πάτησε το σχετικό κουμπί.
Αντικαταβολή, τραπεζική μεταφορά και πολλοί πάροχοι
Πολλά ελληνικά e-shop δεν έχουν μόνο κάρτες. Συνδυάζουν αντικαταβολή, τραπεζικές μεταφορές, wallets και περισσότερους από έναν payment providers. Κάθε μέθοδος χρειάζεται διαφορετικό evidence πληρωμής και χρόνο επιβεβαίωσης.
Η κοινή αναφορά πρέπει να κανονικοποιεί τις συναλλαγές χωρίς να χάνει τις ιδιαιτερότητες κάθε καναλιού. Στην αντικαταβολή, για παράδειγμα, η είσπραξη συνδέεται και με courier settlement, όχι με online charge.
Dashboard και καθημερινές εξαιρέσεις
Ένα πρακτικό dashboard reconciliation δείχνει:
- πληρωμές που δεν συνδέονται με παραγγελία
- παραγγελίες marked as paid χωρίς επιβεβαιωμένη συναλλαγή
- refunds που λείπουν από ERP
- payouts που δεν έχουν συμφωνηθεί
- διαφορές σε gross, fees και net
- συναλλαγές που περιμένουν έλεγχο
- τελευταία επιτυχημένη ώρα συγχρονισμού
Οι χρήστες χρειάζονται φίλτρα, export και audit history για κάθε χειροκίνητη διόρθωση.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry χαρτογραφούμε ολόκληρη τη διαδρομή από την παραγγελία μέχρι το payout και την καταχώριση στο ERP. Δεν θεωρούμε ότι ένα payment_success λύνει όλη τη ροή. Εξετάζουμε statuses, IDs, fees, refunds, disputes και τις εξαιρέσεις που σήμερα ελέγχει χειροκίνητα η ομάδα.
Υλοποιούμε integrations με payment APIs και ERP, αξιόπιστα webhooks, περιοδικά reconciliation jobs και dashboards εξαιρέσεων. Έτσι το e-shop αποκτά καθαρό audit trail και η οικονομική ομάδα μπορεί να εστιάζει στις πραγματικές αποκλίσεις αντί να αντιγράφει στοιχεία ανάμεσα σε exports.
Checklist
- Αποθηκεύονται όλα τα provider transaction IDs;
- Διαχωρίζονται order και payment statuses;
- Καταγράφονται gross, fees και net;
- Συνδέεται κάθε transaction με payout;
- Υποστηρίζονται partial refunds και disputes;
- Υπάρχει περιοδικός έλεγχος πέρα από τα webhooks;
- Ενημερώνεται το ERP με σταθερά references;
- Υπάρχει report για unmatched συναλλαγές;
- Καταγράφονται οι χειροκίνητες διορθώσεις;
- Έχουν δοκιμαστεί καθυστερήσεις, duplicates και αποτυχημένα refunds;
Συμπέρασμα
Η συμφωνία πληρωμών είναι το σημείο όπου η τεχνική ροή συναντά την οικονομική πραγματικότητα. Με σταθερά IDs, σωστά statuses και αυτοματοποιημένο exception handling, το e-shop γνωρίζει όχι μόνο τι πουλήθηκε αλλά και τι πραγματικά εισπράχθηκε.
Πηγές για περαιτέρω ανάγνωση: Stripe balance transaction reconciliation, Stripe payouts reconciliation, Stripe disputes.