Ficheiros de pagamento e reconciliação entre ERP e banco
ERP para banco: ficheiros de pagamento saem, extratos voltam, tudo reconciliado
Pagamentos enviados como ISO 20022 pain.001 por SFTP host-to-host ou APIs bancárias, com extratos camt.053 e MT940 reconciliados com o razão.
Blueprint
Role para o lado para ver o desenho completo.
ERP para banco: pagamentos saem, extratos entram
Pagamentos aprovados saem do ERP como ficheiros ISO 20022 assinados por um canal host-to-host. Relatórios de estado e extratos voltam pelo mesmo caminho e são reconciliados com os itens abertos. Rejeições e linhas não reconciliadas vão para a sua equipa com o motivo anexado.
- Fluxo principal
- Assíncrono
- Caminho de exceção
O fluxo em 10 etapas
O fluxo, etapa a etapa
- De ERP para Camada de integração: Lote de pagamentos aprovado, por REST/JSON · IDoc (fluxo principal).
- De Camada de integração para Canal bancário seguro: Ficheiro de pagamento assinado e encriptado, por ISO 20022 pain.001 · OpenPGP (fluxo principal).
- De Canal bancário seguro para Banco: Entregue ao banco, por SFTP H2H (fluxo principal).
- De Banco para Canal bancário seguro: Relatórios de estado e extratos, por pain.002 · camt.053 · MT940 (assíncrono).
- De Canal bancário seguro para Camada de integração: Recolhidos e validados, por SFTP H2H (assíncrono).
- De Camada de integração para Motor de reconciliação: Linhas do extrato, por camt.053 (assíncrono).
- De Motor de reconciliação para ERP: Lançamentos reconciliados registados, por REST/JSON (fluxo principal).
- De Camada de integração para Equipa de tesouraria e finanças: Pagamentos rejeitados, com o código de motivo, por pain.002 RJCT (caminho de exceção).
- De Motor de reconciliação para Equipa de tesouraria e finanças: Linhas não reconciliadas: uma divergência de reconciliação (caminho de exceção).
- De Equipa de tesouraria e finanças para ERP: Corrigidos e reenviados (caminho de exceção).
Visão geral
Este é o fluxo entre um ERP e os seus bancos: os pagamentos aprovados saem, e os relatórios de estado e os extratos voltam. É a ligação que a maioria das equipas de finanças ainda faz à mão, por portais bancários e folhas de cálculo, e aquela em que um erro custa dinheiro.
O desenho de referência coloca uma camada de integração entre o ERP e cada banco. A camada mapeia os pagamentos para a variante do banco do ISO 20022 pain.001, assina e encripta os ficheiros, e os entrega por SFTP host-to-host, EBICS ou pela API do banco. Relatórios de estado e extratos voltam pelo mesmo caminho e são reconciliados com os itens em aberto no ERP.
O caminho de falha é desenhado com o mesmo cuidado que o caminho feliz. Um pagamento rejeitado volta com o código de motivo do banco. Uma linha de extrato que não corresponde vira uma quebra de reconciliação para uma pessoa nomeada resolver. Nada é descartado e nada é lançado duas vezes.
Como o fluxo funciona
Aprovar o lote de pagamentos
O seu ERP gera o lote de pagamentos e os seus aprovadores o autorizam, como fazem hoje. A camada de integração só recolhe lotes aprovados.
Mapear, assinar e encriptar
A camada mapeia cada pagamento para a variante pain.001 do banco, valida o ficheiro e o assina e encripta conforme o banco exige.
Entregar ao banco
O ficheiro trafega pelo canal acordado, SFTP host-to-host, EBICS ou a API do banco, antes do horário limite do banco.
Receber estado e extratos
O banco devolve relatórios de estado pain.002 para cada ficheiro e pagamento, e extratos camt.053 ou MT940 no fim do dia.
Recolher e validar
A camada recolhe cada relatório, verifica lacunas e duplicidades frente à sequência de extratos e o converte em linhas.
Reconciliar e lançar
As linhas de extrato são reconciliadas com os itens em aberto pelas regras que aprovou, e os lançamentos reconciliados são registados no ERP.
Quando algo falha
Um pagamento é rejeitado
O relatório pain.002 traz o código de motivo do banco. O pagamento é marcado como rejeitado no ERP e enviado à sua equipa de tesouraria para correção e reenvio.
Uma linha de extrato não corresponde
A linha vira uma quebra de reconciliação com os candidatos prováveis e o motivo da falha. A sua equipa a resolve, e as regras podem aprender com ela.
Um ficheiro está ausente ou atrasado
Os números de sequência dos extratos e os horários esperados de entrega são verificados. Um ficheiro ausente ou atrasado gera um alerta antes que alguém confie na posição de caixa.
Uma chave ou certificado está perto de expirar
Chaves de assinatura e certificados de canal são acompanhados com as suas datas de expiração, e a renovação começa cedo o bastante para acordar a nova chave com o banco.
Normas e sistemas
- Normas e canais bancários
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
Perguntas e respostas
Host-to-host, EBICS ou APIs bancárias: qual devemos usar?
Normalmente o banco decide. O SFTP host-to-host é o canal mais amplamente oferecido para ficheiros de pagamento corporativos. O EBICS é comum em bancos da Alemanha, da França e de países vizinhos. As APIs bancárias servem para saldos em tempo real e pagamentos instantâneos onde o banco as oferece. Muitas empresas usam mais de um canal, e a camada de integração esconde a diferença do ERP.
Devemos receber extratos camt.053 ou MT940?
Onde o banco oferece os dois, o camt.053 traz dados de remessa mais ricos e estruturados, o que torna a reconciliação automática mais fiável. O MT940 ainda é muito usado e funciona bem em muitos casos. Conseguimos receber os dois, convertê-los para o mesmo modelo interno e migrar cada banco do MT940 para o camt.053 quando for conveniente para si e para o banco.
Podemos ver a nossa posição de caixa durante o dia?
Sim, se os seus bancos fornecerem relatórios intradiários. Eles chegam como mensagens camt.052 ou MT942, ou por uma API de saldo. Recolhemos esses dados no calendário que cada banco suporta e os mostramos ao lado dos extratos de fim de dia, para que a sua equipa de tesouraria veja as posições esperadas e as efetivas antes dos horários limite.
Podemos seguir quem aprovou e enviou um pagamento?
Sim. A aprovação permanece no seu ERP, com os controlos existentes. A camada de integração regista cada ficheiro que cria, assina, envia e recebe, com timestamps, identificadores e a conta técnica usada. Esse log liga cada pagamento do relatório de estado do banco de volta ao documento do ERP e aos seus aprovadores.
Temos vários bancos. Cada um é um projeto separado?
Não. A camada de integração, o modelo interno de pagamentos e as regras de reconciliação são construídos uma única vez. Cada novo banco acrescenta a sua própria variante de formato, canal e etapas de credenciamento, que são peças menores de trabalho. Normalmente ligamos primeiro o banco com maior volume e acrescentamos os outros em ordem.
Como a ligação é testada antes de entrar em produção?
Cada banco fornece um ambiente de testes ou um processo de teste. Acordamos um conjunto de casos de teste com o banco, a cobrir cada tipo de pagamento, rejeições e extratos, executamos e guardamos as evidências. Quando o banco aprova, entramos em produção com um primeiro lote pequeno de pagamentos e comparamos os resultados antes de migrar o restante.
Comece com uma conversa, não com um contrato.
Conte o que precisa construir, ligar ou proteger. Um arquiteto analisa consigo e recomenda por onde começar.
O que acontece a seguir
Definição do horário
A nossa equipa envia um e-mail para combinar o horário da sessão.
Sessão de pré-consultoria
Uma sessão em linha gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Numa avaliação de prontidão gratuita de 48 horas, um Arquiteto Principal verifica o seu projeto com a Definição de Prontidão em 6 pontos e recomenda o percurso adequado.
Escolha do percurso
Projetos com âmbito pronto recebem uma proposta vinculante em 3–5 dias úteis. Projetos em estágio de conceito começam no Blueprint Studio. Um sistema em produção com falhas, não documentado ou que precisa de integração começa com um diagnóstico de 1–2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.