Em novembro de 2026 entram em vigor duas regras, com dez dias de intervalo. O AIB deixa de processar os formatos antigos de pagamentos em lote depois de 12 de novembro. A partir de 22 de novembro, cada transferência SEPA tem de levar a localidade e o país em cada morada, cada um no seu campo. A maior parte dos programas de contabilidade ainda exporta ficheiros que falham as duas.
Passámos as últimas semanas a resolver exatamente isto para um cliente na Irlanda. Fica aqui o que muda, como verificar os seus ficheiros e o que fazer se o programa de contabilidade não conseguir exportar o formato novo a tempo.
O que é um ficheiro pain.001?
O pain.001 é a mensagem XML da norma ISO 20022 que uma empresa envia ao banco para ordenar transferências. Um ficheiro leva um lote de pagamentos: quem paga, quem recebe, os IBAN, os valores e a data de execução. Programas como o Twinfield e o Xledger exportam-no, e a equipa financeira carrega-o no banco ou envia-o por SFTP.
Antes de pagar, o banco valida o ficheiro contra o esquema ISO (o XSD) e contra as suas próprias regras. Se falhar uma delas, o ficheiro é rejeitado, todo ou pagamento a pagamento.
O que muda no AIB a 12 de novembro de 2026?
O AIB deixa de processar os formatos antigos de ficheiros de pagamentos em lote depois de 12 de novembro de 2026. Os ficheiros têm de seguir a especificação pain.001.001.09 do AIB. O banco explica-o na sua página sobre a ISO 20022.
O que muda nos pagamentos SEPA a 22 de novembro de 2026?
A partir de 22 de novembro de 2026, os pagamentos SEPA só aceitam moradas estruturadas ou híbridas. A localidade (TwnNm) e o país (Ctry) passam a ser obrigatórios em cada morada. Uma linha de texto livre com a morada toda é rejeitada. O Bank of Ireland descreve-o na estrutura do ficheiro pain.001.001.09.
A regra vem do European Payments Council, por isso não é só irlandesa. Todos os bancos que processam transferências SEPA a aplicam.
Qual é a diferença entre o pain.001.001.03 e o pain.001.001.09?
O pain.001.001.03 é a versão de 2009 da mensagem, e continua a ser o que a maioria dos programas de contabilidade exporta. O pain.001.001.09 é a versão de 2019, que o European Payments Council adotou para a SEPA em novembro de 2023. Acrescenta elementos de morada estruturada, o LEI e mais alguns campos, e alguns elementos mudam de sítio ou de nome.
Converter não é trocar o namespace. O cabeçalho do lote, a data de execução, a morada e os identificadores de cada banco mudam todos, e cada banco publica as suas regras por cima da norma.
Como é uma morada rejeitada?
Esta é a morada não estruturada que a maioria das exportações ainda escreve. A partir de 22 de novembro falha, porque não tem localidade:
<PstlAdr>
<Ctry>IE</Ctry>
<AdrLine>Unit 4, Quay Road, Dublin 2</AdrLine>
</PstlAdr>Esta morada híbrida passa. A rua fica como foi escrita, e a localidade e o país ficam nos seus próprios elementos:
<PstlAdr>
<TwnNm>Dublin</TwnNm>
<Ctry>IE</Ctry>
<AdrLine>Unit 4, Quay Road</AdrLine>
</PstlAdr>A morada estruturada vai mais longe e separa tudo: rua (StrtNm), número de porta, código postal, localidade e país. Para ficheiros que saem de um programa de contabilidade, a híbrida costuma ser o caminho prático, porque ninguém tem de voltar a escrever a rua.
Como verifico se os meus ficheiros vão ser rejeitados?
- Abra o último ficheiro que enviou e veja o namespace no elemento
Document. Se acabar empain.001.001.03, é a versão antiga. - Procure
PstlAdr. Qualquer morada comAdrLinee semTwnNmfalha a partir de 22 de novembro. - Veja a data de execução pedida. Na versão 09, o
ReqdExctnDtleva a data dentro de um elementoDt. - Valide o ficheiro contra o XSD e contra as regras do seu banco. Passar no esquema ISO não chega.
E se o programa de contabilidade não exportar pain.001.001.09 a tempo?
Era o caso do nosso cliente. As exportações do Twinfield continuavam em pain.001.001.03, com as moradas dos fornecedores escritas numa só linha. Ninguém volta a escrever centenas de moradas numa semana.
Por isso pusemos agentes entre a exportação e o banco. Leem o ficheiro, completam cada morada com a localidade e o país, assinalam o que o banco ia rejeitar (sem localidade, a morada toda numa linha, uma data que já passou) e escrevem um ficheiro pain.001.001.09. Antes de seguir para o banco, o ficheiro é validado contra o esquema ISO 20022, as regras do Bank of Ireland e os totais de controlo do cabeçalho.
O caso completo está em Ficheiros do Twinfield que o AIB e o Bank of Ireland aceitam (em inglês).
Onde entra a Alongside
Automatizamos o trabalho entre os programas de contabilidade e os bancos: exportações do Twinfield, Xledger, Exact, Sage e outros, convertidas, validadas e entregues ao banco. Pode ver como na página de automação financeira (em inglês). Se os seus ficheiros de pagamento têm de mudar este mês, escreva para hi@alongside.team.
