File di pagamento e riconciliazione tra ERP e banca
ERP verso banca: file di pagamento in uscita, estratti conto in ritorno, riconciliati
Pagamenti inviati come ISO 20022 pain.001 tramite host-to-host SFTP o API bancarie, con estratti camt.053 e MT940 riconciliati con il libro giornale.
Blueprint
Scorra lateralmente per vedere l’intero disegno.
Da ERP a banca: pagamenti in uscita, estratti conto in entrata
I pagamenti approvati escono dall’ERP come file ISO 20022 firmati su un canale host-to-host. Rapporti di stato ed estratti conto tornano per la stessa via e sono riconciliati con le partite aperte. Rifiuti e righe non riconciliate arrivano al Suo team con il motivo allegato.
- Flusso principale
- Asincrono
- Percorso di eccezione
Il flusso in 10 passi
Il flusso, passo per passo
- Da ERP a Livello di integrazione: Ciclo di pagamenti approvato, tramite REST/JSON · IDoc (flusso principale).
- Da Livello di integrazione a Canale bancario sicuro: File di pagamento firmato e cifrato, tramite ISO 20022 pain.001 · OpenPGP (flusso principale).
- Da Canale bancario sicuro a Banca: Consegnato alla banca, tramite SFTP H2H (flusso principale).
- Da Banca a Canale bancario sicuro: Rapporti di stato ed estratti conto, tramite pain.002 · camt.053 · MT940 (asincrono).
- Da Canale bancario sicuro a Livello di integrazione: Raccolto e validato, tramite SFTP H2H (asincrono).
- Da Livello di integrazione a Motore di riconciliazione: Righe dell’estratto conto, tramite camt.053 (asincrono).
- Da Motore di riconciliazione a ERP: Voci riconciliate registrate, tramite REST/JSON (flusso principale).
- Da Livello di integrazione a Team tesoreria e finanza: Pagamenti rifiutati, con il codice di motivo, tramite pain.002 RJCT (percorso di eccezione).
- Da Motore di riconciliazione a Team tesoreria e finanza: Righe non riconciliate: un disallineamento di riconciliazione (percorso di eccezione).
- Da Team tesoreria e finanza a ERP: Corretto e inviato di nuovo (percorso di eccezione).
Panoramica
Questo è il flusso tra un ERP e le sue banche: i pagamenti approvati escono, e report di stato ed estratti conto rientrano. È la connessione che più team finance gestiscono ancora a mano, tramite portali bancari e fogli di calcolo, ed è quella in cui un errore costa denaro.
Il progetto di riferimento mette uno strato di integrazione tra l’ERP e ciascuna banca. Lo strato mappa i pagamenti nella variante bancaria di ISO 20022 pain.001, li firma e li cifra, e li consegna via host-to-host SFTP, EBICS o API della banca. Report di stato ed estratti conto tornano per la stessa via e sono riconciliati con le partite aperte nell’ERP.
Il percorso di errore è progettato con la stessa cura del percorso normale. Un pagamento rifiutato torna con il codice motivo della banca. Una riga di estratto conto che non trova corrispondenza diventa una differenza di riconciliazione assegnata a una persona nominata. Nulla viene scartato e nulla viene registrato due volte.
Come funziona il flusso
Approvare il ciclo di pagamento
Il Suo ERP produce il ciclo di pagamento e i Suoi approvatori lo rilasciano, come fanno oggi. Lo strato di integrazione preleva solo i cicli approvati.
Mappare, firmare e cifrare
Lo strato mappa ogni pagamento nella variante pain.001 della banca, lo valida e firma e cifra il file come richiede la banca.
Consegnare alla banca
Il file viaggia sul canale concordato, host-to-host SFTP, EBICS o API della banca, prima dell’orario limite della banca.
Ricevere stati ed estratti conto
La banca restituisce report di stato pain.002 per ogni file e pagamento, e estratti conto camt.053 o MT940 a fine giornata.
Raccogliere e validare
Lo strato raccoglie ogni report, verifica lacune e duplicati rispetto alla sequenza degli estratti conto e lo analizza in righe.
Riconciliare e registrare
Le righe degli estratti conto sono riconciliate con le partite aperte secondo le regole che ha approvato, e le voci riconciliate sono registrate nell’ERP.
Quando qualcosa fallisce
Un pagamento viene rifiutato
Il report pain.002 porta il codice motivo della banca. Il pagamento è contrassegnato come rifiutato nell’ERP e inviato al Suo team di tesoreria per la correzione e il reinvio.
Una riga di estratto conto non trova corrispondenza
La riga diventa una differenza di riconciliazione con i candidati probabili e il motivo del fallimento. Il Suo team la chiude, e le regole possono imparare da essa.
Un file manca o è in ritardo
I numeri di sequenza degli estratti conto e gli orari di consegna attesi vengono verificati. Un file mancante o in ritardo genera un avviso prima che qualcuno faccia affidamento sulla posizione di cassa.
Una chiave o un certificato sta per scadere
Chiavi di firma e certificati dei canali sono monitorati con le loro date di scadenza, e il rinnovo inizia abbastanza presto da concordare la nuova chiave con la banca.
Standard e sistemi
- Standard e canali bancari
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
Domande e risposte
Host-to-host, EBICS o API bancarie: quale dovremmo usare?
Di solito decide la banca. L’host-to-host SFTP è il canale più diffuso per i file di pagamento aziendali. EBICS è comune con le banche in Germania, Francia e Paesi vicini. Le API bancarie si adattano ai saldi in tempo reale e ai pagamenti istantanei dove la banca le offre. Molte aziende usano più di un canale, e lo strato di integrazione nasconde la differenza all’ERP.
Dovremmo ricevere estratti conto camt.053 o MT940?
Dove la banca offre entrambi, camt.053 contiene dati di rimessa più ricchi e strutturati, il che rende più affidabile la riconciliazione automatica. MT940 è ancora molto usato e funziona bene in molti casi. Possiamo accettare entrambi, convertirli nello stesso modello interno e far passare ogni banca da MT940 a camt.053 quando conviene a Lei e alla banca.
Possiamo vedere la posizione di cassa durante la giornata?
Sì, se le Sue banche forniscono report infragiornalieri. Arrivano come messaggi camt.052 o MT942, o tramite un’API dei saldi. Li raccogliamo con la cadenza supportata da ogni banca e li mostriamo accanto agli estratti conto di fine giornata, così il Suo team di tesoreria vede posizioni attese ed effettive prima degli orari limite.
Possiamo tracciare chi ha approvato e inviato un pagamento?
Sì. L’approvazione resta nel Suo ERP con i controlli esistenti. Lo strato di integrazione registra ogni file che crea, firma, invia e riceve, con timestamp, identificativi e l’account tecnico usato. Quel registro collega ogni pagamento nel report di stato della banca al documento ERP e ai suoi approvatori.
Abbiamo più banche. Ognuna è un progetto separato?
No. Lo strato di integrazione, il modello interno dei pagamenti e le regole di riconciliazione si costruiscono una volta sola. Ogni nuova banca aggiunge la propria variante di formato, il proprio canale e i propri passaggi di onboarding, che sono pezzi di lavoro più piccoli. Di solito colleghiamo prima la banca con il volume maggiore e aggiungiamo le altre in ordine.
Come si collauda la connessione prima del go-live?
Ogni banca fornisce un ambiente di collaudo o un processo di test. Concordiamo con la banca una serie di casi di test, che coprono ogni tipo di pagamento, rifiuti ed estratti conto, li eseguiamo e conserviamo le prove. Quando la banca approva, passiamo in produzione con un primo piccolo ciclo di pagamento e confrontiamo i risultati prima di spostare il resto.
Inizi con una conversazione, non con un contratto.
Ci racconti che cosa deve costruire, collegare o proteggere. Un architetto lo esamina con Lei e poi consiglia da dove iniziare.
Che cosa succede dopo
Concordare un orario
Il nostro team Le invia un’e-mail per concordare un orario per la sessione.
Sessione di preconsulenza
Una sessione di preconsulenza online gratuita di 30 minuti: esaminiamo i Suoi obiettivi, i Suoi sistemi e i Suoi vincoli.
Revisione di preparazione
Nell’ambito di una revisione di preparazione gratuita di 48 ore, un architetto principal verifica il Suo progetto rispetto alla definizione di «pronto» in 6 punti e raccomanda il Track più adatto.
Scelta del Track
I progetti con perimetro definito ricevono una proposta vincolante entro 3–5 giorni lavorativi. I progetti in fase di concept iniziano nel Blueprint Studio. Un sistema in produzione che non funziona, non è documentato o richiede integrazione inizia con una diagnosi di 1–2 settimane. Il Blueprint Studio e la diagnosi hanno ciascuno un compenso fisso, indicato nella proposta.