15 erros comuns em XML SEPA e como corrigi-los
Um guia completo sobre os erros de validação mais frequentes em SEPA pain.001 e pain.008, com soluções práticas para cada um.
Por que os ficheiros XML SEPA são rejeitados
Os ficheiros XML SEPA (pain.001 para transferências a crédito e pain.008 para débitos diretos) seguem esquemas ISO 20022 rigorosos definidos pelo European Payments Council (EPC). Mesmo pequenos desvios da estrutura esperada fazem com que os bancos rejeitem lotes inteiros de pagamentos. Compreender os erros comuns poupa tempo e evita atrasos dispendiosos nos pagamentos.
Este guia abrange os 15 erros XML SEPA mais frequentes encontrados por equipas de tesouraria, contabilistas e programadores em toda a Europa. Cada erro inclui a causa raiz, o elemento XML envolvido e uma solução testada.
Quer utilize SAP, Oracle ou um ERP personalizado, estes padrões aplicam-se universalmente a todos os ficheiros de pagamento conformes com SEPA.
Erros de esquema e estrutura
Estes erros ocorrem quando a estrutura XML não corresponde ao esquema XSD do EPC.
1. Espaço de nomes ou versão de esquema incorretos
O elemento raiz <Document> deve declarar o espaço de nomes correto para a sua versão pain.001 (ex.: urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Misturar espaços de nomes de versões diferentes provoca um erro de validação XSD imediato.
2. Campos obrigatórios GrpHdr em falta
O bloco GroupHeader (GrpHdr) requer MsgId, CreDtTm, NbOfTxs, CtrlSum e InitgPty. Omitir qualquer um destes campos — especialmente CtrlSum — faz com que o ficheiro não passe a validação do esquema antes de o banco processar as instruções de pagamento.
3. Codificação XML inválida ou BOM
O XML SEPA deve usar codificação UTF-8. Ficheiros com BOM (Byte Order Mark), UTF-16 ou codificação Windows-1252 são rejeitados. Certifique-se de que a ferramenta de exportação escreve UTF-8 puro sem BOM.
4. Elementos em ordem incorreta
Os esquemas ISO 20022 impõem uma ordenação rígida dos elementos. Por exemplo, em PmtInf, o PmtMtd deve aparecer antes de ReqdExctnDt. Trocar posições de elementos — mesmo que todos os dados estejam presentes — provoca um erro de validação de esquema.
5. MsgId duplicado entre ficheiros
Cada ficheiro SEPA deve ter um MsgId único. Se o sistema reutilizar o mesmo MsgId para diferentes lotes de pagamento, os bancos rejeitarão o duplicado como um potencial ataque de repetição. Use marcas temporais ou UUIDs para garantir unicidade.
Erros de IBAN e BIC
Os erros nos identificadores de conta são a razão mais comum para rejeições SEPA.
6. Soma de verificação IBAN inválida (mod-97)
Os IBANs usam um algoritmo mod-97 para os seus dígitos de verificação (posições 3-4). Um único erro de dígito faz falhar a soma de verificação. Valide sempre os IBANs programaticamente antes de os incluir no seu ficheiro SEPA. O ValidateFin verifica cada IBAN no ficheiro automaticamente.
7. Comprimento de IBAN não corresponde ao país
Cada país tem um comprimento de IBAN fixo (ex.: DE=22, FR=27, BE=16, NL=18). Um IBAN com o número incorreto de caracteres para o seu prefixo de país é imediatamente inválido.
8. BIC obsoleto ou inválido
Os códigos BIC/SWIFT podem tornar-se obsoletos após fusões bancárias. Usar um BIC obsoleto causa falhas de encaminhamento. Para pagamentos SEPA dentro do EEE, o BIC é opcional desde 2016 — considere omiti-lo e deixar o banco derivá-lo do IBAN.
Erros de montante e moeda
Erros de validação financeira que causam rejeição ao nível do lote.
9. CtrlSum não corresponde ao total das transações
O CtrlSum no GrpHdr deve ser exatamente igual à soma de todos os valores InstdAmt no ficheiro. Mesmo uma diferença de arredondamento de 0,01€ faz com que o ficheiro completo seja rejeitado. Use aritmética decimal precisa, não de vírgula flutuante.
10. Moeda não EUR no ficheiro SEPA
As Transferências a Crédito SEPA suportam apenas EUR. Se o seu ficheiro contiver montantes em GBP, CHF ou outras moedas, o banco rejeitá-lo-á. Use um canal de pagamento internacional separado para transferências não EUR.
11. Formato de montante com separador decimal incorreto
O XML SEPA usa um ponto (.) como separador decimal, não uma vírgula. O valor deve ter exatamente 2 casas decimais: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Valores como "1500" ou "1.500,00" são inválidos.
Erros de data e identificador
Erros comuns nos campos de data e referência.
12. Data de execução passada ou inválida
O ReqdExctnDt deve ser um dia útil atual ou futuro. A maioria dos bancos rejeita datas no passado e datas com mais de 30 dias de antecedência. As datas de fim de semana são deslocadas para segunda-feira, mas alguns bancos rejeitam-nas diretamente.
13. Caracteres inválidos em EndToEndId
O campo EndToEndId (máx. 35 caracteres) permite apenas um conjunto restrito: a-z, A-Z, 0-9 e alguns caracteres especiais (/, -, ?, :, (, ), ., +, espaço). Caracteres como #, @, é, ü são rejeitados.
14. Identificador de credor em falta para SDD
O SEPA Direct Debit (pain.008) requer um Identificador de Credor (CI) válido em CdtrSchmeId. Este é um registo específico de cada país (ex.: ICS em França, Gläubiger-ID na Alemanha). Sem ele, todo o lote SDD falha.
15. Contagem NbOfTxs não corresponde
O campo NbOfTxs no GrpHdr deve corresponder ao número real de elementos CdtTrfTxInf (ou DrctDbtTxInf) no ficheiro. Uma discrepância — frequentemente causada pela geração parcial do ficheiro — causa rejeição imediata.
Valide os seus ficheiros SEPA instantaneamente
O ValidateFin deteta todos os 15 erros listados acima — e mais. Carregue o seu ficheiro pain.001 ou pain.008 e obtenha feedback imediato sobre conformidade com o esquema, validação de IBAN, consistência de montantes e codificação de caracteres.
Abrir validador SEPAPerguntas frequentes
Qual é o erro XML SEPA mais comum?
O erro mais comum é uma soma de verificação IBAN inválida (falha mod-97). Isto representa cerca de 30% de todas as rejeições de ficheiros SEPA. Valide sempre os IBANs antes de gerar o seu ficheiro de pagamento.
Posso corrigir erros SEPA sem regenerar o ficheiro inteiro?
Depende do erro. Correções simples como corrigir um IBAN ou ajustar o CtrlSum podem ser feitas editando o XML diretamente. No entanto, erros estruturais (ordem incorreta de elementos, espaço de nomes em falta) geralmente requerem regeneração a partir do sistema de origem.
O ValidateFin verifica todos os 15 erros?
Sim. O ValidateFin valida o seu ficheiro SEPA contra os esquemas XSD do EPC, verifica cada IBAN com mod-97, verifica a consistência do CtrlSum, valida a codificação de caracteres e sinaliza todos os problemas estruturais. A validação é executada completamente no seu navegador — nenhum ficheiro é carregado.
Por que o meu banco rejeita um ficheiro que passou a validação XSD?
A validação XSD verifica apenas a estrutura XML. Os bancos também aplicam regras de negócio: datas de execução válidas, CtrlSum correto, MsgId único e IBAN/BIC apropriados. O ValidateFin verifica tanto o esquema como as regras de negócio.
Os códigos de erro SEPA são padronizados?
Sim. Os bancos usam códigos de motivo ISO 20022 (ex.: AC01 para IBAN incorreto, AM05 para duplicado, AG01 para tipo de transação proibido). O EPC mantém uma lista completa no documento de Códigos de Motivo SEPA.
Como prevenir erros SEPA no meu ERP?
Implemente validação de IBAN na entrada de dados, use uma biblioteca XML SEPA (não concatenação de strings) para geração de ficheiros, valide o ficheiro de saída antes de enviar e teste sempre primeiro com a ferramenta de validação do seu banco.
O que acontece quando um ficheiro SEPA é rejeitado?
O banco devolve um relatório de estado pain.002 com códigos de motivo de rejeição para cada transação falhada. Deve corrigir os erros e reenviar o ficheiro completo ou o bloco de pagamento afetado.
Os problemas de codificação de caracteres podem ser silenciosos?
Sim. Alguns caracteres (como aspas tipográficas " " ou travessões —) parecem corretos no ecrã, mas estão fora do conjunto de caracteres SEPA. Causam rejeições sem uma indicação visual óbvia. O ValidateFin sinaliza estes problemas de codificação invisíveis.
Existe diferença no tratamento de erros entre pain.001.001.03 e .09?
As versões mais recentes (09, 11) têm validação mais rigorosa. Alguns campos que eram opcionais na versão 03 são agora obrigatórios. As restrições do conjunto de caracteres são as mesmas. O ValidateFin valida contra a versão específica declarada no seu ficheiro.
Quanto tempo tenho para corrigir um ficheiro SEPA rejeitado?
Não existe prazo padrão, mas os atrasos de pagamento acumulam-se. A maioria das equipas de tesouraria visa corrigir e reenviar em 4 horas úteis. A pré-validação com ValidateFin elimina a maioria dos cenários de rejeição.