Odoo 20, Light User: cosa sono, come si contano e perché la fattura può crescere senza che nessuno se ne accorga

Con Odoo 20 il listino ufficiale ha una voce che prima non c'era: l'utente Light, a 4,90 € per utente al mese. È una categoria nuova, nata con questa release: nella 19 non esiste né nel listino né nel software. E arriva insieme al primo ritocco dei prezzi dal 2022: il piano Personalizzato aumenta del 20%, mentre lo Standard resta invariato, come ha annunciato la stessa Odoo il 24 settembre (blog ufficiale Odoo). Nello stesso annuncio il Light User è presentato come un accesso a pagamento "per employee", per dipendente.

Presentata così, sembra una buona notizia: un utente che costa meno, per chi in Odoo deve solo segnare le ferie o timbrare. In parte lo è. Ma leggendo il codice di Odoo 20 e la definizione sul listino, la domanda giusta non è quanto costa un utente Light. È chi viene contato come tale, e quando smette di esserlo.

Cos'è un Light User, secondo il codice

Fino a Odoo 18 i permessi di un utente interno si leggono app per app: Vendite, Magazzino, Contabilità, ciascuna con i suoi livelli. Odoo 19 ha aggiunto nella scheda utente un campo riassuntivo, role, con due soli valori: User e Administrator. In Odoo 20 quel campo ne ha tre — Light, User, Administrator — e non è più solo un'etichetta: dice quale licenza conta quell'utente. Il commit che introduce il ruolo Light (818614c, 16 aprile 2026) dichiara lo scopo senza giri di parole:

The goal is to allow each employee to have a low access user (backend) without having to pay the full price of a regular user.

Tecnicamente un Light User non è un tipo di utente separato: è un normale utente interno a cui sono rimasti solo i gruppi classificati come "leggeri". Ogni modulo dichiara i suoi: le proprie ferie, le proprie presenze, il pranzo, l'operatore di cassa del POS, l'operatore in reparto, alcune opzioni di magazzino e di vendita. Il listino elenca le stesse cose dal lato commerciale: le mie ferie, le mie note spese, le mie valutazioni, le mie presenze, la mia pianificazione, l'operatore barcode, la Knowledge in sola lettura (listino ufficiale).

Fin qui, uno strumento sensato. I problemi stanno in due dettagli.

Primo dettaglio: si diventa utenti pieni con una spunta

Il ruolo non si sceglie, si calcola. Il campo role è una proiezione dei gruppi dell'utente: se tutti i gruppi sono "leggeri", l'utente è Light; se ne compare anche uno solo che non lo è, l'utente è User — cioè una licenza piena.

Lo dice il commit, e lo verifica un test del modulo HR (test_real_access_makes_regular):

Granting access beyond the light set turns a Light user into a regular User.

In pratica: il responsabile del personale che dà a un operaio l'accesso in lettura ai documenti di qualità, o a un magazziniere la possibilità di vedere un'app in più, ha appena trasformato una licenza Light in una licenza piena. Nel codice che calcola il ruolo non c'è alcun avviso né conferma: cambia un campo calcolato.

Alcune app sono riservate per costruzione agli utenti pieni: in Enterprise il menu di Knowledge, quello delle Approvazioni e quello dell'AI sono visibili solo al gruppo base.group_user_regular. Chi vuole che il dipendente in reparto chieda un'approvazione dal backend, o usi l'assistente AI, paga un utente pieno.

Secondo dettaglio: contano anche i dipendenti senza login

Questa è la parte che ci aspettiamo genererà più discussioni al primo rinnovo.

Oggi la definizione sul listino ufficiale è doppia:

È considerato Light user qualsiasi account utente indicato come attivo e contrassegnato come "Light user" all'interno del software, oppure qualsiasi scheda dipendente attiva (dall'app Dipendenti) non collegata a un account utente attivo di tipo non-portale.

E nella stessa pagina, tra gli esempi di utente pagante, c'è scritto testualmente: "un dipendente senza account utente".

Cioè: ogni dipendente attivo nell'app Dipendenti che non ha un utente è un Light User, anche se non ha mai fatto login e non lo farà mai. L'anagrafica HR, che molte aziende tengono completa perché serve a presenze, buste paga, turni o semplicemente all'organigramma, diventa una base di fatturazione.

E il codice di Odoo 20 lo misura. Da questa versione il messaggio periodico che ogni istanza manda a Odoo (il publisher warranty, lo stesso con cui Odoo verifica il contratto) contiene due contatori nuovi:

• nbr_light_users e nbr_active_light_users, gli utenti con ruolo Light (commit 5d0d3ac, 14 agosto 2026);
• nbr_employees_wo_user, i dipendenti attivi senza utente, o con un utente archiviato o solo portale (addons/hr/models/update.py, file che in Odoo 19 non esiste).

È esattamente la seconda metà della definizione del listino, tradotta in una query.

Va aggiunto che Odoo 20 spinge attivamente nella stessa direzione: la scheda del dipendente ha un nuovo widget per creare l'utente e mandare l'invito con un clic, e il commit lo dice chiaramente — each employee should have at least a light user. Nel codice, la funzione che lo crea descrive il risultato come un utente "less-billable". Meno fatturabile, non gratuito.

Fino a settembre non era così

La regola è nuova, e lo si vede confrontando il listino ufficiale con le sue copie archiviate. Fino al 14 settembre 2026 la domanda "Qual è la definizione di utente pagante?" aveva questa risposta (copia del listino al 14/09/2026):

Un utente pagante è di solito un dipendente che ha accesso al back-end di Odoo per creare, visualizzare o modificare documenti.

Dei dipendenti senza accesso non si parlava. Nella copia del 1° ottobre la definizione si allunga — "or an employee (record in hr application) who has no linked user" — e tra gli esempi di utente pagante compare una riga nuova: "An employee without users" (copia del listino al 01/10/2026).

Per anni, quindi, la regola è stata chiara: si paga chi entra nel gestionale. E molte aziende ci hanno costruito sopra. Hanno caricato in Odoo tutto il personale — operai, autisti, addetti di reparto, stagionali — proprio perché le schede dipendente non costavano nulla: servivano alle presenze, ai turni, alle buste paga, all'assegnazione di mezzi e attrezzature, e il budget del software si faceva contando solo gli utenti.

Con la nuova definizione quello stesso database cambia valore. Ogni scheda attiva senza utente è una licenza Light. Il budget pensato su "quindici utenti" diventa "quindici utenti più tutte le persone in anagrafica", senza che l'azienda abbia cambiato nulla nel modo in cui usa Odoo.

Un esempio di calcolo, con il prezzo del listino italiano: un'azienda con 80 dipendenti in anagrafica e 15 utenti che lavorano nel gestionale ha 65 schede senza utente. A 4,90 € al mese ciascuna sono 3.822 € l'anno in più, prima ancora dell'aumento del 20% sul piano Personalizzato.

Perché rischia di scontentare molti clienti

Messi insieme, i pezzi disegnano uno scenario che conviene guardare prima che arrivi in fattura.

Cambia le regole a partita in corso. Chi ha scelto Odoo e lo ha riempito di dati negli anni lo ha fatto con una regola precisa sul costo. Non è l'aumento in sé a pesare, è che la base su cui si calcola si sposta su qualcosa che il cliente aveva costruito pensando fosse gratuito. Ed è difficile da far digerire a chi deve giustificare il budget IT in consiglio di amministrazione. Questi cambiamenti minano la credibilità del rapporto tra cliente e fornitore (Odoo SA): oggi il cambio è stato sui dipendenti, chi garantisce alle aziende che un domani non accadrà la stessa cosa per gli utenti portale? 

Arriva insieme a un aumento. Il piano che sale del 20% (annuncio di Odoo) è il Personalizzato, cioè quello di quasi tutte le aziende che lavorano con un partner: secondo il listino è il piano che serve per Odoo.sh e on-premise, API esterna, Studio, più aziende e IA agentica. Oggi costa 27,90 € per utente al mese con fatturazione annuale e 33,90 € con fatturazione mensile; lo sconto mostrato in pagina (22,90 € e 27,90 €) vale solo per i primi 12 mesi sugli utenti ordinati all'inizio. Un cliente che al rinnovo vede salire il prezzo unitario e comparire una riga nuova per gli utenti Light difficilmente la leggerà come un'agevolazione.

Colpisce chi ha più dipendenti che utenti. Manifattura, logistica, retail con molti punti vendita, aziende che usano Odoo per le presenze o le buste paga: è normale avere molti più dipendenti in anagrafica che utenti veri. Fino a settembre la conversazione sul costo di Odoo era "quanti utenti lavorano nel gestionale". Con questa definizione diventa "quante persone hai in organico".

Il passaggio a utente pieno è silenzioso. Un permesso in più assegnato con buone intenzioni cambia il tipo di licenza, e nessuno se ne accorge finché non lo vede il contratto. Il controllo non è tecnico: è di processo, e nella maggior parte delle aziende non esiste.

Il prezzo non è lineare da ottenere. Per attivare la licenza Light il listino rimanda all'incontro con un consulente dedicato di Odoo, che "analizzerà le tue esigenze per proporti la soluzione più adatta". Non è un'opzione che si spunta nel portale.

La misura è automatica. Non c'è niente di illegittimo nel fatto che il software conti quello per cui si paga: lo fa da sempre con gli utenti. Ma è giusto saperlo: dalla 20 Odoo sa quanti dipendenti senza utente ci sono nel tuo database, e la definizione del listino dice che quei dipendenti si pagano.

E chi usa Odoo Community?

Per chi usa solo la versione Community — il repository odoo/odoo, senza i moduli Enterprise — la risposta breve è: nessuna licenza da pagare, Light o piena. I moduli coinvolti (base, hr, mail) sono rilasciati con licenza LGPL-3, e il listino con utenti, Light User e piani riguarda gli abbonamenti Enterprise.

Ci sono però due cose da sapere.

Il ruolo Light esiste anche nella Community. Il campo role, i gruppi "leggeri" e il widget per creare l'utente dalla scheda dipendente stanno nei moduli Community. Lì sono soltanto un livello di accesso: un modo comodo per dare a ogni dipendente un utente con il minimo indispensabile. Nessun costo.

Anche la Community comunica i contatori a Odoo. Il messaggio publisher warranty è nel modulo mail, che è Community, e parte da un'azione pianificata settimanale (Publisher: Update Notification) verso services.odoo.com. Dalla 20 quel messaggio contiene il numero di utenti Light e di dipendenti senza utente anche in un'installazione Community, dove il codice di abbonamento è semplicemente vuoto. Non produce una fattura, ma vuol dire che Odoo sa quante persone ci sono in anagrafica anche nei database che non paga. Su un'installazione Community on-premise l'indirizzo di destinazione è un'opzione del file di configurazione (publisher_warranty_url) e l'azione pianificata si può disattivare. Su Enterprise no: è lo stesso canale con cui viene verificato l'abbonamento.

La conseguenza pratica è per chi sta valutando il passaggio da Community a Enterprise. Fino a settembre il conto si faceva sugli utenti. Oggi va fatto anche sulle schede dipendente, e un'azienda che usa la Community per presenze e personale può scoprire che il costo dell'Enterprise è molto diverso da quello che aveva stimato.

Cosa controllare prima del prossimo rinnovo

Sono controlli da un'ora, e conviene farli prima che il contratto si rinnovi da solo:

1. Quanti utenti hai per ruolo. In Odoo 20, Impostazioni → Utenti, raggruppando per Ruolo: Light, User, Administrator. Chi è User ma usa solo ferie e presenze ha probabilmente un gruppo di troppo.
2. Quanti dipendenti attivi senza utente. Nell'app Dipendenti, filtro sui dipendenti senza utente collegato. Ex dipendenti mai archiviati, collaboratori occasionali, schede duplicate: ognuno è una licenza Light secondo la definizione.
3. Chi assegna i permessi. Decidere chi può dare gruppi aggiuntivi agli utenti, e saperlo. Una spunta in più è una licenza piena in più.
4. Se HR deve stare in Odoo. Per alcune aziende tenere l'anagrafica completa del personale in Odoo vale il costo, per altre no. È una scelta, non un dettaglio di configurazione.
5. Su Odoo 19 o precedenti, il ruolo Light non esiste nel software, ma la definizione del listino non fa distinzioni di versione. Prima del rinnovo, e prima di una migrazione alla 20, conviene contare le schede dipendente attive senza utente e chiedere come verranno conteggiate.

In sintesi

Il Light User è un'idea ragionevole: far entrare in Odoo chi oggi ne resta fuori, a un prezzo più basso. Ma la definizione scelta da Odoo conta come Light anche chi in Odoo non entra mai. Così cambia la regola su cui molte aziende hanno costruito per anni il loro database, quella per cui le schede dipendente non si pagavano. Il codice della 20 le misura e le comunica, e basta un permesso per far scattare la licenza piena. Arrivando insieme a un aumento dei prezzi, è facile che molti clienti lo scoprano dalla fattura invece che dal partner.

Se vuoi capire cosa cambia nel tuo caso — quanti utenti e dipendenti hai oggi, quanti ruoli sono assegnati per abitudine, cosa succede migrando alla 20 — parliamone: è un'analisi breve, e si fa sui dati reali del tuo database.

Per una panoramica completa della release, leggi la nostra overview tecnica di Odoo 20.