Nota: Questo post, come
tutti gli altri, riflette le miei considerazioni ed analisi su mercati e
specifici investimenti, ed è pubblicato a scopo puramente informativo. NON
deve essere considerato come una raccomandazione né di acquisto né di vendita,
ed ogni lettore è pregato di fare le proprie valutazioni: andare “short”
comporta rischi diversi ed aggiuntivi rispetto alle posizioni “long”.
Questo post vuole essere piuttosto
uno spunto di riflessione sull’analisi di bilancio di un potenziale
investimento. Commenti, idee, opinioni e suggerimenti sono benvenuti.
Temenos AG (TEMN:SW)
è una società svizzera leader mondiale nei software per il sistema bancario,
con oltre 1.500 piattaforme installate in 140 paesi. Nel 2012 ha realizzato un
fatturato di $450 milioni, così suddiviso: 28% da licenze per i software; 45%
da maintenance, ovvero ricavi
ricorrenti per il supporto continuativo, tipicamente su contratti di 5 anni; e 27%
da servizi quali implementazione, integrazione ed ottimizzazione della
performance. Il business è diversificato globalmente, con il 37% del fatturato
generato in Europa, il 27% in Asia, il 22% in Africa/Medio Oriente ed il 14%
nelle Americhe.
TEMN
è balzata alla mia attenzione leggendo un report sul futuro delle banche retail, che saranno sempre meno
focalizzate sulle filiali e sugli sportelli e sempre di più sulla tecnologia
digitale (carte, Internet, mobile, etc…). Date queste premesse e la leadership
nei sistemi informatici dedicati al settore bancario, TEMN era quindi
identificata come una delle future beneficiarie di questa rivoluzione digitale.
Dopo
aver analizzato l’azienda, la mia personale
opinione è tuttavia molto diversa.
La tesi
In
sintesi, i dati riportati nei bilanci di TEMN sono molto aggressivi: i crediti verso clienti sono
inspiegabilmente alti; gli utili sarebbero materialmente inferiori se i costi
di sviluppo del software fossero spesati ogni anno invece che essere capitalizzati;
ed i margini nel segmento dei servizi sono stranamente bassi.
TEMN
ha avuto due cambi di CEO tra il 2011 ed il 2012: Guy Dubois, assunto da Mach
Group a febbraio 2011, ha lasciato l’anno seguente dopo 4 trimestri consecutivi
in cui la crescita delle licenze vendute ha “mancato” le stime degli analisti. Nel
2012 David Arnott, da tempo CFO di TEMN, è salito di un gradino alla posizione
di CEO: sotto la sua guida, TEMN ha rifocalizzato la propria strategia sulla vendita
di prodotti con un ciclo di vita più breve e sul taglio dei costi.
Segnale di pericolo #1: DSO troppo elevati
TEMN
ha un ammontare di crediti da clienti (rappresentati dai days of sales outstanding, DSO) troppo elevato. I DSO sono di
solito il sintomo di una politica di contabilizzazione delle vendite molto
aggressiva, di scarso potere negoziale con i clienti, di controlli e processi
di incasso inadeguati, o una combinazione di questi. Per chi ha seguito i
problemi dello scorso anno di HP seguenti l’acquisizione di Autonomy, questo punto merita molta attenzione.
Il
grafico qui sotto mostra i DSO dal 2001 al 2012, suddivisi tra vendite non ancora fatturate (unbilled revenues: il cliente non ha
ancora ricevuto la fattura, ma TEMN ha già conteggiato la vendita basata sulla
percentuale del lavoro completato) e vendite
fatturate (billed revenues: il
cliente ha ricevuto la fattura ma non ha ancora pagato). Questo conteggio non
comprende le vendite posticipate (deferred revenues), discusse in seguito.
Fonte: bilanci annuali di Temenos AG.
TEMN
è il leader mondiale nel software per banche, ma deve comunque attendere 240-280 giorni prima di incassare quanto
venduto. Quante aziende leader nel loro settore devono aspettare 8-9 mesi
prima di essere pagate? Il secondo grafico mostra i DSO negli ultimi 4 anni per
un gruppo di aziende simili a TEMN: pur con business model a volte molto differenti, queste aziende sono pagate
in media in 100 giorni e mai oltre i 150 giorni. I DSO di TEMN sembrano inspiegabilmente
fuori mercato.
Fonte: bilanci annuali delle aziende citate.
Le
risposte di TEMN a questo problema sono tipicamente due.
1. L’implementazione dei progetti richiede tempo. Nel
bilancio 2011 si legge infatti (pag. 14): “One
of the reasons why Temenos has traditionally had such an elevated level of DSOs
has been our model of delivering our projects ourselves, which has resulted in
a high relative share of services revenues as well as licence payment terms
attached to project milestones. This, coupled with the length and complexity of
core banking implementations, has tied up considerable working capital in the
business relative to sales.” Questa linea di difesa è in parte vera rispetto a competitor europei più grandi, come ad
esempio SAP, che usa partner esterni per l’implementazione dei vari progetti
invece di fare tutto in casa. Tuttavia, il
fatto che un progetto sia lungo o complesso non significa necessariamente che
debba impiegare un ammontare eccessivo di working
capital: è possibile avere un progetto che dura 24 mesi ed essere
pagati ad intervalli regolari di 2-3 mesi, come fa ad esempio Accenture, che ha
DSO di 40 giorni. Una società come TEMN dovrebbe essere in grado di ottenere questo
tipo di termini di pagamento.
2. Il focus dovrebbe essere sui crediti verso
clienti al netto delle deferred revenues. Le vendite posticipate sono
soldi che sono incassati prima di portare a termine un servizio e prima che le
relative entrate siano conteggiate. Ad esempio, quando comprate la licenza per
l’antivirus del vostro PC, questa ha una durata di 12 mesi ma viene pagata al
momento dell’acquisto: se questo avviene il 1 settembre, al 31 dicembre la
società deve aggiungere una posta tra le passività per gli 8 mesi ulteriori sui
quali la licenza avrà validità (appunto una deferred
revenue).
Poiché la base di
installazioni di TEMN è cresciuta nel corso degli anni, la quota di ricavi da servizi
ricorrenti (maintenance) è cresciuta da
~25% al 45% dei ricavi totali.
Fonte: bilanci annuali di Temenos AG.
I ricavi da maintenance
sono tipicamente incassati in anticipo, e quindi anche le deferred revenues di TEMN sono cresciute negli anni come
proporzione delle vendite. Di conseguenza calcolare i DSO al netto delle
vendite posticipate farebbe apparire migliore la posizione di TEMN. Tuttavia,
dal punto di vista del business, non è chiaro perché si debba fare questa
compensazione. Se TEMN ha un cliente che paga in anticipo per maintenance ed ha anche fatture per
licenze ed altri servizi, può avere senso concentrarsi sui numeri netti. Ma se
i ricavi da maintenance arrivano dal
cliente A mentre quelli da licenze arrivano dai clienti B e C, queste non
possono essere compensate.
Seguendo il suggerimento di TEMN (grafico seguente),
i DSO netti mostrano effettivamente un andamento decrescente, ma solo grazie
al maggior apporto dei ricavi da maintenance.
Fonte: bilanci annuali di Temenos AG.
Inoltre, anche i DSO netti rimangono elevati (oltre 3 mesi): se facciamo lo stesso
esercizio con le altre aziende precedentemente nominate, la loro media di DSO
netti scende attorno a 10 giorni,
con solo Software AG attorno a 80 giorni. Per molte di loro (ad esempio
Salesforce, Citrix, Sage ed Oracle), i
DSO netti sono addirittura negativi, ovvero queste aziende riescono a farsi
finanziare dai clienti invece di impiegare il proprio capitale.
Infine, nel 2011 TEMN ha eliminato
$43 milioni di crediti verso clienti perché: “Continuously worsening economic climate combined with increased funding
needs in the banking sector have resulted in certain clients taking
increasingly aggressive attitude towards project delays and an increased
willingness to initiate litigation.” Questo potrebbe riflettere una contabilizzazione aggressiva delle
fatture negli anni precedenti. E nonostante questa “pulizia”,
nel 2012 una parte significativa dei quasi $300 milioni di crediti verso
clienti era in forte ritardo di pagamento ma senza i dovuti accantonamenti: $22
milioni erano in ritardo di oltre 360 giorni, $14 milioni tra 180 e 360 giorni
ed ulteriori $12 milioni erano in ritardo di 90-120 giorni.
Segnale di pericolo #2: capitalizzazione dei costi
di sviluppo del software
TEMN
capitalizza una parte dei costi di ideazione e produzione del proprio software,
ed ammortizza questi costi nel corso degli anni. Una politica contabile più
conservativa, seguita dalle maggiori società tecnologiche e farmaceutiche,
sarebbe di spesare questi costi nel
conto economico nell’anno in cui avvengono, e non solo la componente di
ammortamento. Poiché gli ammortamenti sono inferiori ai costi di R&D in
ogni anno, la conseguenza è che i
profitti di TEMN sono sovrastimati.
Ad esempio,
nel 2012 sono stati capitalizzati costi di sviluppo per $42 milioni, mentre
solo $25 milioni sono stati ammortizzati dal totale di “Internally developed software development costs”. Se l’intero ammontare dei costi fossero
stati spesati, nel 2012 EBIT sarebbe stato di $44 milioni anziché $60 milioni,
una riduzione del 27%. La conseguenza è che valutando TEMN sulla base di
P/E o EV/EBIT occorre fare degli aggiustamenti per poterla comparare con i competitors.
Segnale di pericolo #3: bassa profittabilità nel
segmento servizi
TEMN scompone
i margini operativi nei due segmenti in cui opera: prodotti e servizi. Mentre
nel segmento prodotti il margine operativo è stato in media del 40% negli
ultimi anni, quello nel settore servizi è stato attorno a 8% (5% nel 2011 e
1% nel 2012). Altre aziende simili hanno margini nel segmento servizi
attorno a 20%. Come molte aziende di software, TEMN utilizza risorse altamente
qualificate in paesi dove il costo è inferiore, come ad esempio in India: anche
assumendo una percentuale superiore di lavoratori in paesi più costosi ed il
fatto che i servizi non sono il core
business di TEMN, il gap nei margini è inaspettatamente ampio.
Facciamo
un ipotetico esempio per capire come questo possa impattare i risultati
finanziari. Una società vince un contratto per vendere un software ed
installarlo presso un cliente per un valore di €100, e può decidere di
suddividerlo 90:10 tra prodotto ed installazione, oppure 80:20. Se il costo
dell’installazione è di €9, nel primo caso i margini del segmento servizi saranno
molto bassi (profitto di €1 su ricavi di €10, ovvero 10%), mentre nel secondo saranno
superiori (il profitto è di €11 su ricavi di €20, ovvero 55%). Come detto
precedentemente, i ricavi da licenze sono contabilizzati in anticipo, mentre
quelli da installazione avvengono nel corso del periodo di implementazione: è quindi
possibile anticipare i profitti
suddividendo il contratto in modo che il segmento con i margini superiori
riceva una proporzione maggiore del valore del contratto.
Segnale di pericolo #4: destinazione dei flussi di
cassa
Negli ultimi 10 anni, TEMN
ha generato flussi di cassa operativi cumulati di $800 milioni. Di questi,
circa $230 milioni (29%) sono stati assorbiti dal working capital, mentre $550 milioni (69%) sono stati utilizzati per
capex ed acquisizioni di altre
aziende (il debito finanziario è invece passato da zero a $220 milioni). Praticamente l’intero ammontare dei flussi
di cassa prodotti dall’attività operativa sono stati utilizzati per mantenere ed
accrescere l’operatività. Tuttavia non sembra che le varie acquisizioni
abbiano apportato un grosso contributo: mentre il numero dei dipendenti è
cresciuto del 60% negli ultimi 5 anni, i ricavi per dipendente sono diminuiti
del 15%. Inoltre, gli investimenti di €550 milioni hanno incrementato il NOPAT
di soli €28 milioni, per un rendimento (molto
basso) del 5%.
Fonte: bilanci annuali di Temenos AG.
Altra
considerazione riguarda la conversione dei flussi di cassa: uno degli enormi
vantaggi del business del software è appunto di poter incassare in anticipo
prima di effettuare il relativo servizio e prima che le relative entrate siano
conteggiate. Di conseguenza i flussi di cassa operativi nel rendiconto
finanziario (i soldi incassati)
possono essere superiori ai profitti operativi nel conto economico (EBITDA), quello che si chiama caash conversion. È questo ad esempio
il caso di Microsoft, dove il cash
conversion è vicino appunto a 100%. Nel caso di TEMN, questo è invece in
media del 65%, e solo in un caso è stato superiore a 100%.
Fonte: bilanci annuali di Temenos AG.
Infine, TEMN
(che solo nel 2012 ha cominciato a pagare un dividendo) ha riacquistato azioni,
al netto di quelle emesse, per circa $195 milioni dal 2005, pagando nello
stesso periodo ai dirigenti $95 milioni in opzioni ed altri bonus azionari. Un
management pagato molto in opzioni preferisce i buyback, senza alcuna considerazione sui prezzi pagati per le azioni proprie, al pagamento dei dividendi. Ma per un
investitore è vero il contrario.
Conclusioni
Non vi è
dubbio che TEMN abbia un posizione di mercato molto forte, consolidata da un
flusso costante di ricavi da maintenance
da una ampia base di piattaforme installate. Tuttavia i punti discussi qui
sopra riguardo i valori contabili rendono difficile determinare il valore
intrinseco dell’azienda. Non sto assolutamente affermando che i bilanci siano falsi,
poiché con ogni probabilità rispettano - almeno nello spirito – tutti i
principi contabili IFRS [Per chi fosse interessato, esiste un modello – BeneishM-Score - che usa 8 differenti metriche contabili per determinare se un’azienda ha
manipolato i propri bilanci: secondo questo modello, i bilanci di Temenos NON
sarebbero manipolati]. Se lo fossero, TEMN sarebbe la più classica delle azioni
su cui andare short.
Quello che
potrebbe trattenere un investitore anche sofisticato da questa decisione è che
Temenos è un asset strategico che
potrebbe attrarre l’interesse di qualche competitor
più grande in un’operazione di M&A. I multipli impliciti in operazioni di
M&A nel settore del software sono stati tipicamente tra 4x e 10x EV/maintenance sales (oggi TEMN tratta già a
10x questo multiplo, uno dei vari segnali della sua piena valutazione). Al
valore medio di questo range (7x) il titolo potrebbe valere CHF 16, rispetto ai
CHF 24 di oggi.
PS:
Temenos in greco significa: “spazio sacro”, un pezzo di terra
circoscritto assegnato esclusivamente ai re o ad una divinità.
Una domanda/commento riguardo la politica contabile dello sviluppo software (SW).
RispondiEliminaPremetto che NON ho conoscenze di contabilità, mentre, ho, per esperienza personale, una certa conoscenza delle problematiche (tecniche) di sviluppo SW.
Perchè secondo Lei lo sviluppo SW andrebbe contabilizzato nell'anno, invece che ammortizzato ???
A mio avviso la scelta dipende (essenzialmente) dal tipo di SW che si sta sviluppando. Mi spiego: se sviluppo un SW che poi venderò negli anni a venire a più clienti, dovrebbe avere senso ammortizzare tale sviluppo in base ad una ipoteticha (ma conservativa) vita del prodotto. Viceversa, se sviluppo un SW per una specifica realtà aziendale, difficilmente adattabile ad altre realtà (il cosiddetto System Integration), tale sviluppo andrebbe spesato nell'anno.
Onestamente NON ho mai visto il bilancio di Microsoft, ma dubito fortemente che gli sviluppi siano contabilizzati nell'anno, invece che ammortizzati.
Cordialità
Marco D.M.
Marco, chiedo scusa per il ritardo nel rispondere ma ero ad una conferenza.
EliminaQuello che fa Temenos non è illegale, è però “aggressivo” rispetto allo spirito di cercare di essere conservativi che ispira i principi contabili. Se i costi di sviluppo vengono capitalizzati (e poi ammortizzati) significa che si ha un aumento delle attività in bilancio, e quindi un corrispondente aumento dei mezzi propri (equity) perché non vi è un aumento corrispondente delle passività. Il problema è che la determinazione del valore di questa attività (intangibles) è molto aleatorio, perché non si può sapere in anticipo quale sarà il rendimento monetario di questi sforzi di ricerca e sviluppo. Tu presteresti i soldi ad un’azienda che ha come unica attività in bilancio (o come principale voce tra le attività) e quindi come “garanzia” delle cose immateriali come “Costi sostenuti per R&D”?
Tutte le maggiori aziende tecnologiche e farmaceutiche seguono la strada di spesare i costi in R&D nell’anno in cui sono fatte, anziché capitalizzarle. Questo porta ad un altro paradosso dei principi contabili (R&D generata internamente è spesata mentre quella ottenuta da una acquisizione, il cosiddetto goodwill, è capitalizzata). Ma questo è un discorso molto lungo sulla reale utilità dei principi contabili così come sono.
Oracle, ad esempio, dichiara nell’ultimo bilancio che: “All research and development costs are expensed as incurred. Software development costs required to be capitalized under ASC 985-20, Costs of Software to be Sold, Leased or Marketed, and under ASC 350-40, Internal-Use Software, were not material to our consolidated financial statements in fiscal 2013, 2012 and 2011.”
Microsoft, invece, adotta un approccio più “aggressivo”, anche se meno di Temenos: lo scorso anno ha spesato R&D per $10,4 miliardi, e nel bilancio annuale dichiara: “Such costs related to software development are included in research and development expense until the point that technological feasibility is reached, which for our software products, is generally shortly before the products are released to manufacturing. Once technological feasibility is reached, such costs are capitalized and amortized to cost of revenue over the estimated lives of the products.”
Le spese per i software si possono capitalizzare (non ho infatti detto che i bilanci di Temenos sono falsi), ma si introduce un ulteriore elemento di aleatorietà. Essendo un value investor, preferisco vedere bilanci “puliti” e con valori conservativi, cosa che il bilancio di Temenos invece non fa. E preferisco vedere spesati i costi di R&D in ogni singolo anno (anziché solo la parte di ammortamento), perché mi da un’idea più chiara di quali sono i reali utili/flussi di cassa dell’azienda.
Grazie per l'esauriente risposta. Se ho capito bene, la frase rilevante è l'ultima: "perché mi da un’idea più chiara di quali sono i reali utili/flussi di cassa dell’azienda".
EliminaProbabilemente, per quello che posso capire io, l'approccio maggiormente "neutrale", mi sembra essere quello di Microsoft. Ma capisco che un value investor preferisca approcci ancora più conservativi.
Grazie & Cordiali Saluti
Marco D.M.
anche se cerco di capire da dove vengono e perchè, io rimuovo sempre goodwill&intangibles nelle mie analisi, sopratutto quelle asset-based, per cui l'approccio che preferisco è quello di Oracle.
EliminaQuello che è importante è infatti il goodwill economico (cioè vantaggi competitivi, capacità di innovare, di aumentare i prezzi, ...), non quello contabile che appare nei bilanci.