Articoli

Abbiamo esaminato sinteticamente nel precedente post ( Cash-flow previsionale e IA: come gestire i castelletti SBF ) come modificare l’architettura di integrazione dei vari tipi di dati al fine di costruire un cash-flow previsionale adatto ad una PMI per tenere conto dell’esistenza di castelletti s.b.f. (presentazione ri.ba. e anticipo fatture).

Ciò data la particolarità di quanto stabilito dalla direttiva europea PSD2.

Qui invece esamineremo le relazioni tra cash flow previsionale e budget, cioè come tener conto dei dati derivanti dai budget (ove esistenti e formalizzati documentalmente).

La risposta dipende dagli applicativi utilizzati.

Cash flow previsionale e budget: il problema concettuale

I dati di budget sono diversi per natura da tutti gli altri dati recepiti nei diversi layer (“livelli”: si veda il post sopra richiamato e l’architettura proposta più sotto). Gli ordini confermati e la pipeline CRM hanno un ancoraggio alla realtà (un cliente ha firmato o ha almeno trattato). Il budget vendite è invece una previsione pura, costruita a tavolino. Questo crea un problema di affidabilità: se il motore IA li tratta allo stesso modo degli ordini confermati le previsioni di cassa spesso diventano troppo ottimistiche.

Per questo motivo il budget vendite non dovrebbe mai “mescolarsi” con i dati certi, ma essere recepito nel sistema con un peso probabilistico; il layer in cui inserirlo dipende proprio da quanto è strutturato e affidabile il processo con cui viene prodotto.

Ipotesi per le vendite da budget

Caso 1 — Excel (scenario più comune nelle PMI)

Il budget è un file Excel aggiornato periodicamente dalla direzione o dal commerciale. In questo caso siamo nel Layer 4, perché richiede un’azione manuale di caricamento. Il middleware legge il file da una cartella condivisa o lo riceve via upload, lo normalizza e lo inserisce nel DB con un flag “budget” e un coefficiente di confidenza configurabile (es. 60%). Il vantaggio è la semplicità; lo svantaggio è che dipende dalla disciplina di chi aggiorna il file.

Caso 2 — Salesforce o HubSpot o altri piattaforme di CRM con forecast strutturato

Questi CRM hanno già un modulo di forecast con probabilità di chiusura per fase di pipeline. In questo caso siamo nel Layer 3, perché i dati arrivano via API in modo automatico e strutturato. Il middleware legge le opportunità con data di chiusura prevista, importo e percentuale di probabilità e costruisce una curva di incasso attesa pesata. È il caso ottimale perché la probabilità è già stimata dal CRM sulla base dello storico.

Caso 3 — ERP con modulo budget (SAP, TeamSystem, ecc.)

Se il gestionale ha un modulo di pianificazione o budget attivo, i dati sono già nel Layer 1 e viaggiano con le stesse API delle fatture. Il middleware li distingue tramite un campo tipo “documento = budget” e li tratta separatamente. È il caso più raro nelle PMI ma il più integrato.

Caso 4 — nessuno strumento strutturato

Il commerciale stima le vendite future a voce o in riunione. Qui si è necessariamente nel Layer 4, con un’interfaccia semplice di input manuale dove si inserisce: prodotto/cliente, importo previsto, mese atteso, grado di confidenza soggettivo. È un dato grezzo ma meglio di niente, perché almeno entra nel sistema con un peso esplicito.

Acquisti conseguenti alle vendite previste

Questo è il passaggio più delicato, perché introduce una dipendenza causale: se prevedo di vendere X, devo comprare Y entro una certa data per poter produrre. Ci sono due approcci.

Il primo è il collegamento manuale: nel Layer 4 si inserisce la vendita prevista e contestualmente si stima il fabbisogno di acquisto associato (materie prime, componenti, servizi) . Questo approccio è semplice ma richiede disciplina.

Il secondo è il collegamento automatico tramite distinta base: se il gestionale/ERP ha una distinta base attiva, il middleware può calcolare automaticamente il fabbisogno di acquisto partendo dalla previsione di vendita. Questo è tipico di ERP strutturati (SAP, Panthera, anche alcuni TeamSystem) e porta i dati direttamente nel Layer 1. Per le PMI senza distinta base formalizzata, si può approssimare con un coefficiente fisso per categoria di prodotto (es. “ogni € 10.000 di venduto genera € 4.000 di acquisti“). Chiaramente diminuisce l’attendibilità.

Vincoli di capacità produttiva

Questo è il tema più complesso e raramente gestito nelle PMI. I vincoli di capacità impattano il cash-flow in due modi: ritardano i ricavi (se non si riesce a produrre in tempo, la fattura “slitta”) e anticipano i costi (si devono acquistare risorse prima di incassare).

Gli approcci possibili sono tre, in ordine crescente di complessità.

Il più semplice è inserire nel Layer 4 un calendario di capacità mensile (ore disponibili, turni, macchinari) e confrontarlo manualmente con il piano di produzione previsto. Se la capacità è satura, il commerciale sposta la data di fatturazione prevista.

Il secondo è usare un MES o un modulo di pianificazione produzione già integrato nel gestionale — in questo caso i vincoli arrivano via API nel Layer 1 e il middleware può calcolare automaticamente lo slittamento dei ricavi.

Il terzo, più sofisticato, è un motore di ottimizzazione che, dato il portafoglio ordini confermati + budget, la capacità disponibile e i lead time di acquisto, calcola il piano di produzione ottimale e da lì deriva il cash flow atteso. Questo esula dal middleware semplice ed è un modulo IA dedicato — utile per aziende manifatturiere con cicli di produzione complessi.

In sintesi: dove collocare i dati di budget nello schema

┌─────────────────────────────────────────────────────────────────────────────┐
│                                 SORGENTI DATI                               │
│    ┌─────────────┐ ┌──────────────┐ ┌───────────────┐ ┌─────────────────┐   │
│    │ GESTIONALE  │ │ HOME BANKING │ │ EMAIL / CRM   │ │ PRODUZIONE      │   │
│    │ /ERP        │ │              │ │               │ │ MES / MRP       │   │
│    └─────────────┘ └──────────────┘ └───────────────┘ └─────────────────┘   │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ LAYER 1 — DATI CERTI                                                        │
│ Gestionale / ERP via API                                                    │
│ · fatture attive & passive · anagrafica clienti/fornitori                   │
│ · scadenzario · Prima nota / movimenti                                      │
│ · budget da modulo ERP (se attivo) · distinta base / fabbisogno acquisti    │
│ · vincoli capacità da MES/MRP · ordini di produzione pianificati            │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ LAYER 2 — DATI IN TEMPO REALE                                               │
│ Home Banking via PSD2                                                       │
│ · saldo c/c disponibile · movimenti estratto conto                          │
│ · accrediti SBF su c/c · addebiti insoluti su c/c                           │
│                                                                             │
│ ⚠ PORTAFOGLIO SBF — FUORI PERIMETRO PSD2                                    │
│ Canale di accesso alternativo da scegliere:                                 │
│                                                                             │
│     ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │
│     │ A) API CBI          │ │ B) EXPORT MANUALE   │ │ C) MODULO           │ │
│     │ CORPORATE           │ │ CSV / XML           │ │ TESORERIA ERP       │ │
│     │ [AUTO] ⚡           │ │ [SEMI] ?          │ │ [AUTO] ?           │ │
│     │                     │ │                     │ │                     │ │
│     │ · CBI Globe API     │ │ · download portale  │ │ · lettura flussi    │ │
│     │ · castelletti       │ │ · CSV/Excel/XML     │ │ SBF dal modulo      │ │
│     │ real-time           │ │ SEPA                │ │ tesoreria già       │ │
│     │ · distinte &        │ │ · import            │ │ attiva nel          │ │
│     │ partite             │ │ schedulato          │ │ gestionale          │ │
│     │ · stati & insoluti  │ │ · universale        │ │                     │ │
│     └─────────────────────┘ └─────────────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ LAYER 3 — DATI ANTICIPATI (automatici ma non certi)                         │
│ Email · CRM · forecast strutturato                                          │
│                                                                             │
│ · distinte SBF via email · ordini confermati non fatturati                  │
│ · conferme d'ordine da email · pipeline vendite CRM                         │
│                                                                             │
│ VENDITE FUTURE DA BUDGET — se CRM strutturato (Layer 3):                    │
│ ┌─────────────────────────────┐ ┌──────────────────────────────────────┐    │
│ │ SALESFORCE / HUBSPOT        │ │ CRM CON FORECAST API                 │    │
│ │ · opportunità con prob. %   │ │ · data chiusura prevista             │    │
│ │ · importo & data chiusura   │ │ · importo pesato per probabilità     │    │
│ │ · curva incasso attesa      │ │ · curva acquisti conseguenti         │    │
│ └─────────────────────────────┘ └──────────────────────────────────────┘    │
│                                                                             │
│ ACQUISTI CONSEGUENTI (se CRM strutturato):                                  │
│ · fabbisogno stimato da coefficiente fisso per categoria prodotto           │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ LAYER 4 — INPUT MANUALE E STIME                                             │
│ Dati soggettivi · Aggiustamenti · Budget non strutturato                    │
│                                                                             │
│ CORREZIONI OPERATIVE:                                                       │
│ · pagamenti effettuati non ancora contabilizzati                            │
│ · proroghe scadenze concordate · override previsioni AI                     │
│                                                                             │
│ VENDITE FUTURE DA BUDGET — se non strutturato (Layer 4):                    │
│  ┌─────────────────────────────┐ ┌──────────────────────────────────────┐   │
│  │ EXCEL                       │ │ INPUT MANUALE DIRETTO                │   │
│  │ · upload file da cartella   │ │ · cliente / prodotto previsto        │   │
│  │ · importo & mese previsto   │ │ · importo & mese atteso              │   │
│  │ · coefficiente confidenza   │ │ · grado di confidenza soggettivo     │   │
│  │ configurabile (es. 60%)     │ │ · inserito da commerciale/direzione  │   │
│  └─────────────────────────────┘ └──────────────────────────────────────┘   │
│                                                                             │
│ ACQUISTI CONSEGUENTI (Layer 4):                                             │
│ · Stima manuale fabbisogno · Coefficiente fisso per categoria               │
│                                                                             │
│ VINCOLI CAPACITÀ PRODUTTIVA (Layer 4):                                      │
│ · calendario capacità mensile · ore disponibili / turni                     │
│ · se capacità satura → slittamento data fatturazione prevista               │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ MIDDLEWARE (proprietà cliente)                                              │
│                                                                             │
│ · raccoglie dati da tutti 4 i layer                                         │
│ · adatta i formati sorgente tramite adapter specifici                       │
│ · normalizza tutto in formato standard proprietario                         │
│ · applica peso probabilistico ai dati di budget (≠ dati certi)              │
│ · calcola acquisti necessari da distinta base o coefficiente fisso          │
│ · verifica vincoli capacità e slitta ricavi se necessario                   │
│ · salva nel DB cliente (storico permanente, export aperto)                  │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ MOTORE IA — CASH-FLOW ENGINE                                                │
│                                                                             │
│ · piano previsionale 6 mesi · alert liquidità                               │
│ · ottimizzatore castelletti SBF · scoring insoluti                          │
│ · previsione acquisti & uscite · simulazioni scenari (best/worst)           │
│ · cruscotto unificato · KPI in tempo reale                                  │
└─────────────────────────────────────────────────────────────────────────────┘

Riprendiamo quanto esaminato in merito alla costruzione di un cash flow previsionale per le piccole-medie imprese (PMI) con il supporto dell’IA, esaminando i rapporti tra cash flow previsionale e castelletti s.b.f..

Avevamo visto in precedenza ( Cash flow previsionale per le PMI: un approccio pratico ) che i dati necessari alla scopo possono essere recuperati tramite una architettura multi-sorgente, che potrebbe essere strutturata così:

LAYER 1: dati certi

(da gestionale via API – automatico)

 ↓

LAYER 2: dati in tempo reale

(da home-banking via PSD2 – automatico)

  ↓

LAYER 3: dati anticipati

(da email/CRM – semi-automatico)

   ↓

LAYER 4: correzioni/integrazioni

(input manuale spot – interfaccia di facile utilizzo)

  ↓

MOTORE IA

Con riguardo ai dati di origine bancaria, essi vengono recuperati in automatico tramite home-banking grazie alla normativa PSD2 (layer 2).

Occorre tuttavia tenere presente che tipicamente le PMI utilizzano castelletti al salvo buon fine (SBF) per lo smobilizzo del portafoglio commerciale. Qui sorge però un problema, che ha origine nella normativa dell’UE (se si vogliono evitare i dettagli di quest’ultima, si può passare direttamente al paragrafo “cash flow previsionale e castelletti s.b.f.: soluzioni alternative per accedere ai dati del portafoglio“).

La Direttiva PSD2 (“Payment Services Directive 2“) e l’accesso open banking al portafoglio SBF: cosa dice la normativa

La PSD2 si applica ai conti di pagamento, non ai “conti tecnici”. La normativa consente ai clienti delle banche, siano essi privati o imprese, di utilizzare provider terzi autorizzati per gestire i dati e accedere alle informazioni sui propri conti correnti online.

Tuttavia, la PSD2 non ha impatti sugli incassi domestici come MAV, bollettini bancari e Ri.Ba. (si veda Unicredit ). Questa è già una prima esclusione rilevante per il portafoglio SBF, che si basa proprio sulla gestione di Ri.Ba..

Il perimetro della PSD2 riguarda i conti di pagamento; il portafoglio SBF è invece un rapporto tecnico di credito/anticipo, non un conto di pagamento in senso stretto. Per questa ragione le banche italiane possono legittimamente escluderlo dall’accesso open banking PSD2, per i seguenti motivi:

1. natura del rapporto: il portafoglio SBF è una linea di fido e uno strumento di smobilizzo crediti commerciali, non un conto di pagamento. I TPP (Third Party Providers) possono operare direttamente sui conti correnti, previa acquisizione dello specifico consenso dei titolari. Gli istituti finanziari sono tenuti a garantire l’accesso ai TPP tramite apposite API (si rinvia a Mediocredito Centrale ). L’obbligo riguarda i conti di pagamento online (artt. 66-67 PSD2), non i rapporti di credito;

2. esclusioni esplicite della Direttiva: l’art. 3 PSD2 esclude dall’ambito applicativo diverse categorie, tra le quali le operazioni legate alla gestione di crediti commerciali che non costituiscono servizi di pagamento;

3. clienti imprese (non consumatori); il portafoglio SBF è riservato a soggetti diversi dai consumatori. Parte delle tutele PSD2 sono orientate principalmente alla protezione dei consumatori retail. Le imprese hanno spazio contrattuale maggiore per definire le condizioni di accesso;

4. accesso tramite conto corrente, non direttamente: il collegamento tra il portafoglio SBF e il conto corrente significa che un TPP può vedere i movimenti sul conto corrente (accrediti e addebiti legati all’SBF), ma non necessariamente la gestione interna del portafoglio (partite, distinte, scadenze, insoluti) che è un rapporto tecnico separato.

Cosa è invece accessibile via PSD2

La PSD2 regolamenta i servizi di pagamento come bonifici, carte di credito, carte di debito, MAV, RAV, addebiti diretti SDD e conti correnti (si veda Bper ).

Quindi un AISP (“account information service provider“) autorizzato, quale soggetto disciplinato dalla PSD2, potrà vedere sul conto corrente dell’impresa i flussi di cassa generati dall’SBF (accrediti a maturazione, addebiti per insoluti), ma la gestione del portafoglio in quanto tale rimane fuori perimetro.

Più precisamente occorre distinguere 2 piani:

1 — Regole di protezione degli utenti (diritti, rimborsi, trasparenza)

La PSD2 si applica a tutti i servizi di pagamento tra cui bonifici, addebiti diretti, carte di credito, debito e prepagate, portafogli elettronici e altri pagamenti via internet per una sintesi si rinvia a Unicredit ). MAV, RAV e Ri.Ba., intesi come strumenti di incasso sono ricompresi nella disciplina, nel senso che chi li gestisce deve rispettare obblighi di trasparenza e condizioni contrattuali previsti dalla direttiva;

2 — Open Banking (accesso ai conti da parte di TPP)

La PSD2 non ha impatti sugli incassi domestici come MAV, bollettini bancari e Ri.Ba. . Questo si riferisce specificamente all’obbligo di apertura delle API per i TPP: il diritto di accesso open banking riguarda i conti di pagamento online e non si estende ai flussi di incasso domestici o ai rapporti tecnici come il portafoglio SBF.

Pertanto le banche:

• sono tenute a far funzionare MAV e Ri.Ba. secondo le regole PSD2 consentendo l’accesso ai TPP tramite apposite API (ovviamente previo apposito consenso dei titolari;
• non sono obbligate ad esporre tramite API open banking i dettagli del portafoglio SBF ai TPP terzi.

Occorre verificare perciò i relativi contratti con le singole banche, poiché le condizioni contrattuali e le prassi interpretative possono variare da istituto a istituto.

Perché molti portali bancari non hanno PSD2 completo per l’SBF

Come visto sopra, il problema pratico è questo: le API PSD2 standard espongono movimenti e saldo del conto corrente, ma il portafoglio SBF insiste su un rapporto tecnico separato (il “conto anticipi”) che la maggior parte delle banche non espone tramite le API PSD2 obbligatorie. Questo significa che tramite open banking standard si può vedere che “oggi sono stati accreditati € 10.000 da anticipo SBF“, ma non si possono vedere:

• le singole Ri.Ba. presentate nella distinta;
• il castelletto accordato e quanto è utilizzato;
• le scadenze delle singole partite;
• gli insoluti in gestione;
• lo stato (presentato / anticipato / scaduto);

Cash flow previsionale e castelletti s.b.f.: soluzioni alternative per accedere ai dati del portafoglio

Per ottenere questi dati servono quindi le seguenti soluzioni alternative:

Opzione 1 — web scraping del portale home banking

Si accede al portale web della banca simulando la navigazione dell’utente, estraendo i dati dalla sezione “portafoglio SBF” o “anticipo effetti”. È una soluzione tecnicamente fattibile ma con limiti importanti: le banche possono bloccarla in qualsiasi momento, viola spesso i termini di servizio, e richiede manutenzione continua ogni volta che il portale cambia grafica o struttura.

Opzione 2 — API CBI (Corporate Banking Interbancario)

Il CBI (Customer to Business Interaction) è il circuito interbancario italiano che alcune banche espongono per clienti corporate. Tramite il CBI Globe (la piattaforma open banking di CBI) alcune banche offrono API più ricche rispetto alla sola PSD2, includendo dati di portafoglio commerciale. Non è però universale: dipende dalla banca e dal contratto corporate sottoscritto.

Opzione 3 — export manuale strutturato

Questa è la soluzione più robusta per le PMI italiane nella pratica: l’impresa scarica periodicamente dal portale bancario il file con il portafoglio SBF (in formato CSV, Excel o XML SEPA) e lo importa nel sistema di cash flow. Meno automatica, ma affidabile al 100% e indipendente da qualsiasi vincolo tecnologico.

Opzione 4 — integrazione diretta tramite gestionale/ERP

Se il gestionale dell’impresa già dialoga con le banche (es. tramite modulo tesoreria di SAP, Zucchetti, TeamSystem, ecc.), quei flussi possono essere intercettati a livello middleware (cioè tramite applicazione intermedia) senza dover accedere direttamente alle API bancarie.

In sintesi:

Pertanto in presenza di affidamenti bancari per lo smobilizzo del portafoglio commerciale (anticipi fatture e presentazione ri.ba. al salvo buon fine),  l’architettura multi-sorgente di raccolta dei dati per la costruzione di un cash flow previsionale viene pertanto ad essere modificata come segue:

SORGENTI DATI

GESTIONALE     HOME BANKING     EMAIL     CRM /ERP

│
▼

LAYER 1 — DATI CERTI
gestionale / ERP via API
· fatture attive & passive · anagrafica clienti
· scadenzario · prima nota / movimenti

│
▼

LAYER 2 — DATI IN TEMPO REALE
home banking via PSD2
· saldo c/c disponibile · movimenti & estratto conto
· accrediti SBF su c/c · addebiti insoluti su c/c

⚠ portafoglio s.b.f. — fuori perimetro PSD2
canale di accesso alternativo da scegliere:

│
▼
LAYER 3 — DATI ANTICIPATI
Email · CRM · Ordini
· distinte SBF via email · ordini non ancora fatturati
· conferme d’ordine · pipeline vendite CRM
│
▼
LAYER 4 — CORREZIONI MANUALI
input spot · aggiustamenti
· pagamenti non ancora contabilizzati
· proroghe scadenze · override previsioni AI
│
▼
MIDDLEWARE (proprietà cliente)
· raccoglie dati da tutti 4 i layer
· adatta i formati sorgente tramite adapter specifici
· normalizza tutto in formato standard proprietario
· salva nel DB cliente (storico permanente, export aperto)
│
▼
MOTORE IA — CASH-FLOW
· piano previsionale 6 mesi · alert liquidità
· ottimizzatore castelletti · scoring insoluti
· cruscotto unificato · KPI in tempo reale

Questo per quanto attiene le modifiche da apportare alla architettura di raccolta dati per gestire i rapporti tra cash flow previsionale e castelletti s.b.f., vale a direin caso di esistenza di linee di credito per lo smobilizzo del portafoglio commerciale.

Vedremo in successivi passaggi come gestire tramite IA le uscite periodiche (rate di mutuo, noleggio, leasing, salari & stipendi, pagamento imposte e tasse, ecc.) ma soprattutto a che livello gestire vendite e acquisti con un orizzonte temporale che travalica quello degli scadenziari (layer 1) e degli ordini (layer 3); si tratta delle vendite e degli acquisti programmati come da budget.

Come avevamo visto qui , una PMI che intenda implementare un cash flow previsionale, anche attraverso l’utilizzo dell’IA, da un punto di vista pragmatico dovrebbe affrontare 2 fasi:

fase 1: approccio ibrido (vale a dire in parte manuale)

• export manuale settimanale dal gestionale in formato CSV
• input manuale pipeline commerciale
• collegamento home banking via PSD2

fase 2 (dopo circa 3 mesi): automazione progressiva

• se il ritorno dell’investimento è positivo → investire in integrazione API diretta
• se l’utente è soddisfatto del processo manuale → scelta conservativa (mantenimento)

Resta tuttavia un problema di non poco conto: è esperienza comune che nelle PMI il gestionale è assai spesso poco aggiornato.

Solitamente vi sono:

• ritardi di giorni/settimane nell’inserimento dei dati
• fatture non ancora registrate
• scadenze non aggiornate a seguito di accordi informali
• pagamenti effettuati ma non ancora contabilizzati

Come procedere in questi casi ? Occorre progettare una soluzione che poggi su una architettura multi-sorgente , che potrebbe essere configurata così:

LAYER 1: dati certi

(da gestionale via API – automatico)

 ↓

LAYER 2: dati in tempo reale

(da home-banking via PSD2 – automatico)

  ↓

LAYER 3: dati anticipati

(da email/CRM – semi-automatico)

   ↓

LAYER 4: correzioni/integrazioni

(input manuale spot – interfaccia di facile utilizzo)

  ↓

MOTORE IA

Innanzitutto (layer 1) si tratta di recuperare i dati dal Gestionale tramite una API call, per cui occorre stabilire la frequenza di sincronizzazione (ad esempio: ogni notte alle 2:00 AM + on-demand).

Con il secondo passaggio (layer 2: home-Banking PSD2 / Open Banking) è fondamentale per colmare quanto non ancora aggiornato nel gestionale, dal momento che consente di fornire:

• saldo in tempo reale
• movimenti bancari effettivi (incassi/pagamenti già avvenuti)
• valute effettive
• commissioni bancarie

Vantaggi:

• identificazione degli incassi ricevuti non ancora registrati
• identificazione dei pagamenti in uscita non previsti
• verifica saldo reale vs. saldo contabile

Quanto ai dati anticipati (layer 3) occorre un intervento dell’IA su Email/CRM:

• 3A. Mining Email aziendale, via API su – ad esempio – Gmail/Outlook

Vantaggi:

• si intercettano fatture fornitori appena arrivate via email
• non si deve attendere che contabilità le registri
• previsione più accurata dei pagamenti in uscita

• 3B. Integrazione CRM (pipeline vendite)

Perché è cruciale:

• il gestionale ha solo fatture emesse
• il CRM ha vendite future (anche 1-2 mesi prima)
• l’IA può pesare le probabilità di conclusione

• 3C. Email con accordi informali

Il NLP (natural language processing) dell’IA su email permette di identificare dati di linguaggio quali, ad esempio:

• “Vi paghiamo la prossima settimana” → posticipa scadenza
• “Bonifico fatto oggi” → anticipa incasso prima che appaia in banca
• “Possiamo dilazionare in 3 rate?” → modifica piano incasso

Analizzando le email dai clienti si possono quindi  intercettare:

1. impegni di pagamento con data
2. richieste di dilazione
3. conferme di bonifico effettuato

Successivamente è necessario implementare (layer 4) una interfaccia di semplice utilizzo per le correzioni rapide da parte dell’imprenditore / CFO. Casistiche comuni:

Notifica: “Cliente Rossi S.r.l. ha scadenza 5.000 € oggi”

Bottoni rapidi:

[✓ confermato] [→ posticipa 7gg] [✗ non pagherà] [✎ modifica]

oppure:

Alert: “previsione: deficit 15.000 € tra 10 giorni”

Azioni:

[+ aggiungi incasso previsto]

[+ posticipa pagamento fornitore]

[? vedi scenari]

oppure:

l’imprenditore comunica che:

“Il cliente XYZ mi ha detto che paga venerdì prossimo”

→ App trascrivi e aggiorna previsione automaticamente

In conclusione, per somme linee l’architettura di un progetto di cash flow previsionale tarato sulle esigenze di una PMI potrebbe essere la seguente:

GESTIONALE             ────→  HOME BANKING     ────→   GMAIL API

(API notte)                                     (PSD2 live)                                (ogni ora)

└────────────────────┼────────────────────┘

↓

  DATA WAREHOUSE

(PostgreSQL)

↓

RECONCILIATION

ENGINE

[input manuale via web/app]

↓

AI FORECAST ENGINE

↓

    DASHBOARD

(cruscotto aziendale)

Quindi in maggior dettaglio il processo di implementazione raccomandato potrebbe essere il seguente:

fase 1 (4 settimane per arrivare ad un mvp – minimum viable product -, cioè ad una versione di base del prodotto dotata dei requisiti minimi per il funzionamento cosicché possa essere concretamente adottata dagli utenti e raccoglierne i feedbacks per il miglioramento):

• integrazione API gestionale (fatture + scadenzario)
• integrazione home banking PSD2
• dashboard base con saldo previsto

fase 2 (mese 2-3):

• Gmail API per fatture fornitori in arrivo
• CRM sync per pipeline vendite
• App mobile per correzioni rapide

fase 3 (mese 4+):

• NLP avanzato su email
• IA previsione comportamento pagatori
• scenari what-if automatici

Vedremo in seguito l’adattamento dell’architettura appena descritta ad un contesto operativo di tipico ricorso da parte della PMI al credito bancario per lo smobilizzo delle fatture emesse.

Abbiamo visto qui le caratteristiche salienti di un progetto di costruzione di un cash flow previsionale di una PMI.

Continuiamo ora l’esame, analizzando come caricare i dati.

Opzioni di caricamento dei dati aziendali

Opzione 1: integrazione diretta con il gestionale aziendale (soluzione ideale, salvo tipiche situazioni di gestionale non aggiornato, per le quali si rinvia ad un successivo post)

Processo:

• API REST del gestionale (se disponibile)
• estrazione automatica schedulata (es. ogni notte)
• dati prelevati: fatture attive/passive, scadenzario, movimenti contabili

 Esempio di flusso:

Gestionale → API call → database intermedio → script AI → cruscotto

Vantaggi: automatico, dati sempre aggiornati (ma si veda quanto sotto indicato), non vi è spazio per l’errore umano

Svantaggi: richiede un accesso API (non sempre disponibile), setup tecnico più complesso

Opzione 2: export + import semi-automatico (soluzione pragmatica)

Processo:

1. l’utente esporta dal gestionale file standard (CSV/Excel)
2. salva in cartella condivisa (Google Drive/Dropbox) o carica su portale aziendale
3. predisposizione di uno script Python che rileva i nuovo file e li processa automaticamente

File tipici da esportare:

• fatture_attive.csv (cliente, importo, data emissione, scadenza)
• fatture_passive.csv (fornitore, importo, scadenza)
• pagamenti_effettuati.csv (data, importo, beneficiario)
• incassi_effettuati.csv (data, importo, cliente)
• estratto_conto.csv (movimenti bancari)

Esempio di template CSV:

csv

data_fattura,numero_fattura,cliente,importo,scadenza,stato_pagamento

2025-01-15,FT001,Cliente ABC SpA,10000,2025-02-15,da incassare

2025-01-20,FT002,Cliente XYZ Srl,5500,2025-03-20,da incassare

…

Vantaggi: semplice, funziona con qualsiasi gestionale, l’utente mantiene il controllo

Svantaggi: richiede una azione manuale periodica (settimanale/mensile)

Opzione 3: import da home banking (complementare)

Processo:

– collegamento API PSD2 (Open Banking)

– oppure export manuale estratti conto in formato standard

Utilizzo:

– riconciliazione automatica incassi/pagamenti effettivi

– aggiornamento saldo reale vs. previsionale

– training del modello su comportamenti reali

Opzione 4: input manuale selettivo (soluzione ibrida)

Questa opzione è relativa ai dati che cambiano raramente o sono strategici:

Processo:

costruzione di una interfaccia web semplice per inserire:

– nuovi contratti ricorrenti

– grandi commesse in pipeline

– spese straordinarie pianificate

– investimenti previsti

Costruzione di un cash flow previsionale di una PMI

Una raccomandazione pratica per una PMI sia quella di adottare un processo che si sviluppi attraverso le seguenti fasi:

fase 1 (mesi 1-3): approccio “ibrido”

• export manuale settimanale CSV dal gestionale
• input manuale pipeline commerciale
• collegamento home banking via PSD2

fase 2 (dopo 3 mesi): automazione progressiva

• se il ROI (inteso come ritorno dell’investimento tramite una migliore gestione della liquidità) è positivo → investire in integrazione API diretta
• se l’utente soddisfatto del processo manuale → mantenerlo così

In un successivo post approfondiremo l’opzione 1, ovverosia l’integrazione con il gestionale aziendale, probabilmente la soluzione più scalabile.

Proseguiamo quanto introdotto nel precedente post Cash-flow previsionale aziendale e intelligenza artificiale 

Quali sono le opzioni tra le quali può scegliere una PMI che voglia implementare un cash flow previsionale utilizzando sistemi di business intelligence e IA?

Premettiamo che quanto verrà esposto di seguito è svolto solo a meri fini illustrativi, potendo variare in base alle dimensioni dell’impresa, all’organizzazione, all’infrastruttura e alle competenze tecnologiche presenti, al settore di attività, alla tipologia di produzione (in serie, per lotti, su commessa, ecc.) o di servizi erogati, ecc..

Innanzitutto per caricare i dati necessari alla costruzione di un piano di cassa si presentano 2 opzioni:

• opzione 1: integrazione diretta con gestionale
• opzione 2: export + import semi-automatico 

Opzione 1: API REST + estrazione automatica

Con la prima opzione il metodo è il seguente:

• API REST del gestionale (se disponibile); l’API è un set di regole che consente a programmi diversi di comunicare tra loro; l’API REST fornisce un modo standard alle applicazioni web di comunicare tra loro tramite internet
• estrazione automatica schedulata (es. ogni notte)
• dati prelevati: fatture attive/passive, scadenzario, movimenti contabili e altri

Esempio flusso:

Gestionale → API call → database intermedio → script AI → dashboard (cruscotto aziendale)

Vantaggi: automatico, dati sempre aggiornati (se il gestionale ha dati aggiornati), errore umano assente

Svantaggi: richiede un accesso API (non sempre disponibile), set-up tecnico più complesso.

Opzione 2: export + import semi-automatico

Invece con l’opzione 2 (export + import semi-automatico) il processo è il seguente:

1. l’utente esporta dal gestionale file standard (CSV/Excel)
2. salva in cartella condivisa (Google Drive/Dropbox) o carica su portale
3. uno specifico script in codice rileva il nuovo file (o i nuovi file)  e lo/li processa automaticamente

File tipici da esportare (esempio):

• fatture_attive.csv (cliente, importo, data emissione, scadenza)
• fatture_passive.csv (fornitore, importo, scadenza)
• pagamenti_effettuati.csv (data, importo, beneficiario)
• incassi_effettuati.csv (data, importo, cliente)
• estratto_conto.csv (movimenti bancari)

Vantaggi: semplice, funziona con qualsiasi gestionale, l’utente mantiene il controllo

Svantaggi: richiede una azione manuale periodica (settimanale/mensile)

Oltre ad una delle precedenti opzioni se ne devono poi contemplare altre due.

Opzione 3: import da home banking

Tale opzione è complementare.

Metodo:

– collegamento API PSD2 (open banking)

– oppure export manuale estratti conto in formato standard

Utilizzo:

– riconciliazione automatica incassi/pagamenti effettivi

– aggiornamento saldo reale vs. previsionale

– training del modello su comportamenti reali

Opzione 4: input manuale selettivo

E’ da prevedere altresì una quarta opzione che prevede un input manuale selettivo (soluzione ibrida), per dati che cambiano raramente o sono strategici, al fine di creare una interfaccia web semplice per inserire:

– nuovi contratti ricorrenti

– grandi commesse in pipeline

– spese straordinarie pianificate

– investimenti previsti

Un esempio di schermata di interfaccia potrebbe essere il seguente:

“`

Nuovo incasso previsto:

Cliente: [dropdown]

Importo: [____] €

Data prevista: [calendario]

Probabilità: ○ 30% ○ 60% ● 90%

Ricorrente: □ Sì

“`

Vedremo successivamente qui quale potrebbe essere una architettura dati consigliata per le PMI.

Introduzione

Implementare un cash flow previsionale per la gestione della tesoreria aziendale con il supporto dell’intelligenza artificiale (IA) comporta innanzitutto un approccio strategico, che di massima dovrebbe contemplare i seguenti punti:

1. analisi dei dati storici: per prima cosa occorre raccogliere i dati storici dei flussi di cassa (quali, ad es., per clienti e fornitori: incassi, pagamenti, fatture emesse/ricevute, scadenze, stagionalità); l’IA può identificare pattern ricorrenti e anomalie che influenzano la liquidità;
2. sviluppo di un modello predittivo personalizzato che consideri:

• • tempi medi di incasso per cliente/settore;
  • ritardi storici nei pagamenti;
  • eventuale stagionalità del business;
  • contratti ricorrenti o episodici;
  • variabili macroeconomiche (se rilevanti);

3. automazione e integrazione: si procede a integrare il sistema con i gestionali aziendali (fatturazione, contabilità, ecc.) per aggiornare automaticamente le previsioni quando arrivano nuovi dati;
4. scenari what-if: l’IA può generare scenari multipli (ottimistico, realistico, pessimistico) e simulare l’impatto di decisioni specifiche sulla liquidità futura;
5. alert intelligenti: sarebbe appropriato progettare un sistema di notifiche che avvisi quando la previsione mostra criticità di liquidità o opportunità di investimento.

Qualora si consideri una PMI, il progetto di costruzione di un cash-flow previsionale deve essere quanto più possibile snello e sostenibile.

Fasi di costruzione di un cash flow previsionale

La costruzione prevede le seguenti fasi:

Fase 1: mappatura e raccolta dati (2-3 settimane)

Dati essenziali da raccogliere:

• estratti conto bancari, distinte presentazione effetti e insoluti, ultimi 12-24 mesi
• fatture attive/passive e relative scadenze
• storico incassi e pagamenti effettivi
• contratti ricorrenti e loro condizioni
• budget annuali (se esistono)
• ciclo operativo specifico del settore

Interviste con:

• amministrazione/CFO per capire criticità attuali
• commerciale per pipeline vendite
• acquisti per impegni pianificati

Fase 2: modellazione di base (3-4 settimane)

Modello di cassa previsionale con:

• saldo iniziale
• incassi previsti (da fatture emesse + nuove vendite attese)
• pagamenti previsti (fornitori, stipendi, tasse, rate)
• saldo finale giornaliero/settimanale/mensile

Logica IA applicata:

• calcolo dei giorni medi di incasso per cliente/categoria
• identificazione degli andamenti stagionali
• previsione probabilità di ritardo nei pagamenti
• stima degli incassi da flusso vendite

Fase 3: implementazione tecnica

L’architettura tecnica dovrebbe prevedere:

frontend: Excel/Google Sheets (familiarità delle PMI con tali strumenti)

↓

layer IA: scrittura di codice che:

– legge dati da gestionale/CSV

– applica modelli predittivi

– aggiorna automaticamente il template

↓

dashboard (cruscotto): tipicamente tramite Power BI

Fase 4: validazione e calibrazione (2-3 settimane)

• confronto previsioni vs. realtà su dati storici (backtesting)
• aggiustamento parametri per ridurre errore
• test con utenti finali

Fase 5: messa in opera e addestramento

Output finali dell’elaborazione di un sistema di cash flow previsionale

All’esito della implementazione di un sistema di elaborazione di un cash flow previsionale si dovrebbero ottenere:

1. tool automatizzato che genera previsioni settimanali/mensili
2. cruscotto con KPI chiave (saldo minimo previsto, giorni di copertura, alert criticità)
3. simulatore di scenario per testare decisioni (“cosa succede se ritardo questo pagamento?”)
4. report automatico da inviare via email

Formazione team cliente

La formazione dovrebbe avere i seguenti focus:

• come interpretare le previsioni
• come aggiornare assunzioni manualmente
• come usare gli scenari “what-if”

Governance continuativa

La governance dovrebbe essere sviluppata come segue:

• primo mese: monitoraggio settimanale precisione
• trimestrale: revisione modello e ricalibrazione
• annuale: upgrade con nuove funzionalità

In uno o più successivi post vedremo con maggiore dettaglio opzioni e architetture per implementare un cruscotto aziendale al fine di elaborare un cash-flow previsionale su base continuativa, con specifico riguardo alle PMI.

Con il principio contabile internazionale IFRS 18 (“Presentation and disclosure in financial statements”), che entrerà in vigore il 1° gennaio 2027, si apportano alcune novità con le quali, pur non andandosi ad incidere sui criteri di valutazione, si punta ad una maggiore comparabilità dei bilanci al fine di favorirne la trasparenza per quanto attiene la presentazione dei risultati economico-finanziari.

In estrema sintesi, gli aspetti fondamentali sono i seguenti:

Struttura del conto economico

L’IFRS 18 richiede che tutte le società classifichino i ricavi e i costi in cinque categorie obbligatorie:

1. gestione operativa: Include tutte le attività che non rientrano nelle altre categorie – sostanzialmente la gestione caratteristica dell’impresa;
2. investimenti: ricavi e costi da investimenti in “cash”, “cash equivalents” e altri asset che generano ritorni individualmente e largamente indipendenti dalle altre risorse dell’azienda
3. finanziamento: ricavi e costi da passività finanziarie, strumenti di equity e attività finanziarie che nascono da transazioni di finanziamento;
4. imposte sul reddito: categoria separata per le imposte;
5. attività cessate, ove applicabile.

Subtotali obbligatori

L’IFRS 18 introduce, prima dell’indicazione dell’utile o della perdita, due subtotali obbligatori che tutte le società devono presentare:

1. utile/perdita operativa: è il risultato della categoria operativa; questo è il subtotale più significativo e innovativo, perché prima non esisteva una definizione standardizzata;
2. utile o perdita prima dell’attività di finanziamento e delle imposte sul reddito: include l’utile/perdita operativa più il risultato della gestione degli investimenti.

Questi subtotali devono essere presentati con pari evidenza nel conto economico e non possono essere modificati o rinominati.

Requisiti di disclosure per le Management-Defined Performance Measures (MPM)

Le “MPM” sono misure di performance definite dal management che:

• comunicano la visione del management sulla performance dell’impresa;
• integrano (subtotali) o modificano (attraverso aggiustamenti) misure IFRS;
• sono comunicate pubblicamente al di fuori del bilancio (es. comunicati stampa, presentazioni agli investitori).

Sono esempi comuni di MPM:

• EBITDA “adjusted”;
• utile operativo rettificato;
• free cash-flow;
• risultato netto normalizzato.

MPM, IFRS 18 e comparabilità dei bilanci

Onde evitare che le società utilizzino queste misure alternative di rendicontazione dei risultati economico-finanziari (“MPM”) in modo fuorviante o poco trasparente, al fine di agevolare gli investitori nella comprensione di come esse si ricolleghino ai dati ufficiali del bilancio, vengono richiesti i seguenti requisiti:

• riconciliazione: occorre una tabella che riconcili ogni MPM con il subtotale IFRS più direttamente comparabile, mostrando tutti gli aggiustamenti effettuati;
• spiegazione: è necessaria una descrizione chiara di come la MPM viene calcolata e perché il management ritiene che fornisca informazioni utili sulla performance;
• etichetta chiara: occorre assegnare un nome che rifletta accuratamente il contenuto della misura;
• effetto fiscale: per ogni aggiustamento significativo, occorre indicare l’effetto fiscale se rilevante

La direttiva attualmente in vigore

La direttiva 2011/17 sul contrasto ai ritardi nei pagamenti è stata adottata oltre un decennio fa. L’obiettivo della stessa è l’accelerazione dei pagamenti delle fatture nelle transazioni tra imprese, e quindi la protezione in particolare delle piccole e medie imprese (PMI) da situazioni in cui attendere troppo a lungo per il pagamento di una fattura potrebbe avere un impatto negativo sul loro flusso di cassa.

Il ritardo nell’incasso dei crediti commerciali costituisce ancora oggi, in tutta l’U.E., uno dei principali motivi di fallimento delle PMI.

In base alle norme attualmente in vigore, le imprese devono pagare le fatture entro un massimo di 60 giorni. Viene fatto salvo quanto diversamente concordato espressamente nel contratto, a condizione che i termini non siano gravemente iniqui per il creditore.

La Pubblica Amministrazione deve pagare i beni acquistati e i servizi ricevuti 30 giorni. Vi sono alcune eccezioni in particolare per il settore sanitario, per il quale può essere applicata una scadenza di 60 giorni.

I creditori che hanno adempiuto ai propri obblighi legali e contrattuali e che non sono stati pagati entro i termini specificati hanno diritto agli interessi di mora e al risarcimento per il ritardo di pagamento.

La direttiva specifica che gli interessi sui ritardi di pagamento devono essere almeno di 8 punti percentuali superiori al tasso di riferimento della Banca centrale europea (BCE).

I lavori della Commissione europea

Nell’ottobre 2022, la Commissione europea aveva incluso nel suo programma di lavoro per il 2023 una proposta legislativa per la revisione della direttiva sui ritardi di pagamento.

Il 12 settembre 2023, nel contesto di una serie di iniziative per rispondere alle esigenze delle PMI europee (pacchetto di aiuti alle PMI), la Commissione europea ha pubblicato la proposta annunciata. Le nuove norme abrogherebbero la direttiva del 2011 sui ritardi di pagamento e la sostituirebbero con un regolamento.

Il regolamento, a differenza delle direttive che devono essere recepite con apposite legge nei singoli ordinamenti degli Stati membri, produce effetti giuridici immediati e vincolanti per tutti i soggetti operanti nella U.E., sia pubblici che privati.

Cosa prevede la bozza di regolamento sui ritardi nei pagamenti

La bozza del testo della Commissione stabilisce un termine di pagamento massimo più rigoroso di 30 giorni. Ciò sia nelle transazioni business-to-business (B2B) che in quelle “government-to-business” (G2B) (in cui la pubblica amministrazione è il debitore). L’obiettivo è quindi quello di standardizzare i pagamenti puntuali tra imprese e autorità pubbliche.

E’ prevista la possibilità di una maggiore flessibilità previa negoziazione di termini di pagamento fino a 60 giorni di calendario nelle transazioni B2B, purché ciò sia espressamente concordato nel contratto.

I modelli e le pratiche aziendali specifici nel settore della vendita al dettaglio spesso richiedono periodi di pagamento più lunghi. Ciò a causa di fattori come:

• basso turnover dei prodotti;
• la stagionalità o cicli unici per gli articoli (ad . giocattoli, gioielli, attrezzature sportive o libri).

Pertanto sono consentiti in questi casi termini di pagamento fino a 120 giorni.

Per mantenere la coerenza nelle pratiche di pagamento nel mercato unico, la Commissione dovrebbe emanare linee guida sull’applicazione di queste norme alle categorie di prodotti specificate.

Al fine di proteggere le aziende, in particolare le PMI, dai cattivi pagatori e garantire la tempestiva ricezione dei pagamenti per evitare interruzioni del flusso di cassa, il testo adottato prevede un pagamento automatico degli interessi di mora maturati. Inoltre il debitore dovrà rifondere tra 50 e 150 euro per ogni transazione (a seconda del valore) a titolo di compensazione dei costi di recupero sostenuti dal creditore.

Secondo la bozza di regolamento gli Stati membri saranno tenuti a nominare autorità nazionali con il compito di applicare il regolamento e con poteri di indagine e sanzionatori.

A che punto è l’iter di approvazione di regolamento sui ritardi nei pagamenti

La proposta della Commissione di regolamento sui ritardi nei pagamenti è tuttavia bloccata ormai da mesi sui tavoli di lavoro del Consiglio dei ministri dell’Unione.

L’iter legislativo, iniziato lo scorso settembre con la presentazione del testo proposto dalla Commissione. Esso aveva raggiunto una tappa fondamentale ad aprile 2024, quando il Parlamento europeo si era espresso favorevolmente con larga maggioranza.

Nel frattempo, invece, le discussioni tra gli Stati membri al Consiglio dell’Unione europea non hanno ancora condotto ad alcun risultato.

Introduzione

Nel 2020 vengono emanati dall’Autorità Bancaria Europea gli “Orientamenti in materia di concessione e monitoraggio dei prestiti”[1] .

Essi costituiscono il complessivo contesto operativo al quale le banche devono attenersi[2] in sede di valutazione del merito creditizio, di concessione e di monitoraggio dei prestiti.

Più precisamente essi dettano regole per la tracciabilità storica del processo creditizio:

• sin dall’origine dello stesso in sede di valutazione del merito e di concessione dell’affidamento (“origination”);
• e poi in costanza del rapporto (“monitoring”),

al fine di migliorare le prassi di affidamento bancario.

In tal senso esse dettano regole:

• non solo in merito alle procedure interne alle banche,
• ma pure circa le informazioni esterne che le banche devono raccogliere dalle imprese affidate o che chiedono di essere affidate.

Quali sono le novità

Queste, in estrema sintesi, alcune tra le principali novità:

• quanto alla valutazione del merito creditizio:
  • non è più fondata sui dati storici rinvenienti dai bilanci e dalle situazioni infrannuali;
  • diventano prioritari i dati previsionali e in primis quelli di natura finanziaria;
  • ciò attraverso adeguati indici volti a catturare la verosimile capacità di rimborso degli affidamenti, su un orizzonte temporale adeguato, coerente con la durata di questi;
• ancora prima la banca deve raccogliere dall’impresa-cliente informazioni di tipo qualitativo che risaltino:
  • la messa in opera degli adeguati assetti e quindi l’organizzazione dell’impresa (organigramma, poteri, deleghe, funzioni, procedura);
  • che tali assetti si articolino in strumenti e procedure che ancor prima dell’andamento previsionale dell’impresa, diano evidenza:
    • della strategia della stessa;
    • dell’associato business model;
    • della relazione tra questi e i flussi di cassa;
    • definendo i rischi aziendali, di settore e del contesto macroeconomico[3];
• in questo modo acquistano rilevanza le risultanze delle analisi di scenario in termini di effetti di variazioni delle condizioni macroeconomiche e ambientali sul merito creditizio;
• vengono introdotti i fattori ESG di prestazione ambientale, sociale e di governance che quindi avranno sempre più rilievo nei processi di erogazione e monitoraggio del credito[4] ;
• vengono introdotti ben 22 indicatori di monitoraggio del rischio in ottica previsionale.

[1] EBA, “Final Report – Guidelines on loan origination and monitoring” (in www.eba.europa.eu/sites/ default/ documents/files/ document_library/Publications). Tali orientamenti sono entrati in vigore:

• il 30 giugno 2021 per i prestiti erogati da tale data;
• il 30 giugno 2022 per i prestiti oggetto di rinegoziazione.

Il 30 giugno 2023 entreranno in vigore i principi attinenti al monitoraggio del credito.

[2] In realtà le banche non sono obbligate ad uniformarsi a detti orientamenti, valendo tuttavia il principio “comply or explain”, dovendo gli scostamenti essere motivati e circostanziati.

[3] A tal fine la banca deve verificare la coerenza tra il profilo di rischio (in termini di business model, strategia e flussi di cassa) dell’impresa affidata/da affidare e il risk appetite della banca stessa.

[4] Al momento per le micro e le piccole imprese la valutazione dell’impatto dei fattori ESG può anche essere condotta a livello di portafoglio, mentre per gli affidamenti associati a livello di maggiore rischio dell’impatto dei fattori ESG è richiesta una analisi più approfondita del business model.

Nel 2017 con l’ introduzione per le banche del principio contabile internazionale IFRS9 (“Strumenti finanziari”), nella valutazione del merito creditizio (e quindi della solvibilità del cliente) queste sono passate da una valutazione a posteriori ad una valutazione prospettica del deterioramento creditizio (la cosiddetta ottica “forward-looking”).

In tal modo i crediti vengono classificati ai fini della valutazione delle perdite durevoli (e dei conseguenti accantonamenti) in 3 classi (“stages”) in funzione del rischio di credito del cliente:

• stage 1 (credito “performing”), che comprende gli strumenti finanziari soggetti a basso rischio o ad un aumento del rischio di credito non significativo;
• stage 2 (credito “underperforming”), al verificarsi di un significativo deterioramento del merito creditizio, che pertanto rappresenta una vera e propria allerta per la banca; tale deterioramento si presume qualora lo strumento sia scaduto da 30 giorni o più.

Questi 2 stages rappresentano i crediti “in bonis”, quindi non deteriorati. Si vuole tuttavia evidenziare che nello stage 2 sono inclusi pure i crediti oggetto di concessione o di rinegoziazione. Si badi che determinati eventi comportano la riclassificazione di un credito da stage 1 a “underperforming” (stage 2), quali a titolo di esempio:

• moratorie o sospensione per un periodo non inferiore a 6 mesi nel pagamento di rate di un mutuo;
• allungamento del piano di ammortamento di un mutuo;
• presenza di pregiudizievoli (protesti, pignoramenti, iscrizione di ipoteche giudiziali, sequestri, altri atti esecutivi o cautelari disposti dal Tribunale, iscrizione di ipoteche legali da parte dello Stato o dell’Agenzia delle Entrate);
• deposito di istanza per l’accesso alla composizione negoziata della crisi o a strumenti per la regolazione della crisi o dell’insolvenza;
• significativa riduzione del patrimonio netto o patrimonio netto negativo;
• elevato incremento del rapporto di indebitamento;
• DSCR non sostenibile;
• peggioramento del rating a seguito di pubblicazione del nuovo bilancio;
• parere negativo o riserve da parte dell’organo di controllo in sede di relazione al bilancio o mancata certificazione;
• variazione della forma giuridica che comporti la decadenza dell’organo di controllo.

• stage 3 (credito “non performing”), allorché vi siano oggettive evidenze di impairment; questo stage coincide con i crediti deteriorati e in esso è inclusa la clientela cosiddetta “UTP” (“unlikely to pay”); in questo caso la perdita viene calcolata con riferimento all’intera durata residua dello strumento (come per lo stage 2), ma analiticamente per ogni posizione. Gli interessi vengono calcolati scontando i flussi netti (anziché lordi, come negli stages 1 e 2) dell’esposizione per il tasso di interesse effettivo.

Per i crediti in stage 1 la banca valuta le perdite attese su un orizzonte temporale di 12 mesi, mentre per quelli in stage 2 e 3 tale valutazione si estende per l’intera durata (residua) dell’attività, anche in considerazione degli scenari macroeconomici e settoriali previsti.

Alla banca viene perciò richiesta una valutazione del merito creditizio previsionale, al fine di adeguare tempestivamente il valore dei crediti in funzione del peggioramento del rischio di credito. Ogni variazione (anche positiva) nelle perdite attese al momento della rilevazione iniziale (o precedente) va imputata a conto economico.

Pertanto non viene più richiesto il concreto manifestarsi di un evento negativo, essendo sufficiente un significativo incremento del rischio (secondo il principio che non si deve più attendere la concreta manifestazione della perdita, ma prevederla al fine di poterla gestire in modo proattivo).

Se Vi interessano chiarimenti e approfondimenti circa la valutazione del merito creditizio, scoprite il nostro servizio di Consulente in finanza aziendale – Venezia .