Recunoașterea veniturilor (IFRS 15 / ASC 606)

Amânarea veniturilor la nivel de linie și recunoașterea eșalonată: datorii din contracte, metode bazate pe trecerea timpului, alocarea prețului tranzacției, provizioane pentru rambursări, abonamente și modificări contractuale. Calea implicită rămâne neschimbată - o linie de factură simplă recunoaște în continuare veniturile integral la emitere (la un moment în timp), ceea ce este conform cu standardele 606/15 pentru o singură obligație de performanță îndeplinită la livrare. Tot ce este prezentat mai jos este opțional (opt-in) per linie de factură.

Aplicația dispune de capacități conforme cu normele 606/15; entitatea raportoare este cea care respectă sau nu aceste standarde. Alegerea metodei corecte pentru fiecare obligație, estimarea prețurilor de vânzare independentă și a ratelor de rambursare, precum și aprecierea dacă bunurile sau serviciile rămase sunt distincte în cazul unei modificări rămân la latitudinea contabilului care face raportarea.

Conturi

Trei conturi contabile stau la baza acestor fluxuri, configurate ca chei pentru regulile de postare (care pot fi suprascrise per companie prin ledger/posting-rules/update): revenue.deferredIncome → 4910 „Ateinančių laikotarpių pajamos” (datorie din contract), revenue.refundLiability → 4450 „Grąžinimo įsipareigojimai pirkėjams”, revenue.contractAsset → 2910 „Sukauptos pajamos”. Companiile existente obțin aceste conturi prin reaplicarea șablonului de plan de conturi (ledger/accounts/apply-template).

Obligațiile de performanță pe liniile facturii

Liniile din sales/invoices/create|update acceptă parametrul recognition: { method, startDate, endDate, milestones }, unde method poate fi una dintre următoarele valori:

Metodă	Comportament la emitere	Recunoaștere
point_in_time (implicit)	Credit (CR) venituri integral	la emitere, neschimbat
ratable (startDate..endDate)	Credit (CR) venituri în avans	eșalonare lunară ponderată în funcție de numărul de zile pe perioada de prestare a serviciului
milestone (milestones[], cu procente însumând 100)	Credit (CR) venituri în avans	câte o tranșă per jalon, recunoscută la producerea evenimentului
percent_complete	Credit (CR) venituri în avans	prin rapoarte de progres cumulat

Conturile de clienți (AR) și TVA rămân neschimbate: emiterea inregistrează Debit (DR) 2410 pentru suma brută, Credit (CR) 4492 pentru TVA și divide valoarea netă între venituri (pentru liniile recunoscute la un moment în timp) și 4910 (pentru liniile eșalonate). Eșalonările sunt stocate în moneda de bază a companiei la cursul de schimb valutar de la data emiterii - sales/recognition-schedules/list (sales:read) afișează fiecare tranșă cu starea pending | recognized | cancelled (în așteptare | recunoscută | anulată).

Alocarea prețului tranzacției. Atunci când există mai mult de o linie, parametrul standaloneSellingPrice de pe fiecare linie alocă valoarea netă a facturii proporțional între obligații (IFRS 15 §76–80); suma alocată - nu prețul menționat pe linie - determină împărțirea între venituri/venituri în avans și eșalonările. TVA-ul rămâne aferent liniilor de factură așa cum a fost stabilit.

Motorul de recunoaștere

Recunoașterea înregistrează Debit (DR) 4910 / Credit (CR) venituri (contul de servicii/produse și centrul de cost de pe linia originală) ca o singură notă contabilă per rulare, înregistrată în sales/recognition/runs/list.

• POST /v1/sales/recognition/compute (sales:read) { asOfDate? } - previzualizare de tip dry-run a tranșelor eșalonate scadente.
• POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } - postează tranșele eșalonate scadente sau exact tranșele specificate prin scheduleIds (indiferent de metodă).
• POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } - pentru liniile cu procent de finalizare: raportează progresul cumulat; noua sumă netă dobândită se postează imediat, iar regresiiile sunt respinse.
• POST /v1/sales/recognition/summary (sales:read) - valoarea recunoscută până în prezent, suma rămasă, numărul de elemente în așteptare și data următoarei scadențe per linie, plus totalurile la nivel de companie.

Trei evenimente declanșează recunoașterea fără a necesita interogări periodice (polling): închiderea perioadei (ledger/periods/lock), care mai întâi recunoaște tot ceea ce este scadent până la sfârșitul perioadei, postat la data de sfârșit a perioadei; emiterea procesului-verbal de predare-primire (sales/acts/issue), care recunoaște tranșele scadente aferente jaloanelor din factura legată la data actului; și un cronometru pentru scadența eșalonărilor care se activează la data următoarei scadențe liniare și postează pentru fiecare companie la sosirea acesteia (o perioadă închisă va fi reîncercată ulterior). Jaloanele sunt bazate pe evenimente în mod intenționat - data estimată (expectedDate) a unui jalon este o informație de planificare și nu declanșează niciodată recunoașterea în mod autonom.

Contraprestație variabilă - datoria privind rambursările

Parametrul refundEstimatePercent de pe o linie creditează cota-parte corespunzătoare din valoarea netă (alocată) în contul 4450 în loc de venituri sau venituri în avans la momentul emiterii - rambursările așteptate sunt excluse din prețul tranzacției (IFRS 15 §55). Starea la nivelul fiecărei facturi se regăsește în sales/refund-liability/list (estimată, consumată, rambursări efective de la decontări observate, rămasă).

Valori efective: o factură de stornare (credit note) emisă pentru factură debitează contul 4450 până la concurența datoriei rămase, înainte de a afecta conturile de venituri. sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } revizuiește estimarea și postează diferența în contul de venituri în ambele direcții (limitat inferiors la suma consumată). Rambursările de la furnizorii de servicii de plată (PSP) asociate facturii sunt înregistrate în legătură cu datoria și generează un eveniment webhook refund_liability.actual - acestea nu se postează direct în contul 4450, deoarece diminuarea veniturilor și a TVA-ului colectat necesită factura de stornare drept document justificativ de TVA.

Abonamente - acorduri către facturi

Atribuiți unui acord un billingPeriod (monthly | quarterly | annual - lunar | trimestrial | anual), iar agreements/generate-invoice (agreements:write) va crea factura în ciornă (draft) pentru următoarea perioadă nefacturată: linii preluate din elementele acordului (sau valoarea value ca o singură linie per perioadă), fiecare cu recunoaștere eșalonată pe perioada de prestare a serviciului. Comanda agreements/billing/run { asOfDate? } parcurge toate acordurile active, generează fiecare perioadă scadentă și expiră acordurile facturate integral care au depășit data de sfârșit. Perioadele scurte finale sunt proratate în funcție de numărul de zile; parametrul autoRenew prelungește termenul cu propria sa durată și continuă facturarea. Facturile generate conțin agreementId (care poate fi filtrat în sales/invoices/list).

Modificări contractuale

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

• prospective - anulează eșalonarea în așteptare și redistribuie suma rămasă nerecunoscută pe noile condiții începând de la data modificării (bunurile sau serviciile rămase sunt distincte: IFRS 15 §20(a), §21(a)). Liniile eșalonate liniare preiau newEndDate; liniile bazate pe jaloane preiau newMilestones (procente din suma rămasă).
• cumulative_catch_up (doar pentru eșalonări liniare) - recalculează veniturile ca și cum noile condiții s-ar fi aplicat de la început și postează diferența imediat, în ambele direcții (o singură obligație parțial îndeplinită: §21(b)); restul sumei este redistribuit.

Scăderile de preț se transmit prin facturi de stornare: o factură de stornare emisă pentru o factură cu eșalonări în așteptare debitează mai întâi veniturile în avans și ajustează planul în așteptare de la capătul său îndepărtat, apoi datoria privind rambursările și abia apoi veniturile. Creșterile de preț reprezintă facturi suplimentare cu propriul lor regim de recunoaștere - fiind prospective prin însăși structura lor.

Limite

• Eșalonările și postările de recunoaștere sunt sume în moneda de bază (EUR) fixate la cursul de schimb valutar de la data emiterii; soldurile veniturilor în avans nu sunt reevaluate în funcție de cursul valutar după emitere.
• Contul pentru active din contracte (2910) este furnizat în planul de conturi și ca o cheie de postare, dar nicio înregistrare automată a veniturilor nefacturate nu este postată încă în acesta - recunoașterea în avans față de facturare se face în prezent printr-o notă contabilă manuală.
• Alocarea necesită un preț de vânzare independent pe toate liniile facturii sau pe niciuna; abordarea reziduală (§79(c)) nu este implementată.
• Datoriile privind rambursările sunt urmărite net de TVA la nivel de factură; activul corespunzător dreptului de a recupera bunurile returnate (§B25) nu este modelat.
• Metoda de corecție cumulata (cumulative catch-up) se aplică liniilor eșalonate liniare; replanificarea jaloanelor este exclusiv prospectivă; liniile cu procent de finalizare sunt ajustate prin rapoarte de progres, nu prin comanda modify.
• Componentele de finanțare semnificative (§60–65), contraprestațiile care nu constau în numerar și contraprestațiile plătite către un client nu fac obiectul prezentului document.
• Executările automate ale eșalonărilor scadente se postează în ziua în care sunt declanșate; postările de recuperare în perioade închise sunt respinse - deblocați perioada sau utilizați o dată de postare deschisă.

FAQ

Cum se tratează modificările contractuale care afectează mai multe linii?

Modificările contractuale trebuie aplicate individual pentru fiecare linie afectată prin intermediul endpoint-ului de modificare. Dacă un contract suferă modificări complexe la nivel general, se recomandă anularea sau corectarea liniilor relevante și crearea unor noi linii cu parametrii de recunoaștere actualizați.

Pot anula o recunoaștere de venituri deja postată?

Postările de recunoaștere efectuate nu pot fi anulate direct; trebuie să emiteți o notă contabilă de stornare sau o factură de stornare corespunzătoare în funcție de natura corecției contabile necesare.

Ce se întâmplă dacă o rată de rambursare estimată se dovedește a fi incorectă?

Utilizați funcția de actualizare a datoriilor privind rambursările (sales/refund-liability/true-up) pentru a ajusta estimarea la valorile reale observate. Sistemul va calcula automat diferența și o va posta în contul de venituri.