Nordlet

← Documentazione / Guide

Riconoscimento dei ricavi (IFRS 15 / ASC 606)

Ricavi differiti, rate, piani a milestone e a percentuale di completamento, passività per rimborsi, abbonamenti.

Differimento dei ricavi per riga e riconoscimento pianificato: passività contrattuali, metodi basati sul tempo, allocazione del prezzo dell'operazione, accantonamenti per rimborsi, abbonamenti e modifiche contrattuali. Il percorso predefinito rimane invariato: una normale riga di fattura riconosce comunque i ricavi per intero all'emissione (momento puntuale), il che è conforme ai principi IFRS 15 / ASC 606 per una singola obbligazione di fare soddisfatta alla consegna. Tutto quanto descritto di seguito è facoltativo e attivabile per singola riga di fattura.

Il software è capace di gestire i principi IFRS 15 e ASC 606; l'entità redigente è quella che risulta (o meno) conforme. La scelta del metodo corretto per ciascuna obbligazione, la stima dei prezzi di vendita autonomi e delle percentuali di rimborso, nonché la valutazione sul fatto che i beni o servizi residui siano distinti in caso di modifica, rimangono valutazioni contabili di competenza dell'utente.

Conti

Tre conti del piano dei conti supportano i flussi, configurati come chiavi di regola di registrazione (sovrascrivibili per azienda tramite ledger/posting-rules/update): revenue.deferredIncome → 4910 "Ateinančių laikotarpių pajamos" (passività contrattuale), revenue.refundLiability → 4450 "Grąžinimo įsipareigojimai pirkėjams", revenue.contractAsset → 2910 "Sukauptos pajamos". Le aziende esistenti ottengono i conti riapplicando il modello del piano dei conti (ledger/accounts/apply-template).

Obbligazioni di fare sulle righe di fattura

Le righe di sales/invoices/create|update accettano il parametro recognition: { method, startDate, endDate, milestones }, dove method può essere uno dei seguenti:

Metodo Comportamento all'emissione Riconoscimento
point_in_time (predefinito) Avere ricavi per l'intero importo all'emissione, invariato
ratable (startDate..endDate) Avere risconti passivi piano mensile ponderato per giorni nel corso del periodo di servizio
milestone (milestones[], percentuali che sommano a 100) Avere risconti passivi una quota per ogni milestone, riconosciuta al verificarsi dell'evento
percent_complete Avere risconti passivi tramite report di avanzamento cumulativi

Crediti commerciali e IVA rimangono inalterati: l'emissione registra Dare 2410 per il lordo, Avere 4492 per l'IVA e ripartisce l'importo netto tra i ricavi (righe a momento puntuale) e il conto 4910 (righe differite). I piani di ammortamento/riconoscimento sono memorizzati nella valuta di base dell'azienda al tasso di cambio della data di emissione; l'endpoint sales/recognition-schedules/list (sales:read) mostra ogni quota con stato pending | recognized | cancelled.

Allocazione del prezzo dell'operazione. Con più di una riga, il campo standaloneSellingPrice su ogni riga ripartisce il netto della fattura tra le obbligazioni in proporzione (IFRS 15 §§ 76–80); l'importo allocato, e non il prezzo di riga indicato, determina la ripartizione tra ricavi e risconti e i relativi piani. L'IVA rimane associata alle righe di fattura come originariamente indicato.

Motore di riconoscimento

Il riconoscimento registra Dare 4910 / Avere ricavi (conto di servizio/prodotto e centro di costo della riga originaria) come un'unica registrazione prima nota per ogni elaborazione, registrata in sales/recognition/runs/list.

  • POST /v1/sales/recognition/compute (sales:read) { asOfDate? } - anteprima di simulazione (dry-run) delle quote di rate in scadenza.
  • POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } - registra le quote di rate in scadenza o esattamente le quote specificate da scheduleIds (per qualsiasi metodo).
  • POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } - per le righe a percentuale di completamento: riporta l'avanzamento cumulativo; il nuovo delta maturato viene registrato immediatamente, mentre eventuali regressioni vengono rifiutate.
  • POST /v1/sales/recognition/summary (sales:read) - importo riconosciuto alla data, residuo, conteggio delle quote in sospeso e prossima data di scadenza per riga, oltre ai totali aziendali.

Tre eventi guidano il riconoscimento senza necessità di polling: la chiusura del periodo (ledger/periods/lock), che per prima cosa riconosce tutto quanto dovuto fino alla fine del periodo, registrato alla data di chiusura del periodo; l'emissione del verbale di consegna (sales/acts/issue), che riconosce le quote di milestone in sospeso della fattura collegata alla data del verbale; e un timer di scadenza del piano, che si attiva alla successiva data di scadenza della rata ed esegue la registrazione per azienda al suo arrivo (un periodo chiuso ripeterà il tentativo in seguito). Le milestone sono basate su eventi per scelta progettuale: la data prevista (expectedDate) di una milestone è un'informazione di pianificazione e non attiva mai autonomamente il riconoscimento.

Corrispettivo variabile - passività per rimborsi

Il parametro refundEstimatePercent su una riga accredita tale quota del netto (allocato) al conto 4450 anziché a ricavi o ricavi differiti al momento dell'emissione; i rimborsi attesi sono esclusi dal prezzo dell'operazione (IFRS 15 § 55). Lo stato per singola fattura risiede in sales/refund-liability/list (stimato, utilizzato, rimborsi di transazione effettivi osservati, residuo).

Dati effettivi: una nota di credito a storno della fattura addebita il conto 4450 fino a concorrenza della passività residua prima di toccare i ricavi. L'endpoint sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } rivede la stima e registra il delta a valere sui ricavi in entrambe le direzioni (con un limite inferiore pari all'importo consumato). I rimborsi di transazione dei PSP abbinati alla fattura vengono registrati sulla passività ed emettono un webhook refund_liability.actual: essi non registrano movimenti direttamente sul conto 4450, poiché lo storno dei ricavi e dell'IVA a debito richiede la nota di credito quale documento IVA valido.

Abbonamenti - da accordi a fatture

Assegnando a un accordo un periodo di fatturazione (billingPeriod: monthly | quarterly | annual), l'endpoint agreements/generate-invoice (agreements:write) crea la fattura bozza per il successivo periodo non ancora fatturato: le righe derivano dagli articoli dell'accordo (o dal value come singola riga per periodo), ciascuna con riconoscimento rateale lungo il periodo di servizio. L'endpoint agreements/billing/run { asOfDate? } elabora tutti gli accordi attivi, genera ogni periodo in scadenza e fa scadere gli accordi completamente fatturati oltre la loro data di fine. I periodi brevi finali sono riproporzionati per giorni; il parametro autoRenew estende la durata per la sua stessa lunghezza e continua la fatturazione. Le fatture generate riportano l'attributo agreementId (filtrabile in sales/invoices/list).

Modifiche contrattuali

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

  • prospective - annulla il piano in sospeso e ridistribuisce la parte rimanente non riconosciuta sui nuovi termini a partire dalla data di modifica (beni o servizi residui distinti: IFRS 15 § 20(a), § 21(a)). Le righe rateali richiedono newEndDate; le righe a milestone richiedono newMilestones (percentuali dell'importo residuo).
  • cumulative_catch_up (solo per righe rateali) - ricalcola i ricavi come se i nuovi termini fossero stati applicati sin dall'inizio e registra immediatamente la differenza, in entrambe le direzioni (singola obbligazione parzialmente soddisfatta: § 21(b)); la parte rimanente viene ridistribuita.

Le riduzioni di prezzo transitano attraverso le note di credito: una nota di credito emessa contro una fattura con piani in sospeso addebita dapprima i ricavi differiti e riduce il piano in sospeso partendo dalla sua scadenza più lontana, poi la passività per rimborsi e solo infine i ricavi. Gli aumenti di prezzo costituiscono fatture aggiuntive dotate di un proprio riconoscimento, prospettico per costruzione.

Limiti

  • I piani di ammortamento e le registrazioni di riconoscimento sono espressi in importi nella valuta di base (EUR) fissati al tasso di cambio della data di emissione; i saldi differiti non vengono rivalutati ai tassi di cambio dopo l'emissione.
  • Il conto attività contrattuali (2910) è fornito nel piano dei conti e come chiave di registrazione, ma al momento nessun flusso automatizzato di ricavi non ancora fatturati vi registra movimenti: il riconoscimento antecedente alla fatturazione richiede una prima nota manuale.
  • L'allocazione richiede un prezzo di vendita autonomo su tutte le righe della fattura o su nessuna; l'approccio residuale (§ 79(c)) non è implementato.
  • Le passività per rimborsi sono tracciate al netto dell'IVA a livello di fattura; la corrispondente attività per il diritto a recuperare i beni restituiti (§ B25) non è modellata.
  • Il recupero cumulativo (cumulative catch-up) si applica alle righe rateali; la ripianificazione delle milestone è esclusivamente prospettica; le righe a percentuale di completamento vengono adeguate tramite i report di avanzamento e non tramite modify.
  • Le componenti finanziarie significative (§§ 60–65), i corrispettivi non monetari e i corrispettivi dovuti ai clienti sono esclusi dall'ambito di applicazione.
  • Le esecuzioni automatiche dei piani in scadenza vengono registrate nel giorno in cui si attivano; le registrazioni di conguaglio in periodi chiusi vengono rifiutate: sbloccare il periodo o utilizzare una data di registrazione aperta.

FAQ

Q: Come gestisco una fattura con righe sia a momento puntuale che differite? A: Utilizza recognition: { method: 'ratable', startDate, endDate } solo sulle righe che richiedono il differimento. Le righe senza il blocco recognition utilizzeranno in automatico il comportamento predefinito a momento puntuale (point_in_time).

Q: Posso annullare o modificare un piano di riconoscimento già elaborato? A: Non è possibile modificare direttamente le registrazioni contabili generate. Per correggere la pianificazione, utilizzare gli strumenti di modifica contrattuale come POST /v1/sales/recognition/modify o emettere una nota di credito.