Escreves «autoriza as contas que vencem esta semana» e queres despachar trabalho, não abrir mais uma discussão. Mas, antes de alguém responder «feito», precisas de saber que contas entram nessa frase. As de que empresa? Só as pendentes de aprovação? Inclui uma fatura cuja mercadoria ainda não chegou?
Este é um cenário ilustrativo, não o relato de um incidente. É também um teste útil para qualquer assistente ligado ao teu ERP: consegue transformar um pedido vago numa lista que possas verificar, sem começar por alterar os registos?
A ordem correta é consultar, apresentar a seleção, obter aprovação e só depois executar a operação autorizada. A qualidade da conversa não substitui nenhuma destas etapas.
O número concreto: até 10 registos no Omie
A documentação do Omie sobre recursos financeiros por IA no WhatsApp, datada de 18 de março de 2026, descreve a aprovação de contas a pagar. Permite pedidos sem identificação individual das contas, mas estabelece um limite: se o pedido abranger mais de 10 registos, não será processado.
Isto demonstra que a ação financeira pelo WhatsApp já existe num ERP. Não precisamos de a apresentar como uma promessa futura. Também não devemos concluir que todos os produtos se limitam a responder a perguntas frequentes.
O limite merece, contudo, ser interpretado com precisão. Dez registos não são dez euros, nem uma garantia de baixo risco. Uma única conta pode ter um valor elevado. E a documentação desse limite não demonstra, por si só, uma pré-visualização obrigatória dos documentos ou uma confirmação associada à lista exata.
É aqui que começa o trabalho de integração: definir o que o pedido seleciona e o que a aprovação permite fazer. O fluxo que propomos neste artigo é um requisito de desenho, não uma descrição de controlos que o Omie documente ou de uma instalação Leiritech já em produção.
«Esta semana» é um filtro, não uma lista aprovada
Um operador usa linguagem natural porque conhece o contexto. O sistema não pode presumir que conhece o mesmo contexto.
«Esta semana» pode significar até sexta-feira ou até domingo. «As contas» pode significar todas as contas por pagar ou apenas as que aguardam autorização. Uma prestação pendente pode ter um saldo diferente do valor original da fatura. Se o assistente não tornar estas escolhas visíveis, duas pessoas podem concordar com a mesma frase e estar a aprovar coisas diferentes.
A primeira resposta deve, por isso, explicitar os critérios usados: empresa, intervalo de vencimento com datas concretas, estado dos registos e eventuais exclusões. Se faltar uma decisão que altere a seleção, pergunta antes de avançar.
Depois mostra os resultados com referências verificáveis: identificador do registo no ERP, fornecedor, documento, vencimento, saldo pendente, moeda e estado de aprovação. Um total ajuda a conferir, mas não substitui as linhas. Quando há moedas diferentes, os totais devem ficar separados, salvo se existir uma regra de conversão explícita.
A resposta deixa de ser «encontrei umas contas» e passa a ser uma seleção que consegues confrontar com o sistema de origem.
Um exemplo: 12 candidatas, quatro escolhidas
Imagina uma PME portuguesa a preparar o fecho de outubro. A 26 de outubro de 2026 faltam cinco dias para o fim do mês: uma razão prática para rever pendências, não uma obrigação de autorizar tudo à pressa.
O exemplo seguinte usa valores fictícios em euros e um ERP genérico. Não representa uma conta Omie nem resultados de um cliente.
A consulta encontra 12 contas que correspondem ao intervalo pedido. Num fluxo sujeito ao limite documentado do Omie, o pedido de aprovação das 12 não seria processado. O conector não deve contornar isso aprovando silenciosamente dez e depois duas. Também não deve escolher as primeiras dez como se fossem as mais importantes.
Mostra as 12 candidatas e pede uma seleção. Depois de reveres as pendências, escolhes quatro:
| Registo | Fornecedor ilustrativo | Documento | Saldo pendente |
|—|—|—|—:|
| CP-184 | Consumíveis do laboratório | FT-381 | 640 € |
| CP-191 | Manutenção das instalações | FT-905 | 1.200 € |
| CP-203 | Material de embalagem | FT-227 | 360 € |
| CP-208 | Serviço de transporte | FT-614 | 800 € |
O âmbito da aprovação fica concreto: quatro contas, 3.000 €, para passar de pendentes a autorizadas. As outras oito ficam fora desta operação. A confirmação deve identificar esta seleção, não repetir apenas o filtro «esta semana».
Esta distinção importa porque um filtro pode devolver resultados diferentes minutos depois. Se entretanto entrar outra fatura com o mesmo vencimento, ela não recebeu a tua aprovação. Executar novamente a pesquisa e autorizar tudo o que aparecer seria executar uma ordem diferente.
Uma confirmação deve apontar para uma seleção estável
Na implementação proposta, a preparação gera uma referência de operação associada aos identificadores das quatro contas e aos valores apresentados. Essa referência pode surgir num ecrã de revisão ou numa mensagem curta que permita abrir o detalhe num portal autenticado.
Quando confirmas, o sistema verifica novamente o estado dessas contas. Se uma tiver sido alterada, liquidada ou cancelada entretanto, não deve substituir a seleção nem fingir que nada mudou. Deve interromper a aprovação afetada e apresentar a diferença para nova decisão.
A proteção não pode depender apenas de uma instrução ao modelo para «ter cuidado». A camada que comunica com o ERP tem de recusar identificadores fora da seleção aprovada e impedir que uma confirmação antiga aprove documentos novos. A decisão sobre executar o conjunto como uma única operação ou aceitar resultados parciais depende das capacidades reais da API e das regras acordadas para o projeto.
Se forem possíveis resultados parciais, isso precisa de estar definido antes. Três contas autorizadas e uma recusada não são «quatro contas tratadas». São um resultado parcial que exige uma resposta explícita.
A prova necessária muda com o trabalho
A lista não serve apenas para conferir somas. Serve para tornar visível o motivo pelo qual cada conta está, ou não, pronta para autorização.
Num laboratório de calibração, a conta de um serviço subcontratado pode aguardar a aceitação desse serviço. Mostrar apenas fornecedor e vencimento esconde essa pendência. Se o estado de aceitação existir no sistema e a consulta estiver autorizada, pode acompanhar a linha; se não existir, o assistente deve dizer que não conseguiu verificá-lo.
Numa estrutura residencial para pessoas idosas, a aprovação de uma fatura de um fornecedor pode depender da conferência administrativa da entrega. Essa tarefa não exige expor dados clínicos dos residentes numa conversa financeira. O contexto apresentado deve ser suficiente para decidir sobre a conta, não uma cópia indiscriminada dos dados disponíveis.
No armazém, o documento do fornecedor e o registo de receção ajudam a confirmar se o material foi recebido. A ligação entre ambos tem de existir ou ser validada: o modelo não pode inventá-la porque as datas e os montantes parecem próximos.
Na faturação eletrónica, importa distinguir o estado fiscal do documento do estado interno da conta a pagar. Ter um documento emitido ou comunicado no sistema fiscal aplicável não demonstra que a despesa foi aprovada. São factos diferentes e devem aparecer separados quando forem relevantes para a decisão.
Estes são critérios a acordar com cada operação. Não são regras universais que uma IA possa impor ao laboratório, à residência ou ao armazém.
Consultar não dá permissão para autorizar
Um assistente grounded responde a partir dos registos reais que está autorizado a consultar. A linguagem natural ajuda a formular a pesquisa e a explicar resultados; não cria fornecedores, saldos ou estados que faltam na origem.
Na abordagem da Leiritech, o acesso conversacional ao ERP começa por ser read-only e auditado. Pode preparar a lista e mostrar as referências sem alterar contas. Se o projeto incluir autorizações, essa capacidade exige uma via de escrita separada, com permissões e aprovação próprias. Não resulta automaticamente de ligar o chat ao ERP.
Há, aliás, um primeiro passo útil sem escrita pelo assistente: preparar a seleção em modo de leitura e concluir a autorização no ecrã nativo do ERP. Resolve parte do trabalho sem fingir que o agente tem capacidades que ainda não foram implementadas.
Também é preciso separar três acontecimentos: autorizar uma conta, registar contabilisticamente um pagamento e executar uma transferência bancária. A documentação do Omie apresenta aprovação e registo de pagamento como recursos distintos. A aprovação descrita não demonstra uma transferência de dinheiro. A mensagem final deve nomear apenas o que foi verificado.
«Mas rever a lista tira a vantagem à automação»
Só se a revisão te obrigar a reconstruir o trabalho todo. O ganho procurado está em reunir os documentos certos, apresentar os estados e destacar o que falta decidir. Não está em retirar ao responsável a possibilidade de perceber o que vai autorizar.
É possível acordar regras para apresentar em conjunto contas semelhantes e destacar exceções. Mas o conjunto continua a precisar de âmbito verificável. Uma aprovação de 3.000 € sem saber a que documentos corresponde não fica melhor por ter sido dada numa conversa rápida.
No fim, o registo de auditoria deve permitir reconstruir a operação: critérios da consulta, seleção apresentada, identidade de quem aprovou, momento da aprovação e resultado devolvido por cada registo. Uma mensagem «concluído» sem correspondência com o ERP é apenas mais uma afirmação por confirmar.
O preço do bot não responde a esta pergunta
Na oferta consultada da 3HASH, publicada em junho de 2026, o site custava 15 €/mês e o WhatsApp acrescentava 10 €/mês: 25 €/mês, além de 100 € de configuração. Essa oferta descrevia atendimento e passagem à equipa, mas não documentava um conector ERP incluído nesse preço. Isso não demonstra incapacidade do fornecedor para desenvolver integrações.
Um bot de atendimento pode ser adequado ao seu objetivo. Para autorizar contas, a avaliação é outra: que registos consulta, como delimita a seleção, o que pode alterar e que evidência devolve. Nem um preço baixo prova falta de integração, nem um preço alto prova segurança.
Envia à Leiritech um exemplo anonimizado da tua lista de contas a pagar e a regra de autorização que usas hoje, para hello@leiritech.com. Esse é o ponto de partida para definir o que pode ser consultado, o que exige aprovação e como demonstrar o resultado antes de permitir qualquer escrita.
