Integrar IA no ERP: Primavera, PHC, Sage e Dynamics

A integração de ERP com IA é onde a automação numa PME portuguesa deixa de ser uma demonstração e passa a poupar horas — e é também onde a maioria dos projetos encalha, porque o ERP é o sistema que ninguém pode dar-se ao luxo de estragar. A pergunta que os gestores nos fazem não é "a IA consegue?": é o que é que posso ligar ao meu Primavera ou ao meu PHC sem partir a contabilidade nem sair da lei. Este guia responde a isso ERP a ERP, começando pelo caso que vemos pedir mais vezes — lançar faturas de compra que chegam por email — e termina no que não se deve fazer, que em Portugal é a parte mais importante.

TL;DR:

• O caso que compensa primeiro é quase sempre contas a pagar: um fluxo que lê o email, extrai os dados da fatura em PDF e prepara o lançamento no ERP. É repetitivo, é de alto volume e o resultado mede-se em horas por mês.
• A superfície de integração varia muito por ERP e por versão — e é isso que determina o preço. Um Dynamics 365 Business Central tem API REST documentada publicamente; um PHC CS expõe um único web service SOAP que executa scripts que alguém tem de escrever do lado do PHC. Não são o mesmo projeto.
• A IA nunca deve emitir documentos fiscais. Em Portugal a faturação passa por software certificado pela AT, com ATCUD e comunicação de SAF-T. A IA prepara, classifica e propõe; quem emite e quem lança é o software certificado e uma pessoa.
• Regra prática: IA do lado da entrada de documentos (ler, extrair, classificar, propor) é território seguro e paga-se depressa. IA do lado da emissão de documentos fiscais é risco regulatório sem retorno.

O que é que a IA faz de facto num ERP — e o que não faz?

A IA não substitui o ERP: trata do trabalho que as pessoas fazem à volta dele. O ERP continua a ser o sistema de registo e continua a aplicar as suas regras. O que a IA faz bem é a camada de interpretação que hoje é feita por alguém a olhar para um documento e a escrever no ecrã: perceber que aquele PDF é uma fatura, de que fornecedor, com que linhas, que IVA, a que centro de custo pertence — e preparar o lançamento.

Vale a pena separar três coisas que são frequentemente vendidas como a mesma:

Quase todos os projetos reais de ERP são uma combinação dos três, escolhida processo a processo — e a escolha errada é a causa mais comum de custo a mais. Escrevemos o critério completo em RPA vs agentes de IA, e o enquadramento mais amplo de que processos atacar primeiro está no guia de automação de processos com IA.

Caso #1: lançar faturas de compra sem ninguém as escrever

É o caso com melhor relação esforço-retorno em praticamente todas as PME que vemos, porque o trabalho é diário, é repetitivo e o volume é previsível. O fluxo tem cinco passos, e é útil ver onde cada um pode falhar:

1. Receção. Uma caixa de correio dedicada (faturas@) recebe os PDFs dos fornecedores. O fluxo lê os anexos e ignora o resto do email. Onde falha: faturas no corpo do email em vez de anexo, e fornecedores que enviam vários documentos num só PDF.
2. Extração. Um modelo lê o documento e devolve campos estruturados: NIF do fornecedor, número do documento, data, base tributável por taxa de IVA, total, e as linhas quando são necessárias. Onde falha: PDFs digitalizados de má qualidade e tabelas com várias páginas. Um PDF nativo é muito mais fiável do que um scan.
3. Validação. Antes de tocar no ERP, o fluxo verifica o que é verificável por regra e não por modelo: o NIF existe na tabela de fornecedores, a soma das linhas dá o total, o IVA é uma taxa legal, o documento ainda não foi lançado. Onde falha: é o passo que as demonstrações saltam — e é o que separa um piloto de um sistema em produção.
4. Classificação. A IA propõe a conta e o centro de custo, aprendendo com o histórico de lançamentos daquele fornecedor. Onde falha: fornecedores novos e despesas ambíguas. É aqui que se define um limiar de confiança: acima dele propõe-se, abaixo dele encaminha-se para uma pessoa.
5. Lançamento em rascunho. O fluxo cria o documento no ERP em estado não contabilizado e uma pessoa confirma. Onde falha: quando alguém decide saltar a confirmação para "ganhar tempo" — ver a secção do que não fazer.

O que se ganha é tempo de tarefa, não pessoas: o trabalho passa de escrever cada fatura para revisar propostas, e o volume deixa de ser proporcional ao esforço. É o mesmo padrão que aplicámos na reconciliação financeira da Seed Real Estate, onde os workflows em n8n cruzam extratos bancários com faturas do InvoiceExpress e usam um modelo para categorizar as transações, com o Airtable como sistema de registo — o Excel deixou de ser onde a verdade vivia. Quem quiser ver como se constrói este tipo de orquestração tem o nosso guia de agentes de IA com n8n.

Se a vossa operação é um gabinete de contabilidade e não uma empresa a lançar as suas próprias faturas, o ângulo muda e está tratado em ideias de projetos de IA para contabilidade.

Como se liga a IA a cada ERP?

A resposta honesta é: depende menos da IA e mais de que ERP e que versão têm instalada. Esta é a tabela que costumamos preencher na avaliação técnica, antes de haver orçamento:

Primavera

O Primavera divide-se em dois mundos que não se devem confundir. O V10 tem uma Web API própria e, ao contrário da maioria dos ERP, essa API é extensível: a documentação mostra que se estende a Web API com controladores C# próprios — classes que herdam de ApiController, compiladas numa biblioteca e copiadas para a pasta WebApi\bin da instalação. É uma vantagem real, porque dá para expor exatamente a operação de negócio que precisam em vez de compor dez chamadas genéricas. E é ao mesmo tempo um custo: exige desenvolvimento .NET e acesso ao servidor, o que traz o parceiro Primavera para dentro do projeto. Os produtos cloud (Jasmin, Rose) expõem uma API REST organizada por áreas funcionais — Vendas, Compras, Inventário, Finanças, entre outras, listadas no índice de categorias da API. O arranque passa por registar uma conta e criar uma app no portal, com autenticação OAuth2, conforme o guia de iniciação.

Duas notas que poupam semanas. Primeiro, confirmem antes de orçamentar quais os endpoints que a vossa subscrição e versão expõem para o documento concreto que querem criar — "o Primavera tem API" e "o Primavera tem API para o que eu preciso" não são a mesma afirmação. Segundo, a Primavera BSS passou a integrar a Cegid, e a documentação para developers vive hoje em domínios cegid.com; links antigos redirecionam.

PHC

O PHC é o caso onde a versão muda o projeto todo, e é o mais mal compreendido. O PHC GO (cloud) tem uma API REST para developers, com dois níveis de acesso, e é o cenário confortável.

O PHC CS é outra história. A API é um web service SOAP num endereço com o padrão [url da aplicação]/ws/wscript.asmx, e expõe essencialmente uma operação — RunCode — que executa um script previamente registado dentro do PHC e devolve XML, conforme a documentação do PHC CS. A consequência prática é que não existe uma API orientada a recursos: para cada operação que quiserem, alguém tem de escrever e registar o script do lado do PHC. Isso significa duas competências no projeto — quem constrói a automação e quem sabe programar em PHC — e é a razão número um pela qual orçamentos para PHC CS aparecem mais altos do que o cliente esperava. Não é o fornecedor a inflacionar: é trabalho a mais que existe de facto.

Sage

Aqui vale mais a honestidade do que a certeza, e é deliberado não darmos aqui um endpoint. A Sage vende várias famílias de produto distintas e a superfície de integração difere por produto e por localização, pelo que documentação de API encontrada online pode descrever um produto ou um mercado que não é o vosso. A recomendação é chata mas é a correta: peçam ao parceiro Sage confirmação escrita de qual a API disponível na versão exata que têm instalada, e para que documentos, antes de qualquer orçamento. Enquanto a resposta for vaga, tratem a integração como o cenário de maior custo — e se alguém orçamentar sem essa confirmação, está a adivinhar.

Dynamics 365 Business Central

É o mais previsível de orçamentar, porque está documentado publicamente. A API v2.0 cobre as entidades de negócio, e para o nosso caso #1 interessa uma distinção que a própria Microsoft torna explícita: criar uma fatura de compra é um POST em purchaseInvoices, e contabilizá-la é uma ação separada (post) sobre esse documento.

Essa separação entre criar o documento e contabilizá-lo é exatamente a arquitetura correta para automação com IA — e o desenho que se deve replicar mesmo nos ERPs onde a API não a impõe. A automação cria; a pessoa contabiliza.

E se o ERP não tiver API utilizável?

Há três saídas, por ordem de preferência. Base de dados em leitura — muitos ERPs on-premise permitem uma vista de leitura sobre a base de dados, o que resolve o lado da consulta sem risco de escrita. Importação por ficheiro — pouco elegante e surpreendentemente sólida: a automação produz o ficheiro no formato que o ERP já importa, e o ERP faz a validação dele. RPA na interface, só como recurso último e com plano de substituição escrito, porque parte quando o ecrã muda.

O que NÃO fazer (a parte que em Portugal não é opcional)

Não ponham IA a emitir documentos fiscais. É a regra que resume esta secção. Em Portugal a emissão de faturas passa por software de faturação certificado pela AT, e há obrigações associadas que não são negociáveis: o ATCUD deve constar dos documentos fiscalmente relevantes, com as séries comunicadas previamente à AT para obter o código de validação — e a AT esclarece que o código QR é exigido nos documentos emitidos por programa certificado, conforme as FAQ sobre séries e ATCUD. Há ainda a obrigação de exportação e comunicação do SAF-T (PT). Nada disto se contorna com um fluxo automatizado — e a AT publica a lista dos programas certificados, que é onde se confirma o estado do vosso.

A leitura prática: o lado da entrada é seguro, o lado da emissão não é vosso. Ler, extrair, classificar, reconciliar e propor lançamentos de documentos que recebem — território livre e onde está o retorno. Emitir faturas, notas de crédito ou recibos fora do software certificado — não.

Os outros quatro erros que vemos repetir-se:

• Contabilizar automaticamente. Criem o documento em rascunho e deixem a confirmação a uma pessoa, pelo menos até terem meses de histórico que justifiquem outra coisa. Um erro de extração que fica em rascunho custa trinta segundos; contabilizado custa um lançamento de correção e uma conversa com o contabilista.
• Contornar as validações do ERP. Escrever diretamente na base de dados para "ir mais rápido" salta as regras de negócio que o ERP aplica e cria inconsistências que só aparecem no fecho. Se a API é lenta, a resposta é uma fila, não um INSERT.
• Não ter idempotência. Se o fluxo correr duas vezes — e vai, porque um email é reprocessado ou um webhook repete — tem de reconhecer que aquele documento daquele fornecedor já foi lançado. Faturas duplicadas são o modo de falha mais comum e o mais embaraçoso.
• Enviar dados pessoais para onde não devem ir. Faturas contêm dados de terceiros. Decidam antes de ligar nada onde é que os documentos são processados, e tratem essa decisão como um requisito de arquitetura, não como um detalhe de configuração.

Isto é informação geral e não aconselhamento fiscal ou jurídico — a situação concreta da vossa empresa deve ser confirmada com o vosso contabilista certificado.

Que processo do ERP automatizar primeiro? Um scorecard

Pontuem cada processo candidato de 1 a 5 em cada linha e somem. Acima de 20 vale a pena; abaixo de 14, deixem para depois.

Na prática, contas a pagar ganha este exercício quase sempre, e reconciliação bancária vem em segundo. Processos de emissão pontuam alto em volume e mal em custo do erro — o que é outra forma de chegar à mesma conclusão da secção anterior.

Quanto custa e quanto tempo leva?

Os números concretos dependem do ERP, da versão e da qualidade dos documentos, e qualquer fornecedor que dê um preço antes de ver isso está a adivinhar. O que se pode dizer com honestidade é onde o custo se concentra, e é isto que costumamos mostrar antes de orçamentar:

A conta que decide o go/no-go é simples: horas por mês gastas hoje no processo, vezes o custo horário, contra o custo de construir mais o custo de correr. Se não se paga em doze meses no volume atual — não no volume que esperam ter — a resposta honesta é esperar. Fazemos essa conta na avaliação e dizemos quando não compensa; o mapa do processo fica com vocês de qualquer forma. As ordens de grandeza por tipo de projeto estão em serviços de automação com IA: o que incluem e quanto custam.

E a fiabilidade — demo contra produção?

Uma demonstração de extração de faturas funciona sempre; é em produção que aparece a fatura que o modelo lê mal. A diferença não está no modelo, está na camada em volta: limiares de confiança que encaminham os casos duvidosos para uma pessoa, filas de erro que se conseguem reprocessar, alertas quando a taxa de exceções sobe, e registo de tudo o que foi proposto e por quem foi aprovado. Explicámos porque é que isto é o trabalho real em porque é que o vosso agente de IA não é fiável para escalar, e porque é que tantos pilotos morrem antes de chegar lá em porque os pilotos de IA não chegam a produção.

O caminho que funciona é sempre o mesmo: um fornecedor, em modo de sugestão, durante algumas semanas, com uma pessoa a comparar o que a automação propôs com o que ela teria feito. Só depois se alarga. Quem começa com todos os fornecedores e confiança total descobre os casos-limite na contabilidade, que é o pior sítio possível.

Perguntas frequentes

O meu ERP é antigo e não tem API. Ainda dá para fazer alguma coisa?

Sim, e é o caso normal. Por ordem de preferência: leitura direta à base de dados para a parte de consulta, importação por ficheiro no formato que o ERP já aceita para a parte de escrita, e só em último recurso automação pela interface. O que muda não é a viabilidade, é o custo e a fragilidade — e isso deve estar escrito no orçamento em vez de aparecer a meio do projeto.

A IA pode emitir faturas aos meus clientes?

Não é por aí que se deve ir. A emissão de documentos fiscais em Portugal passa por software certificado pela AT, com ATCUD e comunicação de SAF-T. A IA pode preparar tudo o que antecede a emissão — juntar os dados, propor as linhas, validar — e o documento deve ser emitido pelo software certificado. O retorno está do lado da entrada de documentos, não da emissão.

Quanto tempo até ver resultados nas contas a pagar?

Depende sobretudo da API do ERP e da qualidade dos PDFs, mas o marco que importa é anterior ao "resultado": ter o fluxo a correr em modo de sugestão sobre faturas reais, com uma pessoa a comparar. Se ao fim de algumas semanas nesse modo a taxa de propostas aceites sem correção não for confortável, o problema é de dados ou de regras — e é melhor descobri-lo aí do que depois de contabilizar.

Preciso de trocar de ERP para usar IA?

Quase nunca, e desconfiem de quem sugerir isso à primeira conversa. Trocar de ERP é um projeto de outra ordem de grandeza, com risco próprio, e a maioria dos casos de automação resolve-se ligando à instalação atual. A exceção honesta é quando o ERP não tem API nem importação viável e o volume é grande — aí a substituição pode ser mais barata do que a automação, e deve ser dito.

Quem é que trata das exceções depois de estar a funcionar?

Alguém tem de ser o dono, e é melhor decidir isso antes de construir. Na prática é a mesma pessoa que hoje lança as faturas: o trabalho dela passa de escrever tudo para revisar propostas e resolver o que a automação encaminhou. Se ninguém tiver esse papel atribuído, o fluxo acumula exceções em silêncio até deixar de ser confiável — e esse é um problema de organização, não de tecnologia.

Por onde começar

Escolham um processo — contas a pagar, na maioria dos casos —, confirmem o que a API do vosso ERP permite de facto criar, e corram-no em modo de sugestão antes de deixar qualquer coisa ser contabilizada automaticamente. É esse o trabalho dos nossos serviços de automação com IA, e a camada de ligação aos sistemas que já têm está descrita na página de integração com os sistemas que já usam.