"Fatura 1487": quem a encontra no teu ERP?

"Bom dia, a fatura 1487 está mal, o valor não bate com a encomenda."

É assim que a mensagem chega. Sem série, sem ano, sem tipo de documento. Às vezes é "a fatura de 1.200 euros de setembro". Às vezes é "a da semana passada". Às vezes o número que o cliente escreveu nem é o da fatura — é o da encomenda dele, ou o da guia que veio colada à palete.

No teu ERP, essa "1487" pode ser a FT 2026/1487 da série B (a que usas para vendas a revendedores), a FT A/1487 de 2025, a nota de crédito NC 2026/1487, ou não existir de todo para aquele cliente. Alguém no escritório abre o ERP, filtra por cliente, cruza com o valor, vê qual é, e responde. Quatro minutos, se correr bem. Multiplica pelas mensagens de uma segunda-feira de outubro, em plena corrida às encomendas de Natal.

É aqui que se vê a diferença entre um bot que responde bonito e um sistema que consulta o teu ERP.

Porque é que o número "nunca está certo"

Não é desleixo do cliente. É que o número que tu usas e o número que ele vê são coisas diferentes.

Em Portugal, desde que o ATCUD passou a ser obrigatório, cada documento tem uma série comunicada à AT, um código de validação dessa série e um número sequencial. O identificador completo é qualquer coisa como "FT B/1487" mais um ATCUD do tipo "CSDF7T5H-1487". O cliente lê o que lhe salta à vista: o 1487. Se tens três séries ativas (balcão, revenda, exportação), tens potencialmente três documentos 1487 no mesmo ano. Somando anos anteriores, notas de crédito e faturas-recibo, a ambiguidade é estrutural, não acidental.

E o problema não é só português:

• Faturação eletrónica no Chile: o cliente fala no "folio 1487", mas o folio só é único dentro do tipo de DTE. A factura electrónica (tipo 33), a factura exenta (34), a guía de despacho (52) e a nota de crédito (61) têm, cada uma, a sua numeração. "Folio 1487" sem tipo é meia informação.
• Calibração: o cliente pede "o certificado do paquímetro". Tu registas o instrumento pelo teu código interno e pelo número de série do fabricante; ele conhece-o pela etiqueta de inventário dele. Se tem doze paquímetros, qual?
• Armazém e logística: "a guia que veio na palete" é uma guia de transporte com o seu próprio número, ligada a uma encomenda com outro, faturada numa fatura com um terceiro.
• Saúde e lares: a família pergunta pela "fatura do mês da minha mãe" — e no ERP há a mensalidade, os medicamentos faturados à parte e uma nota de crédito por um dia de internamento hospitalar.

A pessoa do outro lado não tem de saber nada disto. Quem tem de saber é o sistema.

O que o bot de €25 faz com esta mensagem

Os bots básicos — €100 de setup e €25/mês, como algumas ofertas portuguesas que estão no mercado — são treinados na informação pública do negócio: horários, serviços, preços, perguntas frequentes. Vendem-se com uma promessa honesta: "nunca inventa". E é verdade. Perante "a fatura 1487 está mal", o melhor que um bot destes pode fazer é não inventar: "Vou passar a sua questão à nossa equipa."

Isso é segurança pela negativa. Não errar porque não se tenta. O cliente continua à espera, e a tua funcionária continua a fazer a mesma pesquisa no ERP que fazia antes do bot existir. Pagaste para mudar a porta de entrada da fila, não para encurtar a fila.

E atenção: preço alto também não prova integração. Há ofertas em Portugal a €200–400/mês, com €3.000 de setup, cujo escalão base continua a ser FAQ com limite de 500 conversas. A Meta One sobe de $14,99 para $499/mês, mas a escada sobe por capacidade e volume — não por ligações ao PHC ou ao Primavera. A pergunta certa a qualquer fornecedor não é "quanto custa", é "que sistemas lê e que ações executa".

O que um agente ligado ao ERP faz, passo a passo

Pega na mesma mensagem: "a fatura 1487 está mal, o valor não bate com a encomenda". Eis o que acontece num agente construído sobre os dados reais, read-only e auditado.

1. Identifica quem está a falar. O número de WhatsApp está associado a um contacto, e esse contacto a uma entidade com NIF no ERP. A partir daqui, toda a pesquisa fica limitada aos documentos dessa entidade. Isto não é um pormenor: é o que impede que o cliente A veja a fatura do cliente B só porque acertou num número.

2. Interpreta, sem inventar. O modelo de linguagem não procura faturas. Faz uma coisa mais pequena e verificável: extrai a intenção (reclamação de valor) e as pistas (número 1487, menção a uma encomenda). Transforma isso numa consulta estruturada.

3. Consulta o ERP. Procura documentos de venda daquela entidade cujo número sequencial seja 1487, em todas as séries e tipos, nos últimos dois anos. Em paralelo, procura encomendas com esse número, porque o cliente pode estar a falar da dele.

4. Decide pelo número de candidatos.

• Um candidato: responde com dados do documento — "Encontrei a FT B/1487 de 18 de setembro, €1.236,90, referente à vossa encomenda 4410. Qual é a linha que não bate?" — e abre o caso com o documento já associado.
• Vários candidatos: pergunta com aquilo que o cliente sabe, não com aquilo que tu sabes. Não diz "série A ou B?"; diz "Tenho duas faturas com esse número: uma de março, de €480, e uma de setembro, de €1.236,90. É qual?"
• Zero: diz que não encontra nenhum documento com esse número para a empresa dele, pede o valor ou a data, e passa a humano com tudo o que já tentou.

5. Regista tudo. Pergunta recebida, consulta executada, candidatos devolvidos, resposta enviada. Se amanhã alguém perguntar "porque é que o agente disse aquilo?", a resposta está no log, linha a linha.

A diferença para o bot de FAQ não está na simpatia da resposta. Está em que, quando a conversa passa para a tua equipa, o caso já chega com a FT B/1487 identificada, a encomenda 4410 ao lado e a linha em causa. A funcionária começa a resolver em vez de começar a procurar.

Porque é que "grounded" bate "esperto"

A objeção mais comum é: "E se o modelo inventa uma fatura?" É a objeção certa, e a resposta está na arquitetura, não na promessa.

Num sistema grounded, o modelo nunca produz o número da fatura, o valor ou a data. Esses campos vêm das linhas devolvidas pela consulta ao ERP, e a resposta só pode citar o que lá está. Se a consulta não devolve nada, não há nada para citar — e o agente diz isso. O modelo trata da linguagem; o ERP trata dos factos.

O acesso é read-only: o agente lê documentos, não os altera, não emite notas de crédito, não mexe em séries certificadas. Emitir documentos fiscais continua a ser trabalho do software certificado e de uma pessoa. O que muda é que a pessoa já não gasta os primeiros quatro minutos a descobrir de que documento se está a falar.

"Mas o meu ERP já tem pesquisa"

Tem, e é exatamente isso que o agente usa. A pesquisa não é a parte difícil. As partes difíceis são três, e é por elas que o trabalho custa mais do que €25/mês:

• Delimitar a identidade. Ligar um número de telemóvel a uma entidade, tratar o contabilista que fala por três empresas, e garantir que nenhuma pesquisa sai do perímetro daquele cliente.
• Desambiguar com as palavras do cliente. Saber que, na tua operação, "a da semana passada" quer dizer data de documento e não data de vencimento; que "o paquímetro" deve cruzar com a etiqueta de inventário do cliente; que "folio" sem tipo deve começar pelas facturas tipo 33.
• Auditar. Um log que aguenta uma auditoria ISO ou uma inspeção, não um histórico de chat.

Isto não se configura num painel de FAQ. Constrói-se sobre o teu modelo de dados — séries, tipos de documento, entidades, códigos internos — porque é lá que está a semântica que o cliente não conhece e não tem de conhecer.

Por onde começar

Não precisas de ligar o ERP inteiro ao WhatsApp. Começa por medir: durante uma semana, conta quantas mensagens chegam com um número de documento incompleto ou errado, e quanto tempo leva cada uma a ser identificada. Em outubro e novembro, com as encomendas de Natal a acumular, essa conta costuma ser esclarecedora.

Se o número justificar, o primeiro passo é pequeno e seguro: um agente read-only que só identifica documentos — faturas, guias, certificados — dentro do perímetro de cada cliente, com log completo. Sem escrita, sem emissão, sem tocar no que é certificado.

Se quiseres ver como isto ficaria sobre o teu PHC, Primavera ou ERP à medida, escreve-nos para hello@leiritech.com. Falas diretamente com quem escreve o código.