Αναγνώριση εσόδων (IFRS 15 / ASC 606)

Αναβολή εσόδων ανά γραμμή και προγραμματισμένη αναγνώριση: υποχρεώσεις συμβολαίου, μέθοδοι βάσει χρόνου, κατανομή τιμής συναλλαγής, προβλέψεις επιστροφών, συνδρομές και τροποποιήσεις συμβολαίων. Η προεπιλεγμένη διαδρομή παραμένει αμετάβλητη - μια απλή γραμμή τιμολογίου εξακολουθεί να αναγνωρίζει το έσοδο εξ ολοκλήρου κατά την έκδοση (χρονική στιγμή), το οποίο είναι συμβατό με τα πρότυπα 606/15 για μια ενιαία υποχρέωση εκπλήρωσης που ικανοποιείται κατά την παράδοση. Όλα τα παρακάτω είναι προαιρετικά (opt-in) ανά γραμμή τιμολογίου.

Το λογισμικό είναι ικανό για τα πρότυπα 606/15 (606/15-capable). Η οντότητα αναφοράς είναι αυτή που συμμορφώνεται (ή δεν συμμορφώνεται). Η επιλογή της σωστής μεθόδου ανά υποχρέωση, η εκτίμηση των τιμών μεμονωμένης πώλησης και των ποσοστών επιστροφής, καθώς και η κρίση σχετικά με το εάν τα εναπομείναντα αγαθά ή υπηρεσίες είναι διακριτά κατά την τροποποίηση, παραμένουν λογιστικές κρίσεις που πραγματοποιεί ο συντάκτης των οικονομικών καταστάσεων.

Λογαριασμοί

Τρεις λογαριασμοί του σχεδίου λογαριασμών υποστηρίζουν τις ροές, συνδεδεμένοι ως κλειδιά κανόνων καταχώρισης (posting rules) (με δυνατότητα παράκαμψης ανά εταιρεία μέσω του ledger/posting-rules/update): revenue.deferredIncome → 4910 "Ateinančių laikotarpių pajamos" (υποχρέωση συμβολαίου), revenue.refundLiability → 4450 "Grąžinimo įsipareigojimai pirkėjams", revenue.contractAsset → 2910 "Sukauptos pajamos". Οι υφιστάμενες εταιρείες αποκτούν τους λογαριασμούς με εκ νέου εφαρμογή του προτύπου σχεδίου λογαριασμών (ledger/accounts/apply-template).

Υποχρεώσεις εκπλήρωσης στις γραμμές τιμολογίου

Οι γραμμές του sales/invoices/create|update δέχονται το πεδίο recognition: { method, startDate, endDate, milestones } όπου το method είναι ένα από τα εξής:

Μέθοδος	Συμπεριφορά κατά την έκδοση	Αναγνώριση
point_in_time (προεπιλογή)	Πίστωση (CR) εσόδων εξ ολοκλήρου	κατά την έκδοση, αμετάβλητη
ratable (startDate..endDate)	Πίστωση (CR) αναβαλλόμενων εσόδων	μηνιαίο χρονοδιάγραμμα σταθμισμένο ανά ημέρα εντός της περιόδου υπηρεσίας
milestone (milestones[], ποσοστά που αθροίζουν σε 100)	Πίστωση (CR) αναβαλλόμενων εσόδων	μία δόση ανά ορόσημο, αναγνωριζόμενη κατά το συμβάν
percent_complete	Πίστωση (CR) αναβαλλόμενων εσόδων	μέσω αθροιστικών αναφορών προόδου

Οι λογαριασμοί πελατών (AR) και ΦΠΑ παραμένουν ανέπαφοι: η έκδοση καταχωρεί χρέωση (DR) 2410 για το μεικτό ποσό, πίστωση (CR) 4492 για τον ΦΠΑ και κατανέμει το καθαρό ποσό μεταξύ εσόδων (γραμμές χρονικής στιγμής) και 4910 (αναβαλλόμενες γραμμές). Τα χρονοδιαγράμματα αποθηκεύονται στο νόμισμα βάσης της εταιρείας με την ισοτιμία της ημερομηνίας έκδοσης - το sales/recognition-schedules/list (sales:read) εμφανίζει κάθε δόση με κατάσταση pending | recognized | cancelled.

Κατανομή τιμής συναλλαγής. Με περισσότερες από μία γραμμές, το πεδίο standaloneSellingPrice σε κάθε γραμμή κατανέμει το καθαρό ποσό του τιμολογίου στις υποχρεώσεις κατ' αναλογία (IFRS 15 §76–80). Το κατανεμημένο ποσό - και όχι η αναγραφόμενη τιμή της γραμμής - καθορίζει τον διαχωρισμό εσόδων/αναβαλλόμενων ποσών και τα χρονοδιαγράμματα. Ο ΦΠΑ παραμένει στις γραμμές του τιμολογίου όπως αναφέρεται.

Μηχανχανισμός αναγνώρισης (Recognition engine)

Η αναγνώριση καταχωρεί χρέωση (DR) 4910 / πίστωση (CR) εσόδων (λογαριασμός υπηρεσίας/προϊόντος και κέντρο κόστους από την αρχική γραμμή) ως ενιαίο ημερολόγιο ανά εκτέλεση, το οποίο καταγράφεται στο sales/recognition/runs/list.

• POST /v1/sales/recognition/compute (sales:read) { asOfDate? } - δοκιμαστική προεπισκόπηση (dry-run) των οφειλόμενων δόσεων αναλογικής κατανομής.
• POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } - καταχώριση οφειλόμενων δόσεων αναλογικής κατανομής ή ακριβώς των δόσεων που ορίζονται από τα scheduleIds (οποιαδήποτε μέθοδος).
• POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } - γραμμές ποσοστού ολοκλήρωσης: αναφορά αθροιστικής προόδου. Η νεοαποκτηθείσα διαφορά καταχωρείται αμέσως, ενώ οι μειώσεις (regressions) απορρίπτονται.
• POST /v1/sales/recognition/summary (sales:read) - ποσό που έχει αναγνωριστεί μέχρι σήμερα, εναπομείναν ποσό, πλήθος εκκρεμών και επόμενη ημερομηνία οφειλής ανά γραμμή, συν τα σύνολα της εταιρείας.

Τρία συμβάντα οδηγούν την αναγνώριση χωρίς polling: το κλείσιμο περιόδου (ledger/periods/lock) αναγνωρίζει πρώτα όλα όσα οφείλονται έως το τέλος της περιόδου, καταχωρημένα την ημερομηνία λήξης της περιόδου. Η έκδοση πρωτοκόλλου παράδοσης (sales/acts/issue) αναγνωρίζει τις εκκρεμείς δόσεις οροσήμων του συνδεδεμένου τιμολογίου κατά την ημερομηνία του πρωτοκόλλου. Και ένα χρονόμετρο λήξης χρονοδιαγράμματος (schedule-due timer) ενεργοποιείται για την επόμενη ημερομηνία λήξης αναλογικής κατανομής και πραγματοποιεί καταχώριση ανά εταιρεία όταν αυτή φτάσει (μια κλειστή περίοδος επαναλαμβάνει την προσπάθεια αργότερα). Τα ορόσημα βασίζονται επίτηδες σε συμβάντα - η expectedDate ενός οροσήμου είναι πληροφορία σχεδιασμού και ποτέ δεν πυροδοτεί από μόνη της αναγνώριση.

Μεταβλητό τίμημα - υποχρέωση επιστροφής

Το πεδίο refundEstimatePercent σε μια γραμμή πιστώνει αυτό το μερίδιο του (κατανεμημένου) καθαρού ποσού στον λογαριασμό 4450 αντί για τα έσοδα ή τα αναβαλλόμενα έσοδα κατά την έκδοση - οι αναμενόμενες επιστροφές εξαιρούνται από την τιμή συναλλαγής (IFRS 15 §55). Η κατάσταση ανά τιμολόγιο βρίσκεται στο sales/refund-liability/list (εκτιμώμενη, αναλωθείσα, παρατηρηθείσα διακανονισμένη επιστροφή, εναπομείνασα).

Πραγματικά ποσά: ένα πιστωτικό τιμολόγιο έναντι του τιμολογίου χρεώνει τον λογαριασμό 4450 έως το ποσό της εναπομείνασας υποχρέωσης πριν αγγίξει τα έσοδα. Η ενέργεια sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } αναθεωρεί την εκτίμηση και καταχωρεί τη διαφορά έναντι των εσόδων προς οποιαδήποτε κατεύθυνση (με κατώτατο όριο το αναλωθέν ποσό). Οι επιστροφές διακανονισμού από πάροχο υπηρεσιών πληρωμών (PSP) που ταιριάζουν με το τιμολόγιο καταγράφονται στην υποχρέωση και εκπέμπουν ένα webhook refund_liability.actual - δεν καταχωρούνται απευθύνονται απευθείας στον 4450, διότι η απομείωση των εσόδων και του ΦΠΑ εκροών απαιτεί το πιστωτικό τιμολόγιο ως παραστατικό ΦΠΑ.

Συνδρομές - συμφωνίες σε τιμολόγια

Ορίστε σε μια συμφωνία ένα billingPeriod (monthly | quarterly | annual) και το agreements/generate-invoice (agreements:write) δημιουργεί το πρόχειρο (draft) τιμολόγιο της επόμενης μη τιμολογημένης περιόδου: γραμμές από τα στοιχεία της συμφωνίας (ή την value ως μία γραμμή ανά περίοδο), καθεμία με αναγνώριση βάσει χρόνου καθ' όλη τη διάρκεια της περιόδου υπηρεσίας. Η ενέργεια agreements/billing/run { asOfDate? } σαρώνει όλες τις ενεργές συμφωνίες, δημιουργεί κάθε ληξιπρόθεσμη περίοδο και θέτει σε λήξη τις συμφωνίες που έχουν τιμολογηθεί πλήρως μετά την ημερομηνία λήξης τους. Οι τελικές σύντομες περιόδοι υπολογίζονται κατ' αναλογία ημερών. Το πεδίο autoRenew παρατείνει τη διάρκεια κατά το δικό της μήκος και συνεχίζει την τιμολόγηση. Τα παραγόμενα τιμολόγια φέρουν το πεδίο agreementId (με δυνατότητα φιλτραρίσματος στο sales/invoices/list).

Τροποποιήσεις συμβολαίων

POST /v1/sales/recognition/modify (sales:write) { invoiceLineId, approach, date?, newEndDate?, newMilestones? }:

• prospective - ακύρωση του εκκρεμούς χρονοδιαγράμματος και εκ νέου κατανομή του μη αναγνωρισμένου υπολοίπου σύμφωνα με τους νέους όρους από την ημερομηνία τροποποίησης (τα εναπομείναντα αγαθά/υπηρεσίες είναι διακριτά: IFRS 15 §20(a), §21(a)). Οι γραμμές χρονικής κατανομής δέχονται newEndDate. Οι γραμμές οροσήμων δέχονται newMilestones (ποσοστά του εναπομείναντος ποσού).
• cumulative_catch_up (μόνο για γραμμές χρονικής κατανομής) - επανυπολογισμός των εσόδων σαν να ίσχυαν οι νέοι όροι από την αρχή και καταχώριση της διαφοράς αμέσως, προς οποιαδήποτε κατεύθυνση (ενιαία υποχρέωση μερική εκπλήρωσης: §21(b)). Το υπόλοιπο κατανέμεται εκ νέου.

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

Όρια

• Τα χρονοδιαγράμματα και οι καταχωρίσεις αναγνώρισης είναι ποσά σε νόμισμα βάσης (EUR) καθορισμένα με την ισοτιμία της ημερομηνίας έκδοσης. Τα αναβαλλόμενα υπόλοιπα δεν επαναποτιμώνται για συναλλαγματικές διαφορές μετά την έκδοση.
• Ο λογαριασμός περιουσιακού στοιχείου συμβολαίου (2910) παρέχεται στο σχέδιο λογαριασμών και ως κλειδί καταχώρισης, αλλά καμία αυτοματοποιημένη ροή μη τιμολογημένων εσόδων δεν καταχωρείται ακόμη σε αυτόν - η αναγνώριση πριν από την τιμολόγηση αποτελεί προς το παρόν χειροκίνητη εγγραφή ημερολογίου.
• Η κατανομή απαιτεί τιμή μεμονωμένης πώλησης σε όλες τις γραμμές του τιμολογίου ή σε καμία. Η προσέγγιση του υπολοίπου (§79(c)) δεν έχει υλοποιηθεί.
• Οι υποχρεώσεις επιστροφής παρακολουθούνται προ ΦΠΑ σε επίπεδο τιμολογίου. Το αντίστοιχο περιουσιακό στοιχείο για το δικαίωμα ανάκτησης επιστραφέντων αγαθών (§B25) δεν μοντελοποιείται.
• Η σωρευτική προσαρμογή (cumulative catch-up) εφαρμόζεται στις γραμμές χρονικής κατανομής. Ο επανασχεδιασμός οροσήμων είναι μόνο προοπτικός. Οι γραμμές ποσοστού ολοκλήρωσης προσαρμόζονται μέσω αναφορών προόδου και όχι μέσω του modify.
• Σημαντικά στοιχεία χρηματοδότησης (§60–65), μη χρηματικό τίμημα και τίμημα πληρωτέο σε πελάτη είναι εκτός πεδίου εφαρμογής.
• Οι αυτόματες εκτελέσεις λήξης χρονοδιαγράμματος καταχωρούνται την ημέρα που ενεργοποιούνται. Οι καταχωρίσεις αναπλήρωσης (catch-up) σε κλειστές περιόδους απορρίπτονται - ξεκλειδώστε την περίοδο ή χρησιμοποιήστε μια ανοιχτή ημερομηνία καταχώρισης.

FAQ

• Μπορώ να συνδυάσω διαφορετικές μεθόδους αναγνώρισης στο ίδιο τιμολόγιο; Ναι. Κάθε γραμμή τιμολογίου μπορεί να χρησιμοποιεί διαφορετική μέθοδο (για παράδειγμα, μία γραμμή με point_in_time και μία άλλη με ratable), αρκεί να τηρούνται οι κανόνες κατανομής.
• Τι συμβαίνει όταν τροποποιείται ένα συμβόλαιο με μεθόδους οροσήμων; Οι τροποποιήσεις σε γραμμές οροσήμων υποστηρίζονται αποκλειστικά με την προοπτική μέθοδο (prospective), επαναπροσδιορίζοντας τα ποσοστά των εναπομειάντων οροσήμων.