Boleto prorrogado no ERP: falta confirmar no banco
«Já mudei a data. Porque é que o banco continua com o vencimento antigo?»
É a pergunta que o teu processo de cobrança tem de conseguir resolver antes de um assistente responder ao cliente: «Está tratado.» Uma data mudou no ERP. Isso não significa, por si só, que o boleto tenha sido prorrogado, nem que a instrução necessária tenha chegado ao banco.
Se a tua operação inclui cobranças no Brasil, esta diferença importa. O boleto é um instrumento de cobrança brasileiro; não estamos a descrever uma referência Multibanco portuguesa. Uma equipa em Portugal que acompanha uma empresa brasileira precisa de respeitar o processo dessa cobrança, não de traduzir o nome de um campo.
O problema não é o tom da resposta no WhatsApp. É saber que alteração foi feita, em que sistema e com que prova.
Uma previsão não é uma instrução ao banco
A documentação do Omie, no artigo «Prorrogando o vencimento de um boleto gerado», é explícita: alterar a previsão de recebimento da conta a receber não prorroga o vencimento do boleto. Existe uma operação própria para essa prorrogação.
A distinção faz sentido. A previsão de recebimento serve para representar quando esperas receber. O vencimento do boleto pertence às condições da cobrança. Podes prever que um cliente pagará mais tarde sem teres renegociado ou alterado essas condições. Se um assistente tratar os dois campos como sinónimos, transforma uma estimativa interna numa promessa externa.
A mesma documentação distingue os circuitos bancários. No Omie.CASH, indica que não é necessária uma nova remessa com a instrução de alteração. Para outros bancos, depois da alteração no Omie, é necessário enviar uma remessa com essa instrução. Acrescenta que algumas carteiras de cobrança não suportam a alteração pelo sistema e que eventuais taxas devem ser verificadas com o banco.
Portanto, «está no Omie» ainda não responde a «está resolvido no banco». E «remessa enviada» também não deve ser usada como sinónimo de «alteração aceite» sem uma evidência que sustente essa conclusão.
Há aqui um limite importante da fonte: o artigo descreve o procedimento e a confirmação no ecrã, mas não documenta um mecanismo universal de confirmação bancária. O projeto de integração tem de identificar essa evidência para o banco e a carteira concretos. Não a pode inventar.
Um exemplo: R$ 4.800 que continuam com a data antiga
Considera este cenário ilustrativo, não um caso de cliente: uma distribuidora brasileira tem um boleto de R$ 4.800, com vencimento em 30 de outubro de 2026. No dia 28, o cliente pede para pagar a 6 de novembro. A equipa aceita o pedido comercialmente e muda a previsão de recebimento para essa data.
A previsão de tesouraria passa a refletir o recebimento esperado em novembro. Mas, se foi apenas esse campo que mudou, o vencimento do boleto não foi prorrogado. Um assistente que consulte só a previsão pode responder «o prazo foi alterado para 6 de novembro» e dar por concluído um trabalho que ainda não aconteceu.
No fecho de outubro, a diferença deixa de ser uma questão de linguagem: uma equipa está a olhar para a previsão de caixa e outra para as condições da cobrança. Nenhuma das duas datas é necessariamente um erro. O erro está em apresentá-las como se fossem o mesmo facto.
Para um banco diferente de Omie.CASH, quando a carteira suporta o procedimento documentado, o fluxo inclui a operação de prorrogação no ERP e o envio da remessa de alteração. Depois, a integração precisa de distinguir o que conseguiu observar do que ainda está por confirmar.
Podemos representar esse acompanhamento assim. Os estados abaixo são uma proposta de desenho do processo, não nomes de estados oficiais do Omie.
| Evidência disponível | Estado que podes comunicar |
| — | — |
| Apenas a previsão passou para 6 de novembro | Previsão atualizada; prorrogação do boleto não demonstrada |
| Operação de prorrogação registada no ERP; instrução ainda por enviar, quando exigida | Alteração no ERP; envio bancário pendente |
| Remessa enviada, sem evidência suficiente do resultado | Instrução enviada; confirmação bancária pendente |
| Evidência bancária confirma a alteração do título certo | Novo vencimento confirmado pela evidência recolhida |
| Instrução rejeitada ou procedimento não suportado | Prorrogação não concluída; intervenção necessária |
Esta separação permite responder com precisão mesmo antes do fim: «A alteração está registada no ERP. A instrução ao banco ainda está pendente.» Não é uma resposta menos útil. É uma resposta que não cria uma garantia falsa.
Primeiro consultar; só depois permitir uma escrita
O primeiro passo de um assistente ligado ao ERP deve ser de leitura: identificar a empresa, o cliente autorizado e o título certo, consultar os dados disponíveis e apresentar as diferenças. No exemplo, interessa mostrar o vencimento atual, a previsão de recebimento, o banco ou carteira relevante e a nova data pedida.
O modelo de linguagem ajuda a interpretar o pedido. Não deve decidir sozinho que encontrou o título correto porque o nome do cliente se parece com o de uma conversa anterior. A identificação tem de assentar nos registos e nas referências do sistema, com acesso limitado ao âmbito do utilizador.
Se o acesso é só de leitura, o assistente pode explicar o que falta e encaminhar o pedido. Não pode prorrogar o boleto. Consultar o ERP e escrever no ERP são permissões diferentes, mesmo quando aparecem na mesma conversa.
Para executar, propomos uma operação separada, com autorização explícita e parâmetros delimitados: aquele título, aquela data e aquele circuito suportado. A camada de execução valida as regras aplicáveis e volta a consultar o estado relevante antes de alterar. Se, entretanto, o título tiver sido liquidado ou o pedido já não for válido, não deve executar às cegas.
Isto é um requisito de arquitetura, não a afirmação de que a Leiritech já tem este conector instalado no teu banco. Também não basta descobrir uma chamada de API que altera um campo: é preciso confirmar que a interface suportada executa a operação de negócio pretendida.
A prova tem de acompanhar a operação
Para investigar uma prorrogação, um registo com «sucesso» é pobre. Sucesso de quê? Da interpretação da mensagem, da alteração local, da preparação do ficheiro ou da aceitação da instrução?
O registo de auditoria deve permitir reconstruir o pedido: quem o fez, que título foi selecionado, quais eram os valores anteriores, que nova data foi aprovada e que resposta devolveu cada sistema. Quando existir um identificador de remessa ou outra referência do envio, deve ficar associado à operação. A evidência bancária disponível também, respeitando os acessos e a proteção dos dados.
Se houver uma falha de comunicação depois do envio, o resultado pode ficar desconhecido. Não é correto chamar-lhe rejeição, mas também não é correto anunciar conclusão. Antes de repetir uma operação, a equipa ou o conector deve reconciliar o estado com os mecanismos disponíveis para aquele circuito.
É esta informação que torna possível uma conversa útil com a tesouraria. Em vez de «a IA disse que estava feito», tens um pedido identificável, uma instrução e um resultado verificável — ou uma pendência claramente atribuída.
Mas o Omie já permite pedir isto pelo WhatsApp
Sim. A documentação «Finanças: Recursos no ERP integrados via IA no WhatsApp», consultada nesta investigação, inclui a funcionalidade de prorrogar boletos de contas a receber. Não seria sério dizer que todos os assistentes apenas respondem a perguntas, ou que um ERP nunca oferece ações no próprio canal.
A pergunta de compra é outra: essa funcionalidade cobre o teu banco, a tua carteira e a confirmação de que precisas? A página sobre WhatsApp não demonstra, por si só, envio automático de remessa e aceitação bancária para qualquer configuração. Essa cobertura deve ser verificada, não presumida.
Se a função nativa já resolve o circuito completo, com os controlos e a evidência necessários, não precisas de construir uma segunda versão. A integração à medida justifica-se quando há uma lacuna concreta, não porque a interface tem uma conversa mais elegante.
O mesmo cuidado vale para a comparação de preços. Na oferta pública da 3HASH consultada em outubro de 2026, o site custa 15 €/mês e o WhatsApp acrescenta 10 €/mês, além de 100 € de configuração. Essa descrição não documenta um conector ERP incluído nos 25 €. Isso não prova incapacidade do fornecedor; prova apenas que não deves comprar uma operação financeira com base numa descrição de atendimento.
O preço de entrada não é um teste de competência. Uma demonstração com o teu processo é.
O que a IA precisa de saber — e o que precisa de consultar
Um assistente com documentação pode explicar como se prorroga um boleto. Para afirmar que o teu boleto foi prorrogado, precisa de consultar o estado da operação e a respetiva evidência.
Esta é a diferença entre responder a partir de instruções gerais e responder com base nos dados reais do teu sistema. Um manual descreve o procedimento possível. Não demonstra que alguém o executou hoje, para aquele título, nem que o banco aceitou a alteração.
Por isso, o teste não deve terminar na frase «boleto prorrogado». Deve incluir uma previsão alterada sem prorrogação, uma instrução ainda por enviar e um resultado bancário pendente ou rejeitado. O assistente deve distinguir esses casos sem os converter todos em sucesso. No percurso concluído, deve conseguir mostrar a origem da confirmação a quem tem autorização para a consultar.
Não há aqui uma promessa de cobrar mais depressa ou de eliminar custos bancários. Há um objetivo mais concreto: impedir que a tua equipa comunique uma conclusão que os sistemas ainda não sustentam.
Começa por um boleto, não por uma apresentação comercial
Escolhe um único circuito de cobrança e define o que conta como concluído: a alteração no ERP, a instrução ao banco e a evidência final, conforme o processo aplicável. Só depois faz sentido decidir o que pode ser automatizado e quem autoriza a execução.
Envia para hello@leiritech.com um exemplo anonimizado desse circuito, indicando o ERP, o banco e a carteira, sem dados pessoais nem credenciais. O ponto de partida é descobrir o que falta entre «mudei a data» e «posso confirmar ao cliente».
