A despesa já está aprovada. O técnico foi reembolsado. Porque é que o custo ainda não apareceu na faturação ao cliente?
A resposta pode estar numa associação que ninguém confirmou: a encomenda à qual aquela despesa deve ser refaturada. O recibo existe, o valor está certo e a aprovação interna também. Mas nada disso, por si só, identifica quem deve suportar o custo nem prova que esse custo chegou a uma fatura.
É neste intervalo que se distingue um assistente que responde bem de uma integração que consulta o teu ERP e identifica o passo em falta. Não precisas de uma conversa mais convincente. Precisas de saber onde ficaram os 120 € daquela deslocação.
Aprovar, reembolsar e refaturar são decisões diferentes
Aprovar uma despesa significa aceitar o registo no circuito interno. Reembolsar significa liquidar o valor devido ao colaborador. Refaturar significa repercutir um custo no cliente, de acordo com o que foi contratado e com as regras de faturação aplicáveis.
Podes ter as duas primeiras operações concluídas e a terceira por fazer. Também podes decidir, corretamente, que uma despesa não é refaturável: por exemplo, porque a deslocação já está incluída num preço fechado. Um sistema útil tem de distinguir uma omissão de uma condição comercial. Não deve transformar todas as despesas aprovadas em receita a cobrar.
Há ainda uma quarta fronteira: faturar não é receber. Uma linha incluída numa fatura confirmada não prova que o cliente pagou. Se a pergunta é «já recuperámos este custo?», a resposta deve indicar se estamos a falar de preparação da faturação, emissão do documento ou recebimento.
No Odoo, a aprovação não é o último passo
A documentação do Odoo 19 sobre refaturação de despesas descreve um circuito concreto. A categoria da despesa tem de permitir a refaturação, ao custo ou segundo o preço de venda configurado. O campo de cliente a refaturar exige escolher a encomenda de venda correspondente, não apenas reconhecer o nome do cliente.
Essa associação deve ser verificada antes de aprovar. Segundo a mesma documentação, a encomenda associada deixa de poder ser alterada depois da aprovação. Se o destino estiver errado, um assistente não deve tentar contornar o bloqueio: deve encaminhar a correção para o procedimento autorizado na instalação.
Outro detalhe importante: aprovar o relatório não faz, por si só, aparecer as despesas na encomenda. No procedimento documentado, isso acontece depois do lançamento contabilístico. Só depois se revêm as linhas na encomenda e se prepara a fatura, inicialmente em rascunho, antes da confirmação.
Este é o motivo para não aceitar «está aprovada» como resposta a «está pronta para faturar?». São estados diferentes. A versão, os módulos e as personalizações do teu ERP precisam de ser verificados; este circuito do Odoo não é uma garantia sobre qualquer instalação ou sobre outro produto.
Um exemplo: 120 € de deslocação, duas encomendas possíveis
Imagina um laboratório de calibração com uma deslocação para visitar duas instalações do mesmo cliente. A despesa considerada para este exemplo é de 120 €. Usamos esse valor como base ilustrativa de custo e refaturação, sem desenvolver IVA ou outros tratamentos fiscais.
O cliente tem duas encomendas abertas. A EC-104 cobre as intervenções dessa visita e permite cobrar a deslocação ao custo. A EC-117 corresponde a um contrato de assistência com deslocações incluídas. Os dois projetos da visita pertencem à EC-104.
O nome do cliente não resolve a escolha. A encomenda mais recente também não. Associar automaticamente os 120 € à EC-117 porque aparece primeiro pode preparar uma cobrança que o contrato não permite.
Há ainda a distribuição analítica. O Odoo 19 exemplifica uma divisão de 50% por cada um de dois projetos do mesmo cliente. Aplicada ao nosso exemplo, são 60 € de custo atribuídos a cada projeto: 120 € × 50% = 60 €.
Dividir o custo entre projetos não é o mesmo que escolher o destino comercial da refaturação. Aqui, ambos os projetos pertencem à EC-104. Uma repartição analítica correta não prova, só por si, que a encomenda foi bem escolhida, nem implica criar duas faturas ou repartir automaticamente a despesa por duas encomendas.
Antes da aprovação, a revisão deve confirmar o vínculo à EC-104, a regra comercial e a distribuição analítica. Se a despesa já estiver aprovada com outro destino, a resposta deve identificar a exceção, sem prometer uma edição que o circuito não permite.
Se estiver corretamente associada e aprovada, mas ainda sem lançamento contabilístico, os 120 € continuam numa etapa anterior à sua inclusão na encomenda. Depois do lançamento, a revisão deve encontrar o valor esperado nas linhas correspondentes. Uma eventual fatura em rascunho continua a não ser uma fatura confirmada.
O resultado útil não é uma frase genérica sobre despesas. É uma conclusão verificável: qual o registo, qual a encomenda, qual o montante e qual o passo que falta.
O que um assistente ligado aos dados deve conseguir mostrar
Uma pergunta operacional seria: «Que despesas desta visita estão aprovadas, mas ainda não chegaram à faturação da EC-104?»
Para responder, o sistema precisa de consultar os registos autorizados e relacionar despesa, relatório, encomenda e documentos de faturação. A identificação da visita tem de estar suportada por referências existentes. Se apenas existir uma descrição vaga como «ida ao cliente», pode ser necessário pedir esclarecimento.
O estado também tem de vir dos dados. Falta de permissão para consultar uma fatura não equivale a ausência de fatura. Uma consulta incompleta não permite concluir que o custo ficou por faturar. O assistente deve dizer o que conseguiu verificar e o que não conseguiu.
No nosso exemplo, uma resposta possível, caso os registos o confirmassem, seria: «A despesa de 120 € está aprovada e ligada à EC-104. Falta o lançamento contabilístico; ainda não está disponível na encomenda para preparar a faturação.» Isto é um exemplo de saída, não um resultado obtido numa instalação de cliente.
Uma consulta auditada deve permitir reconstruir quem perguntou, que referências e estados sustentaram a resposta e quando foram consultados. Acesso só de leitura significa precisamente isso: analisar e explicar sem alterar os documentos. O acesso conversacional ao ERP apresentado pela Leiritech parte dessa base, com dados do cliente e permissões controladas.
Se o âmbito incluir preparar documentos ou executar outras operações, há uma camada adicional a implementar. A consulta não se transforma numa autorização de escrita só porque a frase do utilizador contém «trata disso». A operação tem de respeitar a API, os estados permitidos, a autorização do utilizador e o registo do resultado. Aprovar, lançar e emitir documentos não são poderes implícitos do modelo.
O contrato muda conforme o trabalho, não conforme a conversa
Num laboratório, a deslocação pode ser refaturável numa encomenda e estar incluída noutra. Numa empresa que presta manutenção a uma unidade de saúde, o custo de uma visita pode depender do contrato de assistência. A associação deve apoiar-se na ordem de serviço e na encomenda, sem expor dados de utentes que não sejam necessários à tarefa.
Num serviço realizado num armazém, uma deslocação para reparar equipamento pode estar abrangida pela garantia ou ter sido autorizada como trabalho adicional. O recibo não decide isso. A regra comercial e os registos associados é que determinam se existe valor a faturar.
Na faturação eletrónica, ter identificado corretamente o custo também não dispensa o circuito fiscal e documental do sistema. Uma despesa ligada à encomenda certa ainda não é um documento emitido ou comunicado. A integração deve mostrar a fronteira entre estas etapas, não apagá-la com a palavra «concluído».
«Mas o meu ERP já faz isso»
Se faz, e a equipa consegue verificar o circuito sem esforço desproporcionado, talvez não precises de um agente para esta tarefa. A documentação do Odoo demonstra precisamente que a refaturação já existe. Não há razão para vender como invenção uma funcionalidade do ERP.
O trabalho de integração está em tornar verificável o percurso na tua instalação: como se identifica a intervenção, onde está a regra de refaturação, quem pode consultar cada documento e como se distinguem os estados. Um filtro nativo ou um relatório pode ser suficiente. A interface em linguagem natural só acrescenta valor se facilitar uma verificação correta sem enfraquecer os controlos.
A oferta de entrada da 3HASH consultada nesta investigação anuncia site e WhatsApp por 25 €/mês, com IVA incluído e 100 € de configuração. A página descreve respostas e encaminhamento, mas não especifica este circuito ERP. O mesmo fornecedor anuncia integrações empresariais noutra oferta. Não seria correto concluir que não as consegue construir.
A comparação séria é entre âmbitos e provas, não entre etiquetas de preço. Explicar ao colaborador como submeter um recibo é uma tarefa. Identificar que os 120 € estão aprovados, mas parados antes de chegar à EC-104, é outra. Nenhum preço, baixo ou alto, prova que a segunda está resolvida.
O teste deve terminar numa evidência, não numa promessa
Antes do fecho do mês, vale a pena percorrer uma amostra de despesas candidatas a refaturação. O dia 31 de outubro é uma referência de organização do mês civil, não um prazo fiscal universal.
Para cada despesa, a revisão deve conseguir justificar o destino comercial e localizar a etapa atual. No exemplo, os 120 € podem estar corretamente repartidos entre projetos e continuar por preparar para faturação. Também podem estar contratualmente incluídos e, portanto, não representar uma omissão.
A medida útil é o valor elegível que se consegue reconciliar com as encomendas e os documentos certos, juntamente com as exceções explicadas. Não é o número de mensagens respondidas. Não há aqui uma taxa de recuperação ou uma poupança prometida: isso só se calcula depois de observar os teus registos.
Envia para hello@leiritech.com um esquema anonimizado de uma despesa, da encomenda e dos estados do teu circuito. A partir daí, podemos delimitar o que uma consulta só de leitura consegue verificar e que operações, se necessárias, exigem um fluxo autorizado separado.
