Esiti-SDD

ESITI SDD

Il continuo controllo degli Esiti SDD facilita la gestione degli Incassi, la contabilità e non ultimo la solidità finanziaria dell’Azienda.

Abbiamo spiegato la validità del prodotto di incasso SDD in altri articoli.
La sicurezza del prodotto, il fatto che il pagamento sia un’azione passiva per il debitore, la precisione della scadenza, sono tutti fattori che fanno preferire questo sistema di incasso su altri.
Ma come ogni altro prodotto, occorre seguire attentamente quella che è l’evoluzione del pagamento.
Al contrario di altri sistemi per i quali una volta avvenuto l’incasso la transazione può essere considerata chiusa, per la particolarità del prodotto in alcuni casi non è così precisa.

Particolarità dei mandati

Come detto possiamo emettere SDD nei confronti di due tipologie di mandati: B2B o CORE.
Se i mandati B2B salvaguardano più l’Azienda Creditrice, in quanto a fronte dell’operazione c’è un rapporto commerciale continuo e quindi non è previsto la richiesta di storno, nel caso dei mandati CORE il debitore può richiedere il riaccredito in qualsiasi momento entro le 8 settimane successive l’incasso.
Cioè per quasi 2 mesi dobbiamo tenere alta l’attenzione perché potremmo ricevere una richiesta di riaccredito alla quale non possiamo opporci.
Questa è la salvaguardia che viene concessa ai Clienti non merchant dalle norme SEPA al fine di considerare il prodotto SDD finanziariamente sicuro da parte del Debitore che sottoscrive il mandato.
Senza questa salvaguardia difficilmente l’SDD sarebbe accettato dalla comunità come sistema di pagamento.
Ricordo che questo è l’unico mezzo con cui una Società può addebitare il conto corrente di un suo Cliente, senza ogni volta richiedere una autorizzazione specifica.

Perché degli insoluti

Fissati i concetti che gestiscono l’SDD andiamo ad analizzare i principali motivi che possono creare insoluti.
Tutti i mancati pagamenti sono riepilogati in macro operazioni dette R-Transaction che motivano casi di insoluto.
Diciamo che i motivi principali sono ancora meno e riepilogabili in:

– Mandato non regolare o non preso in carico dalla Banca del Debitore
– Errore formale dei dati contenuti nel flusso
– Mancanza di fondi del Cliente Debitore o conto corrente non addebitabile
– Richiesta di storno richiesto dal Debitore

Le R-Transaction determinano i tempi di creazione dell’insoluto e i soggetti che lo determinano partendo dalla presentazione del flusso.

Accertato quindi la motivazione del mancato accredito dobbiamo andare ad analizzare se l’incasso è giusto e in tal caso come correggere l’eventuale errore o quale azione da iniziare nei confronti del Debitore insolvente in tempi celeri.

Riprendiamo il processo

Togliamo i casi di Revocation, Request-for-cancellation e Reversals che sono generati da parte del Creditore, quindi voluti, abbiamo nell’ordine:

Prima della data di scadenza e di cui avremo notizia prima della scadenza:

– REJECTS BEFORE AUTHORIZATION, emesso da parte della Banca del Creditore che ha preso in carico il flusso e la motivazione è tecnica tipo IBAN o BIC errato, portafoglio non autorizzato, flusso non regolarmente compilato etc…

– REJECTS AFTER AUTHORIZATION, viene emesso da parte della Banca del Debitore e qui le motivazioni sono molteplici tra cui il Mandato non è stato registrato, Iban non regolarmente intestato, il conto non può accettare SDD, conto a firme congiunte etc…

– REFUSAL, emesso dal Debitore che chiede alla sua Banca di non accettare quel particolare pagamento.

Arriviamo così alla data di scadenza:

– RETURNS, emesso dalla Banca del Debitore per mancato addebito per manca fondi, conto bloccato o estinto etc… I tempi di risposta sono entro i 2 giorni successivi la scadenza per i mandati B2B e 5 giorni per quelli CORE.

Passati i 5 giorni fatidici possiamo avere:

– REFUNDS, con il quale il Debitore di un mandato CORE chiede alla sua Banca il riaccredito dell’operazione

– RFUT, richiesta da parte di qualsiasi Debitore entro i 13 mesi successivi l’addebito se non ha mai autorizzato il Creditore con la firma di un mandato.

Capite che le molteplicità sono varie, anche se alcune proprio rare.

La contabilità SDD

Vediamo adesso come viene gestita la contabilità e non prendo volutamente in considerazione eventuali anticipazioni, giusto per rendere più semplice la spiegazione del processo.
Il Creditore, forte dei mandati firmati dai suoi Debitori emette un flusso XML di SDD e lo presenta tramite Home/Remote Banking alla sua Banca.

La Banca del Creditore analizza il flusso e può caricare su un conto di servizio tutto importo, oppure scarta le operazioni Reject before authorization e carica solo la differenza. Questo a volte genera della confusione e alcune Banche effettuano operazioni dette di Gross Booking e cioè fanno passare sul conto speciale in avere l’importo del flusso e in dare gli scarti.

A questo punto la distinta viene girata a sistema e sventagliata su tutte le Banche dei Debitori.

Le Banche dei Debitori ritornano subito le Reject after authorization e la Banca del Debitore addebita il conto speciale.

Arriviamo così alla scadenza e la Banca del Creditore gira l’importo a saldo della partita dal conto speciale al conto ordinario.

Nei 2 giorni successivi per i mandati B2B e nei 5 per i mandati CORE arrivano indietro i Returns che andranno ad addebitare il conto ordinario.

Per i mandati CORE poi per 8 settimane possono tornare dei Refunds e per 13 mesi i rarissimi R-FUT ed entrambi finiranno sul conto ordinario.

Informazioni dalle Banche

Un aspetto molto importante per il controllo degli insoluti è vedere come la Banca del Debitore restituisce i dati di tali operazioni.
Alcune comunicano i dati della distinta (Msg-Id) di presentazione e poi numero e totale degli insoluti.
Capire poi chi effettivamente è il Debitore e quale operazione ha generato l’insoluto sta a noi cercarlo.
Diverse Banche concedono la possibilità di fornire estratti conto detti “parlanti”. Tale modalità prevede l’addebito unitario sia sul conto speciale che sul conto ordinario degli insoluti.
Nello specifico viene inserito nella causale dell’operazione sia l’Msg-Id del flusso, che l’End to End (E2E) che specifica l’operazione del flusso, il nome del Debitore e altri dati esplicativi.
Ovvio che questa metodologia di informazione è scelta a seconda del numero di operazioni.
I grandi “bollettatori” che emettono migliaia di addebiti giornalieri preferiscono gli addebiti cumulativi e la ricerca dello specifico da effettuarsi sui flussi XML di ritorno.

Dove controllare gli insoluti

Se le presentazioni di SDD sono raggruppate a livello di distinte, gli esiti possono seguire i dettagli delle distinte, oppure essere riepilogati in specifici elenchi all’interno degli Home/Remote Banking. Ovvio che il controllo diretto in distinta o dalla lista è da considerare fattibile a seconda del numero delle operazioni. Più è grande questo numero e più necessitiamo di flussi specifici.

A tal proposito il sistema interbancario risponde ai flussi XML di presentazione con flussi XML di Esiti SDD.

Nel flusso di ritorno notiamo, anche se conformi alle regole imposte dal Consorzio CBI, comportamenti non omogenei da parte delle Banche. 

Di regola ogni giorno la Banca dovrebbe fornirmi un file per ogni distinta presentata. Questo va bene per i piccoli/medi Creditori che magari fanno una presentazione raggruppata, in un unico invio mensile. Se prendiamo però un grosso Creditore, che invia migliaia di operazioni, magari con più presentazioni al giorno, il ricevere per ogni giorno un file di esiti per ogni distinta, nel tempo può generare la creazione di centinaia di file che poi devono essere gestiti singolarmente.

Altre Banche, magari che gestiscono anche Clienti più grandi, forniscono un unico file giornaliero che all’interno contiene più distinte.

Ecco che questa differenza genera comportamenti differenziati anche da parte di chi deve gestire i dati.

Presupposto che magari i dati una volta scaricati vengono dati in pasto a grossi programmi di Tesoreria che gestiscono il tutto, resta la possibilità che la piccola Azienda voglia vedere in chiaro questi flussi. Quindi come fare?

Leggere un file XML

Se volete leggere il file in modo “abbastanza” umanizzato basta aprirlo con un browser (Chrome, IExplorer etc…); se invece lo volete strutturato consiglio di aprirlo con Excel. Ecco i passaggi:

• Scaricate il flusso dalla Banca
• Con il tasto destro scegliete Apri con
• Scegliete dall’Elenco Excel o cercatelo la prima volta nella lista dei Programmi
• Apparirà la seguente scelta: 
• Lasciate Tabella XML e date OK
• Se il sistema non ha un Mapping XML interno già precaricato (ed è normale) apparirà:
• Date OK
• Otterrete una tabella dove come nomi colonne ci saranno i tag e sotto i dati raggruppati.
• Ecco un esempio di causali di Esiti SDD:

In questo caso abbiamo in colonna Vil codice dell’insoluto, in colonna W il codice R-Transaction, in X l’importo etc.. 

Ovvio che avremo altre colonne significative con il nome debitore, l’iban di addebito, l’End to End che specifica l’operazione e tutti gli altri dati necessari al riconoscimento dell’operazione.

Codici Insoluti

I codici degli insoluti a livello Paesi SEPA li potete recuperare dall’articolo: SDD Codici Esito