Integrar o ERP com a Loja Online: Guia Técnico Para Empresas Portuguesas (2026)

Já explicámos porque é que a integração ERP decide o projeto num portal B2B. Este artigo é o nível seguinte: a mecânica técnica e fiscal de ligar o ERP à loja online em Portugal — e as decisões que, tomadas fora de ordem, condenam o projeto antes de começar.

---

Há uma diferença enorme entre ter uma loja online e ter uma operação de e-commerce. A diferença chama-se, quase sempre, integração de sistemas.

Enquanto alguém tiver de abrir um ficheiro Excel ao final do dia para acertar stocks, ou copiar encomendas do painel da loja para o Primavera à mão, o negócio não está a crescer — está apenas a acumular trabalho administrativo proporcional às vendas. E esse é precisamente o tipo de crescimento que ninguém quer.

O Que Significa Realmente "Integrar o ERP com a Loja Online"

O erro mais comum começa aqui: tratar a integração como uma coisa só. Não é. São cinco fluxos de dados distintos, cada um com regras próprias, sentido próprio e — este é o ponto crítico — periodicidade própria.

Artigos e preços. O ERP é a fonte de verdade e a loja recebe. Nunca ao contrário.

Stock. O fluxo mais sensível de todos, porque é o único onde um atraso de minutos se transforma diretamente em vendas de produtos que já não existem.

Encomendas. Cada encomenda paga tem de dar origem a um documento no ERP, com o cliente certo, os artigos certos e os valores certos ao cêntimo.

Clientes. Novos registos na loja criam entidades no ERP, e alterações de dados fiscais têm de propagar-se nos dois sentidos sem gerar duplicados.

Documentos fiscais. Faturas, notas de crédito e recibos que voltam para a área de cliente e para o email do comprador.

Aplicar o mesmo padrão de sincronização a estes cinco fluxos é a causa silenciosa da maior parte das integrações que "funcionam mas dão problemas". Uma sincronização noturna é perfeitamente adequada para atualizar fichas de clientes. Aplicada ao stock durante uma campanha de Black Friday, é a receita garantida para vender aquilo que já não tem.

As Três Abordagens Possíveis

1. Plugin ou Conector Nativo

Muitos softwares de faturação portugueses — Moloni, InvoiceXpress, Vendus — disponibilizam ligações prontas a WooCommerce, Shopify e PrestaShop. Instala-se, configura-se, funciona.

É a opção certa quando o catálogo é simples, existe um único armazém, os preços são iguais para todos os clientes e as regras de IVA são as normais. Para uma boa parte das lojas portuguesas, isto chega — e recomendar mais do que isto seria vender complexidade desnecessária.

Os limites aparecem depressa quando o negócio tem particularidades: preços por cliente, artigos com variantes que o ERP não modela da mesma forma, vendas para vários países com taxas diferentes, ou a necessidade de decidir quando se emite a fatura em vez de aceitar o comportamento que o plugin traz de origem.

2. Middleware ou Conector Comercial

Existe um mercado estabelecido de integradores em Portugal que ligam Primavera, PHC, Sage e Eticadata às plataformas de e-commerce mais comuns. Compra-se uma licença, configura-se o mapeamento e há suporte do outro lado quando algo corre mal.

Faz sentido para operações de média dimensão com um ERP instalado e processos relativamente convencionais. A troca é sempre a mesma: ganha-se tempo de implementação e suporte, perde-se controlo sobre o comportamento em casos fora do padrão — e os casos fora do padrão são exatamente aqueles que distinguem um negócio do outro.

3. Integração à Medida

Desenvolvimento sobre as APIs de ambos os lados, com uma camada intermédia própria que faz o mapeamento, a fila de mensagens, a repetição de operações falhadas e o registo de tudo o que acontece.

Justifica-se quando existem regras de negócio que nenhum conector genérico modela, quando há mais do que dois sistemas envolvidos (loja, ERP, CRM, plataforma logística, marketplace), ou quando o volume torna o desempenho e a fiabilidade um requisito e não um detalhe. É também o cenário em que uma arquitetura headless compensa: a camada de integração evolui sem obrigar a reescrever a loja.

O critério de decisão não é o orçamento disponível. É este: existe alguma regra do negócio que um conector genérico não consegue representar? Se não existe, um conector é a escolha profissional. Se existe, forçar um conector significa adaptar o negócio ao software — e isso paga-se todos os dias, para sempre.

A Pergunta Que Quase Ninguém Faz Primeiro: Quem Emite a Fatura?

Antes de discutir tecnologia, há uma decisão que condiciona toda a arquitetura e que é frequentemente deixada para o fim: o documento fiscal é emitido pela loja ou pelo ERP?

Em Portugal, qualquer documento fiscalmente relevante tem de sair de software certificado pela Autoridade Tributária, com série comunicada, código ATCUD e QR Code. Isto elimina imediatamente a hipótese de a loja online gerar faturas por conta própria, a não ser que a própria plataforma esteja certificada.

Na prática, restam dois desenhos:

O ERP emite. A loja regista a encomenda e o pagamento, envia os dados para o ERP e recebe de volta o PDF e os identificadores fiscais. É o desenho correto para a esmagadora maioria dos casos, porque mantém uma única fonte de numeração e um único ponto de conformidade.

Um serviço de faturação intermédio emite. Moloni, InvoiceXpress ou Vendus recebem a encomenda, emitem o documento certificado e, em paralelo, alimentam a contabilidade. Faz sentido quando não existe ERP instalado, ou quando o ERP existente não é o sistema onde a faturação vive.

Definir isto no primeiro dia evita a situação mais desagradável que se pode encontrar numa auditoria: duas numerações a correr em paralelo para o mesmo tipo de documento.

Especificidades Portuguesas Que Condicionam a Integração

Um conector desenhado para o mercado internacional não conhece nada disto. É aqui que as integrações genéricas se partem.

Séries e ATCUD. Cada série tem de ser comunicada à AT para receber o código de validação, e é esse código que permite construir o ATCUD. Uma integração que crie documentos sem série corretamente comunicada produz documentos inválidos — em série, e sem avisar.

SAF-T de faturação até ao dia 5. O ficheiro relativo às faturas de um mês tem de chegar à AT até ao dia 5 do mês seguinte, com coimas entre 50 € e 1500 € por incumprimento ou entrega com erros. Se a integração cria documentos no ERP com dados incompletos, o problema só se manifesta no momento da submissão, quando já é tarde para corrigir com calma.

O NIF como chave de ligação. É a prática habitual em Portugal e funciona bem — até deixar de funcionar. Consumidores finais que não fornecem NIF, o NIF genérico 999999990, empresas com várias moradas de entrega e clientes que se registam duas vezes com dados ligeiramente diferentes são todos casos que têm de estar resolvidos por escrito antes de se escrever a primeira linha de código.

IVA e vendas para a União Europeia. Acima de 10 000 € anuais de vendas à distância para outros Estados-Membros, aplica-se a taxa do país do consumidor e há obrigações declarativas via balcão único (OSS). A loja tem de calcular a taxa certa, e o ERP tem de receber a venda classificada corretamente. Uma integração que assuma sempre 23 % gera trabalho de correção manual todos os trimestres.

Faturação eletrónica em 2027. As faturas em PDF continuam válidas ao longo de 2026. A partir de 1 de janeiro de 2027, passa a ser exigida assinatura ou selo eletrónico qualificado, e o formato estruturado CIUS-PT para quem trabalha com o Estado. Vale a pena confirmar hoje que a arquitetura escolhida acompanha essa transição sem ter de ser refeita.

Os Seis Pontos Onde Estas Integrações Falham

1. Códigos de artigo que não coincidem. A loja e o ERP representam o mesmo produto com identificadores diferentes, e sem uma tabela de mapeamento fiável as encomendas ligam-se silenciosamente ao artigo errado. Variantes de tamanho e cor são onde isto acontece com mais frequência, porque quase nenhum ERP as modela como a plataforma de e-commerce as modela.
2. Sincronização em lote aplicada ao stock. Funciona durante meses e falha exatamente no dia de maior faturação do ano. O stock precisa de um padrão diferente do resto: atualização por evento, e não por horário.
3. Ausência de idempotência. Se a loja reenvia uma encomenda porque não recebeu confirmação, e o ERP a processa como nova, fica um documento duplicado. O mesmo acontece ao contrário, com ajustes de stock aplicados duas vezes. Cada mensagem tem de trazer um identificador único e cada lado tem de saber ignorar o que já processou.
4. Arredondamentos e IVA calculados de forma diferente nos dois sistemas. A loja calcula sobre o total da linha, o ERP calcula linha a linha, e o documento fica a divergir um cêntimo da encomenda. Parece irrelevante até ser preciso justificar a diferença numa conciliação bancária com centenas de encomendas.
5. Portes, descontos e vales tratados como se não fossem linhas. São, para efeitos fiscais. Cada um precisa de artigo próprio no ERP, com a sua taxa de IVA, sob pena de o documento não fechar pelo valor efetivamente cobrado.
6. Webhooks tratados como garantidos. Não são. O Shopify repete o envio se o destino não responder com 200 em cinco segundos, mas há sempre casos em que a notificação simplesmente não chega. Sem um mecanismo de reconciliação periódica que compare os dois lados e detete o que ficou por processar, uma encomenda perdida só é descoberta quando o cliente telefona.

O Que Muda Consoante o Sistema

Primavera. A V10 disponibiliza uma API que cobre os módulos funcionais do produto e permite consultar e escrever — clientes, artigos e documentos de venda incluídos. É a base sobre a qual assentam praticamente todos os integradores do mercado português.

PHC. O PHC GO expõe uma API REST com planos de limite de pedidos, e o PHC CS oferece a framework para invocar serviços externos. A gestão do limite de chamadas tem de entrar no desenho desde o início, sobretudo em cargas iniciais de catálogo.

Sage. Existem integrações estabelecidas com as plataformas mais comuns, com o cuidado habitual de perceber qual das linhas de produto está em causa antes de assumir capacidades.

Moloni, InvoiceXpress e Vendus. APIs modernas e bem documentadas, pensadas para este caso de uso concreto. O Moloni trabalha sobre OAuth 2.0 e o InvoiceXpress usa chave de API. Para quem não tem ERP instalado, são frequentemente a resposta mais sensata — e a mais rápida a pôr em produção.

Do lado da loja, há uma diferença que importa: o Shopify impõe limites de chamadas apertados nos planos base e está a mover o desenvolvimento para a API GraphQL, com a REST em modo legado. Catálogos grandes exigem operações em bloco. O WooCommerce não impõe esses limites, mas em contrapartida o desempenho depende inteiramente do alojamento — e uma carga inicial mal desenhada consegue deitar abaixo um servidor partilhado sem grande esforço.

O Que Faz o Custo Subir ou Descer

Sem entrar em valores, estes são os fatores que determinam o esforço de um projeto de integração — e vale a pena conhecê-los antes de pedir propostas, porque são exatamente as perguntas que um bom fornecedor vai fazer:

• Número de fluxos. Só encomendas para o ERP é um projeto. Cinco fluxos bidirecionais é outro completamente diferente.
• Sentido da sincronização. Unidirecional é substancialmente mais simples do que bidirecional, porque não há conflitos para resolver.
• Qualidade dos dados de partida. Catálogos com códigos inconsistentes, artigos duplicados ou famílias mal estruturadas consomem mais tempo em limpeza do que em desenvolvimento.
• Complexidade do modelo de artigos. Variantes, lotes, números de série e unidades de medida diferentes entre sistemas multiplicam o trabalho de mapeamento.
• Multi-armazém e multi-canal. Vender no site, em marketplaces e em loja física a partir do mesmo stock é um problema de outra ordem de grandeza.
• Regras comerciais. Preços por cliente, escalões de quantidade, campanhas e condições de pagamento a prazo.
• Requisitos de tempo real. Sincronizar de hora a hora e sincronizar ao segundo são arquiteturas distintas, com custos distintos.
• Estado da API do ERP. Versões antigas sem API moderna obrigam a caminhos alternativos, e é frequentemente aqui que os projetos crescem sem que ninguém tivesse previsto.

Checklist Antes de Avançar

Antes de contratar seja quem for, tenha resposta para isto:

• Quem emite o documento fiscal, e em que momento exato do processo?
• Qual é a chave de ligação entre cliente da loja e entidade do ERP, e o que acontece quando não há NIF?
• Quais dos cinco fluxos são realmente necessários na primeira fase?
• Qual é a latência aceitável para o stock — e essa resposta muda em campanha?
• O que deve acontecer quando o ERP está offline? A loja para de aceitar encomendas ou acumula para enviar depois?
• Como é que alguém percebe que a integração falhou, sem ser através de uma reclamação de um cliente?
• Vende para fora de Portugal? Está em OSS?
• Quem fica responsável pela monitorização depois do arranque?

A última pergunta é a que mais projetos condena. Uma integração não é uma obra que se entrega e se esquece: é infraestrutura viva, que se parte quando o ERP é atualizado, quando o tema da loja muda ou quando alguém acrescenta um campo obrigatório num formulário. Sem alguém a olhar para os registos e sem alertas automáticos, o problema é sempre descoberto pelo cliente — que é a pior forma possível de o descobrir.

Em Resumo

Integrar o ERP com a loja online não é instalar um plugin. É decidir quem manda em cada dado, com que frequência, e o que acontece quando algo corre mal — porque vai correr.

Feito bem, elimina trabalho administrativo que crescia ao mesmo ritmo das vendas, corta os erros de stock e garante que a conformidade fiscal deixa de depender de alguém se lembrar de fazer alguma coisa. Feito à pressa, cria uma segunda fonte de verdade que ninguém sabe qual é a certa — e isso é pior do que não ter integração nenhuma.

Na Sparkwave trabalhamos regularmente com Primavera, PHC e Sage do lado dos ERP instalados, e com Moloni, InvoiceXpress e Vendus do lado da faturação certificada. Se está a avaliar uma integração e quer perceber qual das três abordagens faz sentido para o seu caso, fale connosco — ou conheça o nosso serviço de integrações. E se a integração fizer parte de uma mudança de plataforma, comece pelo guia de migração: a ordem por que se fazem estas coisas é metade do resultado.