15 errori SEPA XML comuni e come correggerli
Una guida completa agli errori di validazione più frequenti in SEPA pain.001 e pain.008, con soluzioni pratiche per ciascuno.
Perché i file SEPA XML vengono rifiutati
I file SEPA XML (pain.001 per i bonifici e pain.008 per gli addebiti diretti) seguono schemi ISO 20022 rigidi definiti dall'European Payments Council (EPC). Anche piccole deviazioni dalla struttura attesa causano il rifiuto dell'intero lotto di pagamenti da parte delle banche. Capire gli errori comuni fa risparmiare tempo e previene costosi ritardi nei pagamenti.
Questa guida tratta i 15 errori SEPA XML più frequenti riscontrati da team di tesoreria, contabili e sviluppatori in tutta Europa. Ogni errore include la causa principale, l'elemento XML coinvolto e una soluzione testata.
Che tu usi SAP, Oracle o un ERP personalizzato, questi pattern si applicano universalmente a tutti i file di pagamento conformi SEPA.
Errori di schema e struttura
Questi errori si verificano quando la struttura XML non corrisponde allo schema XSD EPC.
1. Namespace o versione schema errati
L'elemento root <Document> deve dichiarare il namespace corretto per la versione pain.001 (es. urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Mescolare namespace di versioni diverse causa un errore di validazione XSD immediato.
2. Campi obbligatori GrpHdr mancanti
Il blocco GroupHeader (GrpHdr) richiede MsgId, CreDtTm, NbOfTxs, CtrlSum e InitgPty. Omettere uno di questi campi — in particolare CtrlSum — fa fallire la validazione dello schema prima che la banca elabori le istruzioni di pagamento.
3. Codifica XML non valida o BOM
SEPA XML deve usare la codifica UTF-8. File con BOM (Byte Order Mark), UTF-16 o codifica Windows-1252 vengono rifiutati. Assicurati che lo strumento di esportazione scriva UTF-8 puro senza BOM.
4. Elementi in ordine errato
Gli schemi ISO 20022 impongono un ordine rigoroso degli elementi. Ad esempio, in PmtInf, il PmtMtd deve apparire prima di ReqdExctnDt. Invertire le posizioni degli elementi — anche se tutti i dati sono presenti — causa un errore di validazione schema.
5. MsgId duplicato tra file
Ogni file SEPA deve avere un MsgId univoco. Se il sistema riutilizza lo stesso MsgId per diversi lotti di pagamento, la banca rifiuterà il duplicato come potenziale attacco replay. Usa timestamp o UUID per garantire l'unicità.
Errori IBAN e BIC
Gli errori negli identificatori di conto sono la causa più comune di rifiuti SEPA.
6. Checksum IBAN non valida (mod-97)
Gli IBAN usano un algoritmo mod-97 per le cifre di controllo (posizioni 3-4). Un singolo errore di cifra fa fallire il checksum. Valida sempre gli IBAN programmaticamente prima di includerli nel file SEPA. ValidateFin controlla ogni IBAN nel file automaticamente.
7. Lunghezza IBAN non corrispondente per il paese
Ogni paese ha una lunghezza IBAN fissa (es. DE=22, FR=27, BE=16, NL=18). Un IBAN con il numero di caratteri sbagliato per il prefisso del paese è immediatamente non valido.
8. BIC obsoleto o non valido
I codici BIC/SWIFT possono diventare obsoleti dopo fusioni bancarie. L'uso di un BIC obsoleto causa errori di routing. Per pagamenti SEPA all'interno del SEE, il BIC è opzionale dal 2016 — considera di ometterlo e lasciare che la banca lo derivi dall'IBAN.
Errori di importo e valuta
Errori di validazione finanziaria che causano il rifiuto dell'intero lotto.
9. CtrlSum non corrisponde al totale delle transazioni
Il CtrlSum in GrpHdr deve essere esattamente uguale alla somma di tutti i valori InstdAmt nel file. Anche una differenza di arrotondamento di 0,01€ causa il rifiuto dell'intero file. Usa aritmetica decimale precisa, non virgola mobile.
10. Valuta non EUR nel file SEPA
I bonifici SEPA supportano solo EUR. Se il file contiene importi in GBP, CHF o altre valute, la banca lo rifiuterà. Usa un canale di pagamento internazionale separato per i trasferimenti non EUR.
11. Formato importo con separatore decimale errato
SEPA XML usa il punto (.) come separatore decimale, non la virgola. Il valore deve avere esattamente 2 cifre decimali: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Valori come "1500" o "1.500,00" non sono validi.
Errori di data e identificatore
Errori comuni nei campi data e riferimento.
12. Data di esecuzione passata o non valida
Il ReqdExctnDt deve essere un giorno lavorativo attuale o futuro. La maggior parte delle banche rifiuta date nel passato e date oltre 30 giorni in avanti. Le date del fine settimana vengono spostate al lunedì, ma alcune banche le rifiutano direttamente.
13. Caratteri non validi in EndToEndId
Il campo EndToEndId (max 35 caratteri) consente solo un set limitato: a-z, A-Z, 0-9 e alcuni caratteri speciali (/, -, ?, :, (, ), ., +, spazio). Caratteri come #, @, é, ü vengono rifiutati.
14. Identificatore creditore mancante per SDD
SEPA Direct Debit (pain.008) richiede un Creditor Identifier (CI) valido in CdtrSchmeId. Questa è una registrazione specifica per paese (es. ICS in Francia, Gläubiger-ID in Germania). Senza di essa, l'intero lotto SDD fallisce.
15. Numero NbOfTxs non corrisponde
Il campo NbOfTxs in GrpHdr deve corrispondere al numero effettivo di elementi CdtTrfTxInf (o DrctDbtTxInf) nel file. Una discrepanza — spesso causata da generazione parziale del file — causa il rifiuto immediato.
Valida i tuoi file SEPA istantaneamente
ValidateFin rileva tutti e 15 gli errori elencati sopra — e altri ancora. Carica il tuo file pain.001 o pain.008 e ottieni feedback immediato su conformità schema, validazione IBAN, coerenza importi e codifica caratteri.
Apri il validatore SEPADomande frequenti
Qual è l'errore SEPA XML più comune?
L'errore più comune è una checksum IBAN non valida (fallimento mod-97). Questo rappresenta circa il 30% di tutti i rifiuti di file SEPA. Valida sempre gli IBAN prima di generare il file di pagamento.
Posso correggere gli errori SEPA senza rigenerare l'intero file?
Dipende dall'errore. Correzioni semplici come correggere un IBAN o aggiustare CtrlSum possono essere fatte modificando direttamente l'XML. Tuttavia, gli errori strutturali (ordine errato degli elementi, namespace mancante) richiedono di solito la rigenerazione dal sistema sorgente.
ValidateFin controlla tutti e 15 gli errori?
Sì. ValidateFin valida il file SEPA contro gli schemi XSD EPC, controlla ogni IBAN con mod-97, verifica la coerenza CtrlSum, valida la codifica caratteri e segnala tutti i problemi strutturali. La validazione viene eseguita interamente nel browser — nessun file viene caricato.
Perché la mia banca rifiuta un file che ha superato la validazione XSD?
La validazione XSD controlla solo la struttura XML. Le banche applicano anche regole aziendali: date di esecuzione valide, CtrlSum corretto, MsgId univoco e IBAN/BIC appropriati. ValidateFin controlla sia schema che regole aziendali.
I codici di errore SEPA sono standardizzati?
Sì. Le banche usano codici motivo ISO 20022 (es. AC01 per IBAN errato, AM05 per duplicato, AG01 per tipo transazione non consentito). L'EPC mantiene un elenco completo nel documento SEPA Reason Codes.
Come prevengo gli errori SEPA nel mio ERP?
Implementa la validazione IBAN all'inserimento dati, usa una libreria SEPA XML (non concatenazione di stringhe) per la generazione di file, valida il file di output prima dell'invio e testa sempre prima con lo strumento di validazione della tua banca.
Cosa succede quando un file SEPA viene rifiutato?
La banca restituisce un rapporto di stato pain.002 con codici motivo di rifiuto per ogni transazione fallita. Devi correggere gli errori e ripresentare l'intero file o il blocco di pagamento interessato.
I problemi di codifica caratteri possono essere silenziosi?
Sì. Alcuni caratteri (come virgolette tipografiche " " o trattini em —) sembrano corretti sullo schermo ma sono al di fuori del set di caratteri SEPA. Causano rifiuti senza un chiaro indizio visivo. ValidateFin segnala questi problemi di codifica invisibili.
C'è differenza nella gestione degli errori tra pain.001.001.03 e .09?
Le versioni più recenti (09, 11) hanno una validazione più severa. Alcuni campi opzionali nella versione 03 sono ora obbligatori. Le restrizioni sul set di caratteri sono le stesse. ValidateFin valida rispetto alla versione specifica dichiarata nel file.
Quanto tempo ho per correggere un file SEPA rifiutato?
Non esiste una scadenza standard, ma i ritardi di pagamento si accumulano. La maggior parte dei team di tesoreria punta a correggere e ripresentare entro 4 ore lavorative. La pre-validazione con ValidateFin elimina la maggior parte degli scenari di rifiuto.