A migração para pain.001.001.09 abrange toda a cadeia de pagamentos: dados do ERP, geração do ficheiro, validação bancária e tratamento dos retornos. Alterar um número de versão num XML não é suficiente. Uma migração bem preparada permite às equipas de tesouraria manter o controlo dos pagamentos, melhorando a qualidade dos dados e a rastreabilidade.
Informação normativa verificada em 21 de outubro de 2026. A abordagem de projeto apresentada é uma recomendação operacional da Précis Consulting.
1. O que significa pain.001.001.09?
O identificador completo é pain.001.001.09, por vezes abreviado incorretamente para «pain.001.009». Corresponde à mensagem ISO 20022 CustomerCreditTransferInitiationV09: uma instrução de transferência enviada por uma entidade iniciadora ao seu banco ou a um intermediário. Um ficheiro pode reunir várias instruções.
O pain.001 pertence à relação cliente–prestador de serviços de pagamento. A execução interbancária utiliza outra família de mensagens, nomeadamente pacs.008. Esta distinção evita confundir a migração dos ficheiros de pagamentos das empresas com a migração das trocas entre bancos.
2. Distinguir a norma, o perfil bancário e o canal
A norma ISO descreve a mensagem; o sistema de pagamentos define a sua utilização; o banco documenta as condições de envio. Nas transferências SEPA tradicionais, as orientações EPC de 2025 baseiam-se na versão de 2019 da ISO 20022 e utilizam pain.001.001.09. Este enquadramento não significa que todos os pagamentos internacionais, moedas e bancos sigam um calendário único de migração.
Antes de alterar o TMS ou o ERP, recomendamos documentar três níveis de validação:
- Estrutura: XML bem formado e conforme com o esquema da mensagem esperada.
- Regras de negócio: dados e combinações permitidos para o serviço utilizado.
- Envio ao banco: canal, permissões, assinaturas, horas-limite e retornos acordados.
A conformidade com o esquema, por si só, não demonstra que o pagamento será aceite ou executado. Os critérios de sucesso devem abranger o percurso completo, até à reconciliação.
3. Moradas: considerar a atualização mais recente do calendário
As regras EPC distinguem moradas estruturadas, híbridas e não estruturadas. O formato híbrido está disponível no âmbito das regras de 2025 desde 5 de outubro de 2025. Nas publicações oficiais verificadas para este artigo, o EPC adiou a data anteriormente prevista de 15 de novembro de 2026 para o fim das moradas não estruturadas; a nova data continua por determinar. O regulamento SCT 2025, versão 1.2, e o guia de moradas, versão 2.2, publicados em 30 de setembro de 2026, refletem esse adiamento.
É aconselhável prosseguir o trabalho de qualidade das moradas e confirmar os requisitos de cada fluxo. Recomendamos manter separadamente, nos dados de referência, informações como país, localidade e outros componentes da morada, de acordo com o perfil esperado. Um conversor técnico não consegue reconstruir de forma fiável uma informação ausente ou ambígua nos dados de origem.
4. Um plano de migração em seis etapas
Etapa 1 — Mapear os fluxos e as responsabilidades
Identifique as entidades ordenantes, contas a debitar, bancos, países, moedas, tipos de transferência e canais de transmissão. Identifique o gerador de cada ficheiro: ERP, TMS, aplicação de salários ou prestador de serviços. Nomeie um responsável de negócio, um responsável técnico e um interlocutor bancário. O resultado deverá ser uma matriz dos fluxos, com as versões atuais e os perfis de destino confirmados por cada banco.
Etapa 2 — Corrigir os dados antes da conversão
Analise uma amostra representativa de fornecedores, trabalhadores e beneficiários. Verifique os dados bancários, nomes, moradas e referências utilizadas na reconciliação. Os responsáveis pelos dados de referência devem corrigir as anomalias na origem. Conserve um registo de validação das alterações sensíveis, em especial das alterações de dados bancários.
Etapa 3 — Documentar a correspondência dos campos
Crie uma tabela de correspondência entre os dados de origem e os elementos da nova mensagem. Especifique os campos obrigatórios, regras condicionais, valores predefinidos permitidos e tratamento de erros. Mantenha identificadores coerentes entre o ERP, o TMS e os retornos bancários. Controle as versões da parametrização para permitir a auditoria das alterações e evitar diferenças entre filiais.
Etapa 4 — Testar do ficheiro à reconciliação
Comece pelos controlos de estrutura e realize depois os testes de aceitação no dispositivo acordado com o banco. Verifique a aceitação, as rejeições, os estados parciais, os duplicados e a integração dos retornos. Uma confirmação de receção do canal não equivale a uma confirmação de execução. Para cada cenário, conserve o ficheiro enviado, o resultado esperado, o retorno recebido e a aprovação da equipa de negócio.
Etapa 5 — Fazer uma transição gradual
Escolha um âmbito limitado: uma entidade, um banco e uma categoria de pagamentos. Defina os critérios de entrada em produção, as pessoas autorizadas a aprovar a transição e um procedimento de contingência validado com o banco. Um formato antigo pode deixar de ser aceite; a contingência deve ser uma opção operacional confirmada, impedindo o reenvio sem controlo de ordens já transmitidas.
Etapa 6 — Estabilizar e acompanhar as exceções
Acompanhe os primeiros ciclos com a tesouraria, a contabilidade e a informática. Classifique os incidentes por causa: dados, parametrização, canal ou processamento bancário. Meça a taxa de rejeição, as intervenções manuais e o tempo de resolução. Encerre o projeto após a validação do tratamento dos retornos e da reconciliação, integrando depois a evolução dos formatos na manutenção regular.
5. Cenários a incluir nos testes de aceitação
- Uma transferência individual e um lote representativo dos volumes reais.
- Referências de pagamento longas, caracteres especiais e moradas incompletas.
- Um beneficiário incorreto, uma rejeição parcial e um pagamento já transmitido.
- Um envio próximo da hora-limite e um incidente no canal.
- A receção dos estados, a sua interpretação pelas equipas e a reconciliação contabilística.
Adapte esta lista ao serviço bancário em causa. Utilize dados fictícios ou autorizados no ambiente de teste, segundo as condições acordadas com os parceiros.
6. Três provas antes da aprovação
A entrada em produção deve apoiar-se num perfil de destino confirmado pelo banco, em testes de aceitação completos aprovados pelas equipas de negócio e num procedimento de gestão de incidentes controlado. O objetivo é proteger os fluxos, tornar as anomalias visíveis e preservar a continuidade dos pagamentos.
Está a preparar uma migração de formatos ou um projeto TMS? Fale com a Précis Consulting sobre o âmbito e as prioridades do seu projeto.
Fontes e acompanhamento das alterações
Consulte as versões em vigor e a documentação fornecida pelos seus bancos antes de definir um calendário de produção.
