Nell’ambito del sistema di pagamenti verso la pubblica amministrazione, pagoPA, la riconciliazione ha ancora questioni non risolte, a quanto risulta dalla mia esperienza.
La riconciliazione in pagoPA si traduce nella possibilità di verificare che il flusso bancario corrisponda al rendicontato, ovvero verificare che i “soldi in banca” e il dichiarato nella rendicontazione (flusso informatico del nodo dei pagamenti) corrispondano. In tale modo si risolve “il dilemma del ragioniere” che teme sempre che quanto affermato dal flusso informatico (rendicontazione) non corrisponda a quanto incassato (provvisorio), detto anche “mancanza di trust” culturale verso il nodo dei pagamenti (che nel tempo dovrebbe svanire).
Come viene risolto manualmente il dilemma?
Il ragioniere riceve il provvisorio per 20 euro che si riferisce al pagamento di Andrea Tironi per il rinnovo della Carta di Identità Elettronica e grazie all’Id del flusso di rendicontazione nella causale del provvisorio associa il corrispondente flusso di rendicontazione. A questo punto fa la reversale, i soldi vengono “accettati” il giro si chiude.
Come spiegato nell’articolo precedente, questo va bene per un numero mediamente basso di transazioni, diventa difficile per un numero alto di transazioni per la mole di lavoro richiesta.
Anche per numeri relativamente bassi, è chiaro che nel mondo della tecnologia e delle integrazioni, la prima cosa che viene da pensare è: come automatizzare questo meccanismo in modo da liberare tempo al ragioniere e permettergli di fare solo i controlli delle anomalie, mettere solo una spunta per l’ok senza saltare da un sito all’altro (o da un foglio excel all’altro, o da un a3 di carta all’altro) e fare cose a più alto valore aggiunto?
In fondo si tratta di un semplice matching di codici e valori, niente altro. Le possibilità sono due.
La riconciliazione a livello di partner tecnologico
La riconciliazione viene fatta a livello di partner tecnologico, che chiama le API (servizi) della banca, legge il giornale di cassa (mediante OPI), dentro il giornale di cassa trova i provvisori, li processa dividendoli per servizio e quindi fornisce un report al ragioniere che dà come risultato:
Servizio 1: totale euro
provvisorio1 valore euro1 id rendicontazione1
provvisorio2 valore euro2 id rendicontazione2
servizio 2: totale euro
provvisorio50 valoreeuro50 id rendicontazione50
eccetera
Anomalie
elenco anomalie.
doppioni
Elenco doppioni (in caso di OPI ricaricati nuovamente)
Questo permette al ragioniere di avere un processing automatico che riassume per servizio quanto viene incassato. E quindi tutta la fase di verifica del matching tra rendicontato e banca viene fatta in automatico.
Lo svantaggio è che al ragioniere rimane la parte in cui una volta visti i totali deve inserirli nelle corrette voci del bilancio del software di ragioneria, in modo da avere il lavoro completato. E quindi fare le reversali.
Come risolvere questo: sempre con l’integrazione. Integrando il software della contabilità in modo che possa leggere le pratiche e quindi in base al fatto che il flag “riconciliato” dice “si” e al codice di riconciliazione indicato, ogni notte (o in periodicamente) inserire le voci nei giusti conti contabili.
Il vantaggio è che questo meccanismo, pure risolvendo parzialmente il problema dell’automatizzazione, vale per tutti i servizi dell’ente appoggiati al PT, anche quelli che non hanno software verticali gestionali (es.diritti di Segreteria, riscossione pagamento CIE).
La riconciliazione a livello di software di contabilità
L’altro livello a cui si può fare la riconciliazione è quello di importare gli OPI direttamente nel software di contabilità. Questo permette nel software di vedere i provvisori e quindi inserire i dati direttamente sulle corrette voci di bilancio una volta dato l’ok da parte del ragioniere.
Ci dovrà comunque essere una comunicazione/integrazione con il software del PT per la gestione delle rendicontazioni, in modo da fare il matching tra OPI e rendicontato.
Inoltre, il software del PT dovrà comunque continuare a parlare con un eventuale verticale esterno (es. software della Mensa) per ricevere le pratiche da pagare e potrebbe essere necessaria un’integrazione del verticale anche verso il software della Contabilità per uno scambio di informazioni a tutto tondo.
Niente di che, in un mondo ad alta integrazione. Qualcosa di non immediato al momento nella PA italiana, ma che un domani può diventare la normalità.
I due temi che restano aperti
Il primo: le Poste non hanno un OPI a quanto ci risulta, come riconciliare i flussi bancari dei conti postali? Anche Poste produrrà un OPI o si ricade nella seconda domanda?
Si dovrà quindi fare in modo di processare laddove c’è una banca un OPI, ma dove c’è la Posta un conto corrente? Per linee guida anche le Poste devono produrre flussi di rendicontazione a standard pagoPa, quindi vedremo come le Poste nel tempo permetteranno questa riconciliazione che è importante per automatizzare il “giro pagopa”.
Il secondo punto aperto: per gli enti pubblici non comunali (es. utilities), la banca dà un estratto conto (come quello di casa), non un OPI. Nell’estratto conto spesso l’id del flusso di rendicontazione è tagliato per motivi tecnologici (non ci sta nel campo previsto dai sistemi), quindi come si può effettuare la rendicontazione? Su questo punto nel tempo è normale che le banche si adegueranno mettendo un campo più ampio. Prima lo faranno, meglio è.
Infine, c’è un terzo punto aperto, che abbiamo dalla “notte dei tempi” di pagoPA: in alcuni casi, il flusso di rendicontazione non è obbligatorio laddove la transazione è singola. In questi casi la riconciliazione va fatta a ritroso: se ho i soldi allora sicuramente ho rendicontato e quindi do per assunto che la riconciliazione è ok.
Le buone notizie
Fortunatamente anche questi casi nel tempo spariranno: più transazioni ci saranno più si annullerà la probabilità di avere PSP che rendiconteranno flussi con una singola transazione, potendo laddove ritengono di non mandare il flusso. Questo sia nelle PAL (pubbliche amministrazioni locali) che nelle PAC (pubbliche amministrazioni centrali).
Possiamo dire quindi che PagoPa prosegue il suo cammino, verso la scadenza del 31 dicembre 2019 e dopo la costituzione della nuova Pagopa s.p.a. che si occuperà anche dell’app IO e di Data & Analytics Framework (Daf).
