Flowchart IFRS 15: Settore Tecnologico | ciferi

Applicare il modello IFRS 15 al settore tecnologico richiede un'attenzione particolare ai contratti complessi, alle licenze software, agli accordi di...

Navigare il modello di riconoscimento dei ricavi in cinque fasi per le entità tecnologiche italiane

Applicare il modello IFRS 15 al settore tecnologico richiede un'attenzione particolare ai contratti complessi, alle licenze software, agli accordi di assistenza continuativa e ai bundling. Questo flowchart localizza il modello IFRS 15 secondo le aspettative della CONSOB per entità tecnologiche quotate su Borsa Italiana e introduce le considerazioni operative che i revisori incontrano negli incarichi italiani.
---

Il modello in cinque fasi

L'IFRS 15 richiede di applicare una sequenza coerente di valutazioni per ogni contratto con un cliente:
Ogni fase è deterministica. Se una domanda riceve risposta negativa, il percorso cambia in modo specifico. Usare questo flowchart nella pianificazione dell'incarico e durante la revisione del bilancio per tracciare il ragionamento contabile del cliente.
---

Identificare il contratto con un cliente
Identificare le obbligazioni di prestazione distinte
Determinare il prezzo della transazione
Allocare il prezzo della transazione alle obbligazioni di prestazione
Riconoscere i ricavi quando (o mentre) si soddisfa ogni obbligazione di prestazione

Fase 1: Identificare il contratto

Un contratto esiste quando cinque condizioni sono soddisfatte contemporaneamente (IFRS 15.9). Se manca anche una sola condizione, non c'è contratto e il ricavo non viene riconosciuto finché tutte e cinque non sono soddisfatte.

Il contratto esiste?

Le parti hanno approvato il contratto ed entrambe intendono adempiere ai propri obblighi?
Approvazione può essere scritta (ordine di acquisto, accordo formale), orale (registrata o confermata per iscritto successivamente), o implicita dalla pratica commerciale consolidata. Per contratti tecnologici italiani, è raro avere solo approvazione orale; di solito esiste almeno una conferma d'ordine tramite email o un accordo quadro sottoscritto.
Documentazione richiesta: Copia dell'ordine, email di conferma, accordo quadro sottoscritto, o memo che descrive la pratica commerciale consolidata con questo cliente.
---
Si possono identificare i diritti di ciascuna parte rispetto ai beni o servizi da trasferire?
I diritti devono essere eseguibili e specifici. Nel settore tecnologico italiano, questo significa che il contratto deve distinguere chiaramente tra:
Per software as a service (SaaS), il contratto deve specificare il periodo di accesso, il numero di utenti, i livelli di servizio (uptime garantito), e la capacità computazionale fornita.
Documentazione richiesta: Scope del contratto, allegati tecnici, dichiarazioni funzionali, livelli di servizio (SLA).
---
Si possono identificare i termini di pagamento?
I termini di pagamento includono l'importo totale atteso, le scadenze, le modalità (bonifico, assegno, lettera di credito), e qualsiasi elemento variabile (sconti per pagamento anticipato, rabatti per volume, bonus di performance).
Nel contesto italiano, è comune trovare:
Se i termini sono impliciti (ad esempio il cliente ha sempre pagato in 30 giorni), il revisore documenta questa pratica consolidata.
Documentazione richiesta: Foglio condizioni contrattuali, cronogramma dei pagamenti, email che conferma i termini.
---
Il contratto ha carattere commerciale? I flussi di cassa futuri dell'entità si modificheranno a causa di questo contratto?
Un contratto ha carattere commerciale quando cambia il profilo di rischio, tempistica o importo dei flussi di cassa. La maggior parte dei contratti commerciali italiani lo ha. L'eccezione è rara: ad esempio, uno scambio di software identico tra due sviluppatori per soddisfare mercati geografici diversi potrebbe non avere carattere commerciale, ma ciò è teorico.
Documentazione richiesta: Breve analisi che spiega come il contratto cambia i flussi di cassa futuri dell'entità (nuova fonte di ricavo, riduzione dei costi operativi, accesso a nuovi mercati, etc.).
---
È probabile che l'entità riscuota il corrispettivo a cui ha diritto?
Valutare la solvibilità del cliente. Considerare:
Per i SaaS, è comune richiedere un pagamento iniziale (prepaid) per il primo trimestre o semestre; ciò mitiga il rischio di insolvenza.
Se il cliente chiede una riduzione di prezzo prima di firmare il contratto, il revisore documenta il prezzo atteso al netto dello sconto e la base della stima dello sconto (storico, pratica di mercato, circostanze specifiche del cliente).
Documentazione richiesta: Valutazione del credito del cliente, cronologia dei pagamenti precedenti, comunicazioni sulla capacità di pagamento, qualsiasi sconto accordato con relativa motivazione.
---

Combinazione di contratti

Se con lo stesso cliente coesistono più contratti, valutare se vanno combinati (IFRS 15.17).
I contratti sono stati negoziati come un pacchetto unico con un obiettivo commerciale condiviso?
Esempio: L'entità vende una licenza software di base per EUR 50.000, una suite di moduli aggiuntivi per EUR 30.000, e una consulenza di implementazione per EUR 20.000. Se negoziati contemporaneamente come soluzione integrata con uno sconto globale di EUR 20.000, sono un pacchetto. Se negoziati separatamente in momenti diversi, no.
Documentazione richiesta: Email di negoziazione, ordine cliente, bozze di contratto, memo di vendita che mostra il ragionamento commerciale.
---
Il corrispettivo in un contratto dipende dal prezzo o dalla performance dell'altro contratto?
Esempio: Lo sconto sulla licenza è condizionato al fatto che il cliente accetti anche la consulenza di implementazione entro una certa data. Questo indica combinazione.
Contro-esempio: Sconti per volume annuale applicati ai contratti di manutenzione (non legati a contratti specifici di sviluppo). Questi sono indipendenti.
Documentazione richiesta: Testo integrale dei contratti o email che illustra la condizionalità.
---
I beni o servizi promessi nei contratti costituiscono un'unica obbligazione di prestazione?
Valutare se gli elementi sono integrati. Esempio: Un progetto di sviluppo software personalizzato + training del team cliente + manutenzione post-lancio potrebbero costituire un'unica soluzione integrata se il risultato funzionale finale è un sistema coeso che il cliente non potrebbe utilizzare senza tutti i componenti.
Documentazione richiesta: Scope tecnico, diagramma di flusso del progetto, dichiarazione di chi fa cosa e quando.
---

Modifiche contrattuali

Se il contratto viene modificato dopo la firma (cambio di scope, aggiunta di funzionalità, estensione della durata), valutare come contabilizzare la modifica (IFRS 15.18–21).
La modifica aggiunge beni o servizi distinti?
Esempio 1: Il cliente aggiunge tre moduli software non inclusi nel contratto originale. Sì, sono distinti. Verifica la fase successiva.
Esempio 2: Il cliente chiede di estendere il supporto da 3 a 5 anni. Ancora parte della stessa obbligazione di prestazione (servizi di supporto continuativo), non distinto.
Documentazione richiesta: Numero di variante del contratto, change request, email che descrive la modifica.
---
Il prezzo aumenta di un importo che riflette il prezzo di vendita autonomo dei beni o servizi aggiunti (rettificato per le circostanze del contratto)?
Se la modifica aggiunge tre moduli per EUR 20.000 totali e il prezzo di vendita autonomo di quei tre moduli è EUR 22.000, l'aumento è commensurato (il cliente riceve uno sconto minore rispetto a un nuovo cliente, ma è commensurato alla circostanza del contratto esistente).
Se il prezzo aumenta di EUR 5.000 per aggiungere tre moduli il cui prezzo autonomo è EUR 20.000, l'aumento NON è commensurato. La modifica non viene contabilizzata come contratto separato; invece, si applica la regola del catch-up cumulativo (vedere sotto).
Documentazione richiesta: Confronto tra prezzo della modifica, prezzo autonomo dei beni/servizi aggiunti, e rettifiche per circostanze.
---
I beni o servizi rimasti nel contratto modificato sono distinti da quelli già trasferiti?
Se sì: La modifica crea un nuovo contratto. Si contabilizza il ricavo non ancora riconosciuto dal contratto originale come se fosse scaduto, e il nuovo contratto (con la modifica) parte da zero a partire dalla data della modifica. Ciò è raro nel settore tecnologico; accade quando il cliente aggiunge una nuova linea di business completamente separata.
Se no: Si applica il cumulative catch-up adjustment (IFRS 15.21(b)). L'aumento di prezzo dalla modifica viene aggiunto al prezzo originale, e si rivede il ricavo da riconoscere per l'intera obbligazione di prestazione (non ancora conclusa) utilizzando il nuovo prezzo totale. Una quota dell'aumento di prezzo è allocata ai periodo già decorsi (e riconosciuta retroattivamente nel periodo della modifica) e il resto ai periodi futuri.
Documentazione richiesta: Analisi di come il restante scope tecnico si integra con il lavoro già svolto.
---

Quale software (o quale versione) viene concesso in licenza
Se il cliente ha diritto a manutenzione, aggiornamenti, assistenza tecnica
Se il contratto include consulenza di implementazione, training, o integrazione con sistemi esistenti
Quali diritti di proprietà intellettuale rimangono all'entità
Pagamenti in più rate (spesso 30-50-20 in funzione dei milestone di implementazione)
Clausole di sospensione del pagamento se la conformità funzionale non è raggiunta
Sconti per pagamento anticipato (ad esempio 2% se pagato entro 15 giorni)
Rabatti vincolati al raggiungimento di volumi annuali
Se è la prima transazione con questo cliente: verificare il rating creditizio, il rapporto bancario, i bilanci recenti
Se è cliente consolidato: verificare la cronologia dei pagamenti in tempo
Se il cliente è una pubblica amministrazione italiana: di solito affidabile ma i pagamenti possono essere lenti (60-90 giorni); non scartare il contratto per questo
Se il cliente è un'impresa in difficoltà notoria: valutare se il prezzo dovrebbe essere ridotto (sconti per rischio di credito)

Fase 2: Identificare le obbligazioni di prestazione

Un'obbligazione di prestazione è una promessa di trasferire un bene o servizio che è distinto (IFRS 15.22–30). Se il contratto contiene più promesse distinte, il revisore ne identifica il numero. Questo influenza direttamente il riconoscimento dei ricavi: obbligazioni diverse possono essere soddisfatte in periodi diversi usando metodi di misurazione del progresso diversi.
Nel settore tecnologico, le obbligazioni di prestazione comuni sono:
Ciascuna va valutata per distintezza.

Distinctness: Test della capacità di beneficio

Il bene o servizio è capace di essere distinto? Il cliente può beneficiarne da solo o con risorse prontamente disponibili?
Licenza software tradizionale: Sì, è capacibile di essere distinta. Il cliente può usare il software in modo indipendente (o con infrastruttura IT standard) senza la consulenza di implementazione.
Software su misura altamente personalizzato: Potrebbe non essere capacibile di essere distinto se è stato completamente customizzato per il cliente e senza il servizio di integrazione il cliente non potrebbe usarlo (perché non dispone degli esperti per completare l'integrazione e il software senza integrazione ha zero utilità).
Supporto tecnico standalone: È capace di essere distinto se il cliente può sottoscriverlo indipendentemente per un software già in uso. È meno capacibile di essere distinto se è incluso come parte di un contratto globale e il cliente non potrebbe separarlo (ad esempio supporto 24/7 per un sistema critico in cui il supporto è tecnico e integrato nella soluzione).
SaaS (Software as a Service): Il diritto di accesso è capacibile di essere distinto se il cliente può beneficiarne in modo indipendente. Un servizio di data analytics SaaS può essere usato indipendentemente una volta implementato.
Consulenza di integrazione: Potrebbe non essere capacibile di essere distinto se produce un asset (il sistema integrato) che il cliente non potrebbe ottenere da nessun altro (o con altre risorse prontamente disponibili) e che il cliente non potrebbe usare senza la consulenza stessa.
Documentazione richiesta: Per ogni potenziale obbligazione di prestazione, spiegare: (a) il cliente può beneficiarne in modo indipendente, o (b) il cliente potrebbe ottenerlo da terzi, o (c) il cliente ha risorse disponibili (competenze interne) per usarlo senza la consulenza di altri elementi del contratto. Se nessuna di queste è vera, non è capacibile di essere distinto.
---

Distinctness: Test dell'identificabilità separata

La promessa è separatamente identificabile dal resto delle promesse contrattuali?
Anche se un bene o servizio è capace di essere distinto, potrebbe non essere separatamente identificabile se:
Nel settore tecnologico italiano, il caso più comune è il terzo: un grande progetto di trasformazione digitale in cui il software, l'integrazione, il training, l'infrastruttura, e il supporto sono tutti interconnessi e il cliente sta acquistando un sistema funzionale coeso, non moduli intercambiabili.
Indicatore operativo: Chiedere al cliente: "Potresti usare il software senza la consulenza di implementazione? E il training senza il software?" Se la risposta è "no, non ha senso", allora non sono separatamente identificabili.
Documentazione richiesta: Analisi del grado di integrazione e interdipendenza tra i componenti. Descrizione di come il cliente usa il software post-implementazione (sistema integrato vs. moduli indipendenti).
---

La clausola della serie

Se il contratto promette una serie di beni o servizi identici (ad esempio, 12 mesi di supporto mensile, oppure un processo di consegna ripetuto), può essere opportuno aggregarli in un'unica obbligazione di prestazione.
I beni/servizi nella serie sono sostanzialmente identici e seguono lo stesso modello di trasferimento?
Nel supporto mensile: Ogni mese è sostanzialmente identico (le stesse ore di supporto, lo stesso team). Seguono lo stesso modello di trasferimento (tutti over-time, tutti al mese successivo). Pertanto, i 12 mesi possono essere una singola obbligazione di prestazione di supporto continuativo, non 12 obbligazioni separate.
Nel contratto SaaS: L'accesso al servizio ogni mese è sostanzialmente identico e segue lo stesso modello (over-time, ogni mese). Possono essere una singola obbligazione di prestazione di accesso continuativo.
Nel contratto a consegne ripetute (ad esempio consegne mensili di dati elaborati): Se ogni consegna contiene dati elaborati con la stessa metodologia e il cliente le riceve simultaneamente e le consuma contemporaneamente, sono una serie. Se la consegna 1 avviene a gennaio, la 2 a febbraio, etc., e il cliente le usa in momenti diversi, non sono un'unica serie.
Documentazione richiesta: Descrizione della natura ripetuta del bene/servizio e confermazione che il modello di riconoscimento è lo stesso per ogni elemento della serie.
---

Licenza software (o diritto di accesso a SaaS)
Implementazione / consulenza di integrazione
Servizi di training
Supporto / manutenzione continuativa
Hosting / infrastruttura IT
L'entità fornisce un servizio significativo di integrazione che combina il bene/servizio con altri elementi in un output unico. Esempio: La consulenza non solo implementa il software, ma lo customizza profondamente intertwining il software con i processi e i dati del cliente in modo tale che il software senza questa integrazione non ha valore commerciale reale per il cliente.
Il bene/servizio modifica o personalizza significativamente un altro bene/servizio promesso. Esempio: Il servizio di customizzazione è così esteso che il software senza di esso non è utilizzabile. Il software non è più un prodotto generico; è diventato parte di una soluzione integrata.
Il bene/servizio è altamente interdipendente o correlato con altri elementi del contratto, cioè ogni elemento è significativamente influenzato dagli altri e il revisore non potrebbe valutare nessun elemento indipendentemente dagli altri.

Fase 3: Determinare il prezzo della transazione

Il prezzo della transazione è l'importo di corrispettivo che l'entità si aspetta di ricevere in cambio dei beni o servizi promessi (IFRS 15.47).
Questo importo include:

Corrispettivo variabile

Il contratto contiene elementi di corrispettivo variabile?
Nel settore tecnologico, il corrispettivo variabile è frequente:
Documentazione richiesta: Elenco completo di tutti gli elementi variabili, con le condizioni di attivazione e il metodo di stima.
---

Stima del corrispettivo variabile

Quale metodo di stima predice meglio l'importo che l'entità si aspetta di ricevere?
Esistono due metodi (IFRS 15.53):
Metodo del valore atteso: Media ponderata per probabilità di tutti gli esiti possibili.
Esempio: Contratto SaaS con rabattio per volume annuale.
Valore atteso = (100.000 × 0,40) + (120.000 × 0,50) + (140.000 × 0,10) = 40.000 + 60.000 + 14.000 = EUR 114.000.
Metodo dell'importo più probabile: L'esito più probabile sulla base della distribuzione di probabilità.
Nello stesso esempio, l'esito più probabile è 15 moduli (50% di probabilità), quindi EUR 120.000.
Il revisore sceglie il metodo che meglio predice. In genere:
Documentazione richiesta: Metodo scelto, calcoli di supporto, base della stima di probabilità (storico del cliente, pratica di mercato, giudizio commerciale).
---

Vincolo del corrispettivo variabile

Anche dopo aver stimato il corrispettivo variabile, il revisore deve verificare che sia probabile che il ricavo non debba essere significativamente ridotto successivamente (IFRS 15.56–58).
L'importo stimato di corrispettivo variabile è probabile che non debba essere significativamente ridotto a causa del verificarsi o meno di un evento futuro incerto?
Esempio 1: Bonus di performance basato su uptime. L'entità ha una cronologia di 99.2% di uptime per tre anni; è probabile che continuerà. Il bonus stimato di EUR 5.000 non è probabile che debba essere ridotto significativamente. Ricavi: EUR 100.000 + EUR 5.000 di bonus stimato.
Esempio 2: Diritto di restituzione di 30 giorni. Basandosi sulla cronologia, il 5% dei clienti restituisce entro 30 giorni. Il revisore vincola il ricavo al 95% del prezzo (invece di 100%). Se il diritto fosse inaspettatamente esercitato dal 30% dei clienti e l'entità dovesse ridurre il ricavo retroattivamente, quella sarebbe una "significativa" riduzione; il revisore vincolerebbe il ricavo al 70%.
Nel settore tecnologico, i vincoli comuni sono:
Documentazione richiesta: Per ogni elemento di corrispettivo variabile, spiegare se è probabile che il ricavo non debba essere ridotto significativamente e quale percentuale o importo è vincolato.
---

Finanza Significativa

Se il contratto include termini di pagamento significativamente diversi da denaro contante immediato (es. pagamento tra 12 mesi, o pagamento anticipato 6 mesi prima della consegna), il revisore valuta se c'è una componente di finanziamento significativa (IFRS 15.60–65).
Esiste una differenza rilevante tra il prezzo dichiarato e il prezzo che il cliente avrebbe pagato in denaro contante oggi?
Esempio 1: Licenza software per EUR 100.000. Pagamento in tre rate: EUR 50.000 al momento della firma, EUR 30.000 a sei mesi, EUR 20.000 a 12 mesi. Se l'entità avrebbe accettato un pagamento cash di EUR 90.000 oggi (sconto di EUR 10.000 per cash in forma), allora c'è finanziamento implicito: EUR 10.000 di interesse implicito.
Esempio 2: Supporto annuale per EUR 50.000. Pagamento anticipato (oggi) per un servizio che sarà prestato nei prossimi 12 mesi. L'entità dovrebbe valutare se c'è finanziamento significativo (il cliente sta finanziando l'entità con il pagamento anticipato).
Nel settore tecnologico italiano, il finanziamento implicito è raro per contratti di breve durata (6-12 mesi). È più comune per:
Se la differenza di finanziamento non è rilevante (ad esempio, EUR 500 su un contratto di EUR 100.000, che è 0,5%), il revisore può non registrarla. L'IFRS 15.63 consente di non registrare il finanziamento se l'effetto è immateriale.
Documentazione richiesta: Se c'è finanziamento significativo, calcolare il tasso di interesse implicito e registrare gli interessi passivi o attivi nel prospetto conto economico mentre il tempo passa.
---

Corrispettivo Non-Cash

Se il cliente paga parzialmente con beni o servizi (invece che denaro), il revisore valuta il fair value del corrispettivo non-cash (IFRS 15.66–68).
Esempio: Un'entità software vende una licenza per EUR 100.000. Il cliente acconsente a pagare EUR 60.000 in denaro contante e a fornire 500 ore di lavoro di integrazione all'entità (perché ha specialisti in eccesso per questo tipo di lavoro). Se le 500 ore normalmente si vendono a EUR 80 per ora, il valore del corrispettivo non-cash è EUR 40.000. Prezzo della transazione: EUR 100.000 (EUR 60.000 cash + EUR 40.000 valore delle 500 ore).
Nel settore tecnologico, il corrispettivo non-cash accade raramente, ma quando avviene è spesso:
Documentazione richiesta: Descrizione del corrispettivo non-cash, metodo di valutazione del fair value, e supporto alla stima (prezzi di mercato comparabili, listini interni, o valutazione professionista).
---

Corrispettivo fisso: L'importo stabilito nel contratto e non soggetto a modifiche (es. EUR 100.000 per una licenza)
Corrispettivo variabile: Importi che dipendono dal verificarsi o meno di eventi futuri (es. sconti, rabatti, bonus di performance, penalità)
Non-cash consideration: Beni o servizi ricevuti in pagamento (es. crediti di software del cliente, licenze concesse come controparte)
Corrispettivo dovuto a terzi: Se il cliente ha promesso importi a terzi e l'entità ha concordato di pagarli direttamente, questi si sottraggono dal prezzo della transazione
Rabatti per volume: Se il cliente usa il software per più moduli o siti durante l'anno, il prezzo per unità diminuisce. Es. "EUR 10.000 per modulo per il primo anno, EUR 8.000 al modulo se sottoscritti 5 moduli".
Sconti per pagamento anticipato: Es. "2% di sconto se pagato entro 15 giorni".
Bonus di performance: Es. "Se il sistema raggiunge il 99.9% di uptime per il trimestre, il cliente riceve un credito di EUR 5.000 per il trimestre successivo".
Penalità: Es. "Se il sistema scende sotto il 95% di uptime, il cliente ha diritto a un rimborso di EUR 500 per punto percentuale al di sotto del 95%".
Diritti di restituzione: Es. "Il cliente può restituire il software entro 30 giorni per un rimborso completo se non è soddisfatto".
Clausole di rinegoziazione: Es. "Il prezzo sarà rinegoziato a fine anno in base ai volumi effettivi consegnati".
Se il cliente usa 10 moduli (40% probabilità): totale EUR 100.000, costo EUR 8.000 per modulo
Se il cliente usa 15 moduli (50% probabilità): totale EUR 120.000, costo EUR 7.500 per modulo
Se il cliente usa 20 moduli (10% probabilità): totale EUR 140.000, costo EUR 7.000 per modulo
Valore atteso: Quando ci sono molti possibili esiti (ad esempio portafoglio di 500 clienti SaaS, ognuno con profili di utilizzo diversi). La media del portfolio è più prevedibile di un singolo cliente.
Importo più probabile: Quando c'è un chiaro esito dominante (es. il cliente usa "sempre" 15 moduli sulla base della cronologia storica, e la probabilità è 50% per 15 moduli, 30% per 10 moduli, 20% per 20 moduli).
Diritti di restituzione / trial period: Il cliente ha diritto a provare gratis per 30-60 giorni e poi decidere. Vincolare il ricavo al tasso di conversione storico (es. 85% se il cliente è solito convertire).
Sconti per pagamento anticipato: Se non è probabile che il cliente paghi anticipatamente (sulla base della cronologia), non includere lo sconto nella stima iniziale; includerlo solo quando il pagamento anticipato accade effettivamente.
Penalità di performance: Se il sistema è inaffidabile e frequentemente sotto l'SLA, vincolare il ricavo al livello di performance realista (non al target ottimistico).
Contratti pluriennali (es. 3-5 anni) con pagamento in una sola soluzione oggi per servizio futuro
Contratti governativi in cui il pagamento può essere ritardato di 60+ giorni dalla consegna (in cui l'entità sta effettivamente finanziando il cliente)
Permuta di software: Il cliente fornisce una vecchia licenza di un altro fornitore (credito verso la nuova licenza)
Crediti di infrastructure: Il cliente fornisce ore di utilizzo del proprio cloud (per test o hosting)

Fase 4: Allocare il prezzo della transazione alle obbligazioni di prestazione

Se il contratto ha più di un'obbligazione di prestazione distinta (es. licenza + implementazione + supporto), il prezzo deve essere allocato a ciascuna (IFRS 15.73–86).
La base di allocazione è il prezzo di vendita autonomo (standalone selling price, SSP) di ciascuna obbligazione (IFRS 15.79).

Determinare il prezzo di vendita autonomo

Il prezzo di vendita autonomo è il prezzo al quale l'entità venderebbe il bene o servizio separatamente al cliente (o a un cliente simile) in circostanze simili.
Come determinare l'SSP quando la merce è venduta separatamente?
Se l'entità vende la licenza software anche come standalone (non bundled), il prezzo standalone è il prezzo di listino regolare per la licenza (non un prezzo di sconto applicato al bundle).
Esempio: L'entità vende software di contabilità:
L'SSP della licenza è EUR 5.000 (il prezzo regolare quando venduta separatamente).
Come determinare l'SSP quando la merce non è venduta separatamente?
Se l'entità non vende il servizio di implementazione separatamente (ad esempio offre sempre il bundle), il revisore stima l'SSP usando uno dei metodi di stima riportati in IFRS 15.80:
Nel settore tecnologico italiano, la metodologia più usata è la 1 o la 3, perché il mercato è trasparente (molti competitor pubblici sui listini) e le differenze di complessità sono facilmente mappabili.
Documentazione richiesta: Per ogni obbligazione di prestazione, metodologia di stima dell'SSP, fonti dei dati (competitor listini, costi storici dell'entità, prezzi di mercato), e calcolo dell'SSP.
---

Allocazione proporzionale

Una volta determinati gli SSP, il prezzo della transazione è allocato proporzionalmente (IFRS 15.76).
Allocazione di un prezzo non comune (non scontato):
Contratto 1:
SSP totale = EUR 15.000. Prezzo contratto = EUR 12.000 (sconto globale di EUR 3.000).
Allocazione proporzionale:
Verifica: EUR 4.000 + EUR 6.400 + EUR 1.600 = EUR 12.000 ✓
Documentazione richiesta: Tabella con SSP di ciascuna obbligazione, SSP totale, prezzo della transazione, fattore di allocazione, e importo allocato.
---

Come standalone: EUR 5.000 per anno
Bundled con implementazione + training + primo anno di supporto: EUR 12.000 totali
Metodo del prezzo di mercato stimato: Confrontare con i prezzi pratticati da competitor comparabili. Ad esempio, il revisore cerche i listini di entità software simili italiane che vendono implementazione separatamente e usa quei prezzi come proxy dell'SSP. Per entità medie in Italia, l'implementazione SaaS varia da EUR 3.000 a EUR 15.000 a seconda della complessità; EUR 8.000 potrebbe essere ragionevole se il progetto è di complessità media.
Metodo del margine aggiunto: Partire da un costo stimato e aggiungere un margine ragionevole. Se il costo interno di implementazione è EUR 3.000 (junior developer, progress tracker, gestione progetto) e l'entità di solito applica un margine del 200%, l'SSP sarebbe EUR 9.000. (Questa non è una "formula magica"; il margine dovrebbe riflettere la pratica dell'entità su servizi simili venduti separatamente.)
Metodo della variazione adattata: Partire da SSP di beni/servizi simili aggiustati per differenze (complessità, durata, localizzazione geografica). Se l'implementazione standard è EUR 8.000 e questa è meno complessa (magari meno customizzazione), stimare EUR 6.000. Se più complessa, EUR 12.000.
Licenza software, SSP = EUR 5.000
Implementazione, SSP = EUR 8.000
Supporto 12 mesi, SSP = EUR 2.000
Licenza = EUR 12.000 × (5.000 / 15.000) = EUR 4.000
Implementazione = EUR 12.000 × (8.000 / 15.000) = EUR 6.400
Supporto = EUR 12.000 × (2.000 / 15.000) = EUR 1.600

Fase 5: Riconoscere i ricavi quando si soddisfa l'obbligazione di prestazione

Il momento del riconoscimento dei ricavi dipende da quando l'entità trasferisce il controllo del bene o servizio al cliente (IFRS 15.31–42).
Il controllo è trasferito quando il cliente è in grado di dirigere l'uso del bene/servizio e ottenere i benefici economici da esso (IFRS 15.33).

Indicatori di trasferimento del controllo

L'IFRS 15 fornisce tre indicatori per valutare quando il controllo è trasferito (IFRS 15.38):
Nel settore tecnologico italiano, i modelli più comuni sono:
---

Licenza software (punto nel tempo vs. over-time)

La licenza è un diritto di accesso (over-time) o un diritto di uso (punto nel tempo)?
Secondo IFRS 15.B55–B63, una licenza di software è diritto di accesso se l'entità offre:
Una licenza è diritto di uso se il cliente:
Nel caso del diritto di accesso (SaaS), il ricavo è riconosciuto over-time, solitamente in modo lineare (ogni mese la propria quota). Nel caso del diritto di uso (perpetua on-premise), il ricavo è riconosciuto al momento dell'installazione / live (punto nel tempo).
Documentazione richiesta: Analisi della natura della licenza (accesso vs. uso), date di inizio/fine della licenza, timeline di implementazione, e metodologia di riconoscimento dei ricavi (over-time lineare / non-lineare, o punto nel tempo).
---

Implementazione e consulenza (over-time)

Il servizio di implementazione o consulenza è normalmente una obbligazione di prestazione over-time perché il cliente riceve e consuma contemporaneamente i benefici (IFRS 15.35(a)).
Il revisore misura il progresso usando uno di questi metodi (IFRS 15.39–42):
Metodo degli input: esempio:
Progetto di implementazione SaaS per un'entità italiana:
A fine gennaio, il team ha speso 50 ore (di cui 40 ore junior developer a EUR 50/ora = EUR 2.000, e 10 ore senior consultant a EUR 200/ora = EUR 2.000, total cost EUR 4.000 con margine incorporato).
Utilizzo di input nel Metodo degli input (ore): 50 / 500 = 10%.
Ricavi da riconoscere: EUR 6.400 × 10% = EUR 640.
Metodo degli output: esempio:
Stesso progetto:
A fine gennaio, il team ha completato e messo in esercizio 1 modulo (su 5) ed è stato formalmente accettato dal cliente.
Percentuale di output completato: 1 / 5 = 20%.
Ricavi da riconoscere: EUR 6.400 × 20% = EUR 1.280.
Nel settore tecnologico italiano, il metodo degli output è più preciso se il contratto ha deliverable chiaramente definiti (moduli, fasi, milestone). Il metodo degli input è più pratico se i deliverable sono vaghi o il lavoro è altamente integrativo.
Documentazione richiesta: Scelta del metodo (input / output), parametro di misurazione (ore, costi, moduli, etc.), totale stimato all'inizio, progresso a ogni fine periodo, e percentuale di completamento con calcolo ricavi.
---

Supporto e manutenzione (over-time)

Il supporto continuativo (es. 12 mesi di manutenzione / hotline tecnica) è riconosciuto over-time linearmente, poiché il cliente riceve il servizio di protezione e assistenza continuamente per tutta la durata.
Prezzo allocato al supporto 12 mesi: EUR 1.600.
Ricavi riconosciuti al mese: EUR 1.600 / 12 = EUR 133,33.
Nel caso di supporto a livelli (es. "supporto standard" vs. "supporto premium" con upgrade), il revisore identifica se il cliente ha transizionato da uno stadio all'altro durante l'anno e rivede l'allocazione proporzionalmente.
Documentazione richiesta: Periodo di supporto, prezzo allocato, numero di mesi, e ricavo mensile lineare. Se upgrade o downgrade avviene durante il periodo, documentare la data e il calcolo revised.
---

L'entità ha diritto al pagamento: Il cliente è obbligato a pagare l'importo, indipendentemente da modifiche alle specifiche successive.
Il cliente ha responsabilità legale del bene/servizio: Il rischio di perdita, deterioramento, o manomissione ricade sul cliente.
Il cliente ha accettato il bene/servizio: Fisicamente (nel caso di software on-premise, dopo installazione e avvio; nel caso di SaaS, dopo attivazione dell'accesso); o contrattuali (il cliente ha firmato l'accettazione formale; oppure è decorso il periodo di prova senza obiezioni).
Accesso a software ospitato su server dell'entità (cloud, SaaS): over-time
Accesso al codice sorgente + aggiornamenti / patch continuative durante il periodo della licenza: over-time
Aggiornamenti / correzioni di bug frequenti e non-volontari (ad esempio patch mensili di sicurezza): over-time
Installa il software su propria infrastruttura (on-premise)
Non riceve aggiornamenti obbligatori futuri (solo il codice della versione X.0 con supporto fino a data Y)
Mantiene il software dopo scadenza della licenza (permesso di utilizzo perpetuo anche se il supporto cessa)
Metodo degli input: Proporzione dei input forniti rispetto al totale atteso (es. ore spese / ore stimate, spese di progetto / budget stimato).
Metodo degli output: Proporzione dei deliverable consegnati (es. numero di moduli implementati / numero totale di moduli, etc.).
Ore stimate: 500 ore
Prezzo allocato: EUR 6.400
Numero di moduli da implementare: 5
Prezzo allocato: EUR 6.400

Considerazioni specifiche del settore tecnologico italiano

Bundling complesso

Nel settore tecnologico italiano, è comune che le entità quotate vendano "soluzioni" integrate: software + implementazione + training + supporto + assistenza sul change management. L'IFRS 15 richiede di scomporre la soluzione nelle sue obbligazioni di prestazione distinte, ma la maggior parte dei clienti italiani vede la soluzione come un'unica transazione.
Il revisore deve:
Incarichi di revisione recenti in società tecnologiche italiane quotate hanno visto rilievi CONSOB quando l'entità aveva semplicemente denominato il tutto "Implementazione di soluzione" senza spiegare la scomposizione nelle componenti sottostanti e l'allocation di prezzo.

Ricavi derivati da contratti governativi

Nel settore della tecnologia italiana, molte entità forniscono software e servizi alle pubbliche amministrazioni. I contratti governativi spesso includono:
Il revisore deve:
---

Ricavi da contratti SaaS multi-anno con canoni variabili

Nel caso di SaaS, è comune che il canone sia variabile basato su:
L'IFRS 15.50 consente una "pratica" di semplificazione: se il corrispettivo è variabile basato su metrica di performance (moduli, utenti, transazioni), e l'entità ha il diritto di ricevere il corrispettivo in quell'importo dal cliente, il revisore riconosce il ricavo nell'importo a cui ha diritto (senza vincolare per il variabile) se:
Nel questo caso, il ricavo è riconosciuto nel mese in cui la metrica si verifica: a gennaio ricavi EUR 5.000 (su 10 moduli), a marzo ricavi EUR 7.500 (su 15 moduli).
Documentazione richiesta: Se si applica la pratica di semplificazione di cui sopra, documentare che i criteri sono soddisfatti (metrica sotto controllo del cliente, cronologia di pagamento affidabile, nessun diritto di restituzione).
---

Mettere in discussione il management su come è strutturato il contratto effettivamente (quanti servizi sono distinti nel documento contratuale?)
Verificare se ciascun elemento è facoltativo o obbligatorio
Documentare il ragionamento (linkage, integration, interdependenza) se il management sostiene che ci sia un'unica obbligazione
Testare, sulla base di una lettura esecutiva del contratto originale, se il ragionamento del management è supportato
Pagamento ritardato: Non al momento della consegna, ma 30-60 giorni dopo l'emissione della fattura (di fatto, l'entità finanzia il cliente pubblico)
Penalità di performance: Penali esplicite se il sistema non raggiunge SLA (ad esempio per ogni 1% al di sotto del 99% di uptime, 1% di riduzione del prezzo mensile)
Clausole di revisione dei prezzi: "Il prezzo sarà rinegoziato se le leggi tributarie italiane cambiano" o "Se il tasso di cambio EUR/USD si sposta oltre il 5%"
Diritti di verifica: Auditor pubblici possono revisionare i costi dell'entità per verificare che i margini siano ragionevoli
Documentare il termine di pagamento e valutare se c'è finanziamento significativo (di solito no, perché il ritardo è standard nel settore pubblico)
Valutare le penalità di performance e stimare il corrispettivo variabile vincolato (di solito le PA mantengono l'uptime contrattuale)
Monitorare le clausole di revisione dei prezzi per valutare se c'è una contingenza materiale di perdita futuro
Verificare la fattibilità tecnica dei livelli di servizio promessi (ad esempio, se il contratto promette 99.5% di uptime ma la tecnologia locale ha volatilità di rete il 5% del tempo, il rischio è reale)
Moduli attivi al mese: Il cliente paga EUR 500 per modulo attivo al mese. Se a gennaio usa 10 moduli, a marzo usa 15, a giugno usa 12, il ricavo varia ogni mese.
Utenti attivi: Il cliente paga EUR 50 per utente attivo al mese. Se ha 100 utenti a gennaio e 150 a marzo, la fatturazione e il ricavo aumentano.
Transazioni elaborate: Il cliente paga EUR 0,50 per transazione. Se processa 10.000 transazioni a gennaio, ricava EUR 5.000 quel mese.
La variabilità è dovuta a una metrica di performance controllata dal cliente (il cliente decide quanti moduli attivare)
Storicamente, il cliente non ha mai estinguere il diritto di l'entità di ricevere il corrispettivo una volta che il cliente ha usato la metrica (ad esempio, il cliente ha sempre pagato per i moduli usati, non ha mai chiesto un rimborso retroattivo)
Non c'è un diritto di restituzione o riduzione di prezzo

Considerazioni di revisione

Test di comprensibilità del ragionamento

Durante la revisione, il team deve valutare se il ragionamento contabile dell'entità è coerente con la pratica di revisione:

Aree di revisioneConsidered High Risk

Nel settore tecnologico, le aree high-risk sotto IFRS 15 sono:

Leggere il contratto originale del cliente, non solo la sintesi del management. Molta contabilità scorretta nasce dalla lettura imprecisa dei termini.
Porre domande specifiche: "Quali servizi distinti offriamo in questo contratto?" Non accettare risposte vaghe come "forniamo una soluzione integrata".
Comparare a contratti precedenti dello stesso cliente: Se un cliente aveva tre obbligazioni distinte in maggio e il management dice che ci ne sono due in giugno, verificare cosa è cambiato.
Testare l'allocazione SSP: Se il management stima il prezzo di standalone consulting a EUR 10.000, chiedere: "Abbiamo mai venduto questo tipo di consulting separatamente? A quanto l'abbiamo prezzato?" Se non l'abbiamo mai venduto, su quale base stima EUR 10.000?
Diritto di restituzione/trial period: Il cliente ha diritto a provare gratis per 30-60 giorni. La maggior parte delle entità non vincola il ricavo per la probabilità di restituzione, creando il rischio di overstatement. Testare: qual è la percentuale storica di trial che non convertono? Vincolare il ricavo a quel tasso.
Implementazione integrativa vs. distinta: È la implementazione un elemento separato o parte della "soluzione"? Molti manager dicono parte della soluzione (non