Rozpoznawanie przychodów (MSSF 15 / ASC 606)

Odroczenie przychodów w ujęciu per pozycja oraz planowe ich rozpoznawanie: zobowiązania z tytułu umów, metody rozliczania w czasie, alokacja ceny transakcyjnej, rezerwy na zwroty, subskrypcje oraz modyfikacje umów. Domyślna ścieżka pozostaje bez zmian - standardowa pozycja faktury nadal ujmuje przychód w pełnej kwocie w momencie wystawienia (w określonym punkcie w czasie), co jest zgodne ze standardami ASC 606 / MSSF 15 w przypadku pojedynczego zobowiązania do wykonania świadczenia spełnionego w momencie dostawy. Wszystkie poniższe opcje są włączane fakultatywnie dla każdej pozycji faktury osobno.

Oprogramowanie jest dostosowane do wymogów standardów MSSF 15 / ASC 606; to podmiot sporządzający sprawozdanie ponosi odpowiedzialność za zgodność (lub jej brak) z przepisami. Wybór odpowiedniej metody dla danego zobowiązania, szacowanie indywidualnych cen sprzedaży i wskaźników zwrotów oraz ocena, czy pozostałe towary lub usługi mają charakter odrębny w przypadku modyfikacji, pozostają w gestii oceny księgowej jednostki sporządzającej sprawozdanie.

Konta

Przepływy księgowe opierają się na trzech kontach, powiązanych za pomocą kluczy reguł księgowania (z możliwością nadpisania dla każdej spółki poprzez ledger/posting-rules/update): revenue.deferredIncome → 4910 „Ateinančių laikotarpių pajamos” (zobowiązanie z tytułu umowy), revenue.refundLiability → 4450 „Grąžinimo įsipareigojimai pirkėjams”, revenue.contractAsset → 2910 „Sukauptos pajamos”. Dotychczasowe spółki uzyskują dostęp do tych kont poprzez ponowne zastosowanie szablonu planu kont (ledger/accounts/apply-template).

Zobowiązania do wykonania świadczenia na pozycjach faktury

Pozycje w sales/invoices/create|update akceptują parametr recognition: { method, startDate, endDate, milestones }, gdzie method przyjmuje jedną z następujących wartości:

Metoda	Zachowanie w momencie wystawienia	Rozpoznawanie
point_in_time (domyślnie)	Ma w pełni przychód (CR)	w momencie wystawienia, bez zmian
ratable (startDate..endDate)	Ma przychody przyszłych okresów (CR)	harmonogram miesięczny ważony dniami w okresie świadczenia usługi
milestone (milestones[], sumujące się do 100%)	Ma przychody przyszłych okresów (CR)	jedna transa na kamień milowy, rozpoznawana w momencie wystąpienia zdarzenia
percent_complete	Ma przychody przyszłych okresów (CR)	za pomocą kumulatywnych raportów postępu

Rozrachunki z odbiorcami (AR) oraz podatek VAT pozostają nienaruszone: wystawienie faktury księguje kwotę brutto w Wn 2410, podatek VAT w Ma 4492 oraz dzieli kwotę netto pomiędzy przychód (pozycje rozpoznavane w punkcie w czasie) a konto 4910 (pozycje odroczone). Harmonogramy są przechowywane w walucie bazowej spółki według kursu wymiany z dnia wystawienia - sales/recognition-schedules/list (sales:read) prezentuje każdą transę ze statusem pending | recognized | cancelled.

Alokacja ceny transakcyjnej. W przypadku występowania więcej niż jednej pozycji, parametr standaloneSellingPrice na każdej pozycji rozdziela kwotę netto faktury proporcjonalnie na poszczególne zobowiązania (MSSF 15 §76–80); to alokowana kwota, a nie cena pozycji wynikająca z dokumentu, decyduje o podziale na przychód/przychody przyszłych okresów oraz o harmonogramach. Podatek VAT pozostaje przypisany do pozycji faktury w zadeklarowanej wysokości.

Silnik rozpoznawania przychodów

Rozpoznawanie przychodów księguje kwotę Wn 4910 / Ma przychód (konto usługi/produktu oraz miejsce powstawania kosztów z pozycji pierwotnej) jako pojedynczy zapis księgowy w ramach jednego przebiegu, rejestrowany w sales/recognition/runs/list.

• POST /v1/sales/recognition/compute (sales:read) { asOfDate? } - podgląd symulacyjny należnych trans liniowych (dry-run).
• POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } - zaksięgowanie należnych trans liniowych lub dokładnie tych trans, które wskazano w scheduleIds (dowolna metoda).
• POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } - pozycje rozliczane metodą stopnia zaawansowania: raportowanie postępu kumulatywnego; nowo wypracowana delta jest księgowana natychmiast, a regresje są odrzucane.
• POST /v1/sales/recognition/summary (sales:read) - kwota rozpoznana narastająco, kwota pozostała, liczba pozycji oczekujących oraz data kolejnej płatności w przeliczeniu na pozycję, a także sumy dla spółki.

Za wyzwalanie rozpoznawania bez konieczności odpytywania systemu (polling) odpowiadają trzy zdarzenia: zamknięcie okresu (ledger/periods/lock), które najpierw rozpoznaje wszystko, co jest należne do końca okresu, z datą księgowania przypadającą na ostatni dzień okresu; wystawienie protokołu odbioru (sales/acts/issue), które rozpoznaje powiązane z fakturą oczekujące transy kamieni milowych z datą protokołu; oraz licznik czasu wymagalności harmonogramu, który ustawia się na kolejny termin płatności i dokonuje księgowania dla spółki w wyznaczonym dniu (zamknięty okres powoduje ponowną próbę w późniejszym terminie). Kamienie milowe są z założenia powiązane ze zdarzeniami - pole expectedDate kamienia milowego ma charakter informacyjny/planistyczne i samo w sobie nigdy nie inicjuje rozpoznania przychodu.

Świadczenia zmienne - rezerwa na zwroty

Parametr refundEstimatePercent na pozycji pozwala zaksięgować ten udział (zależny od alokowanej kwoty netto) na konto 4450 zamiast w przychody lub przychody przyszłych okresów w momencie wystawienia - oczekiwane zwroty są wyłączane z ceny transakcyjnej (MSSF 15 §55). Stan dla poszczególnych faktur znajduje się w sales/refund-liability/list (szacunkowy, wykorzystany, zaobserwowane zwroty rozliczone, pozostały).

Rzeczywiste zdarzenia: faktura korygująca do faktury obciąża konto 4450 do wysokości pozostałej rezerwy przed ruszeniem przychodów. Funkcja sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } weryfikuje szacunek i księguje deltę w kierunku przychodów w dowolną stronę (z ograniczeniem do kwoty wykorzystanej). Zwroty rozliczone przez operatora płatności (PSP) dopasowane do faktury są rejestrowane na rezerwie i generują webhook refund_liability.actual - nie obciążają one bezpośrednio konta 4450, ponieważ pomniejszenie przychodów i podatku VAT należnego wymaga faktury korygującej jako dokumentu źródłowego dla VAT.

Subskrypcje - umowy a faktury

Przypisanie umowie parametru billingPeriod (monthly | quarterly | annual) oraz wywołanie agreements/generate-invoice (agreements:write) tworzy projekt faktury dla kolejnego niezafakturowanego okresu: pozycje wynikają z elementów umowy (lub wartości value jako jednej pozycji na okres), przy czym każda z nich podlega liniowemu rozpoznawaniu w okresie świadczenia usługi. Funkcja agreements/billing/run { asOfDate? } przeszukuje wszystkie aktywne umowy, generuje dokumenty dla każdego wymagalnego okresu oraz wygasza umowy w pełni zafakturowane po upływie ich daty końcowej. Ostatnie krótkie okresy są rozliczane proporcjonalnie do liczby dni; parametr autoRenew przedłuża czas trwania umowy o jej pierwotną długość i kontynuuje fakturowanie. Generowane faktury zawierają pole agreementId (z możliwością filtrowania w sales/invoices/list).

Modyfikacje umów

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

• prospective - anulowanie oczekującego harmonogramu i ponowne rozłożenie nierozpoznanej reszty na nowych warunkach od daty modyfikacji (pozostałe towary lub usługi mają charakter odrębny: MSSF 15 §20(a), §21(a)). Pozycje rozliczane liniowo przyjmują newEndDate; pozycje oparte na kamieniach milowych przyjmują newMilestones (jako procenty pozostałej kwoty).
• cumulative_catch_up (tylko dla pozycji liniowych) - ponowne przeliczenie przychodów tak, jakby nowe warunki obowiązywały od samego początku, oraz natychmiastowe ujęcie różnicy w dowolnym kierunku (pojedyncze zobowiązanie spełnione częściowo: §21(b)); pozostała kwota zostaje rozłożona na nowo.

Obniżki cen są obsługiwane za pomocą faktur korygujących: faktura korygująca do faktury z oczekującymi harmonogramami obciąża najpierw przychody przyszłych okresów, skracając plan oczekujący od jego końca, następnie rezerwę na zwroty, a dopiero w ostatniej kolejności przychody. Podwyżki cen stanowią dodatkowe faktury z własnymi regułami rozpoznawania - z założenia o charakterze proспекtywnym (prospektywnym).

Limity

• Harmonogramy i zapisy z tytułu rozpoznawania przychodów bazują na kwotach w walucie bazowej (EUR) ustalonych według kursu walutowego z dnia wystawienia; salda przychodów przyszłych okresów nie są przeliczane po wystawieniu dokumentu z tytułu różnic kursowych.
• Konto aktywów z tytułu umów (2910) znajduje się w planie kont oraz jako klucz księgowania, jednak automatyczny przepływ dla niezafakturowanych przychodów nie jest jeszcze obsługiwany - rozpoznawanie przychodów przed wystawieniem faktury wymaga obecnie ręcznego zapisu księgowego.
• Alokacja wymaga podania indywidualnej ceny sprzedaży na wszystkich pozycjach faktury albo na żadnej; metoda rezydualna (§79(c)) nie została zaimplementowana.
• Rezerwy na zwroty są monitorowane w kwocie netto (bez VAT) na poziomie faktury; odpowiedni składnik aktywów z tytułu prawa do odzyskania zwróconych towarów (§B25) nie jest modelowany.
• Podejście skumulowanego wyrównania (cumulative catch-up) ma zastosowanie do pozycji liniowych; ponowne planowanie kamieni milowych ma charakter wyłącznie prospektywny; pozycje rozliczane metodą stopnia zaawansowania są korygowane za pomocą raportów postępu, a nie funkcji modify.
• Znaczące elementy finansujące (§60–65), świadczenia inne niż pieniężne oraz świadczenia należne klientowi wykraczają poza zakres zastosowania.
• Automatyczne uruchomienia wymagalnych harmonogramów księgują w dniu ich wystąpienia; wpisy korygujące trafiające do zamkniętych okresów są odrzucane - należy odblokować okres lub użyć otwartej daty księgowania.