Como integrar o ERP com o e-Commerce B2B — guia por sistema (TOTVS, SAP, Sankhya, Senior)
A integração com o ERP é o eixo de qualquer projeto de e-commerce B2B. Mas "integrar com TOTVS" pode significar coisas muito diferentes dependendo da versão e do histórico de customizações. Guia técnico e prático por sistema, com o que avaliar antes de contratar.
Mauricio Di BonifacioCo-fundador da Fastchannel
Quando uma indústria ou distribuidor está avaliando um projeto de e-commerce B2B, uma das perguntas mais frequentes é: "Como vai funcionar a integração com o nosso ERP?"
E a resposta que a maioria dos fornecedores dá — "integramos com todos os principais ERPs" — não serve para nada. Porque "integrar com TOTVS" pode significar desde uma integração robusta com décadas de refinamento até um conector que foi construído para um cliente específico e que tem comportamentos imprevisíveis.
Depois de mais de 300 projetos entregues com os principais ERPs do mercado industrial brasileiro, este artigo é o guia prático que eu gostaria que existisse quando começamos. Ele cobre, de forma direta, o que precisa ser integrado, como a engenharia da integração funciona por baixo do capô, o que muda em cada sistema — TOTVS Protheus, SAP, Sankhya, Senior e os menos comuns — e quais são as perguntas que você deve fazer antes de contratar qualquer fornecedor de plataforma.
Se você ainda está um passo atrás, mapeando o que uma boa integração deveria cobrir na sua operação, a página de integração de e-commerce B2B com ERP dá o panorama. Aqui a gente desce ao nível técnico.
O que precisa ser integrado — o essencial, sem enrolação
Antes de entrar em cada ERP, vale fixar o mínimo que qualquer e-commerce B2B precisa trocar com o sistema de gestão. Não como lista de recursos, mas como os cinco fluxos que sustentam a venda:
- Cadastro e regras comerciais do cliente — tabela de preço aplicável, limite de crédito, condições de pagamento liberadas, situação cadastral (ativo, bloqueado, inadimplente) e centro de distribuição que atende a região. Sem isso, o portal não exibe as condições certas para cada comprador — e venda B2B com condição errada não fecha.
- Catálogo, preço e estoque — produtos, preços por tabela e saldo disponível sincronizados. A frequência acompanha a volatilidade: item de alto giro pede algo próximo do tempo real; item de baixo giro tolera janelas maiores. O preço por tabela é, de longe, a peça que mais carrega customização específica de cada empresa.
- Impostos — o pedido precisa exibir o total correto (ICMS, IPI, ST e DIFAL conforme o caso) antes da confirmação.
- Pedidos — o pedido confirmado no portal entra no ERP como se tivesse sido digitado pelo comercial, com tratamento de erro e retorno de status.
- Financeiro e crédito — consulta a limite disponível e posição de títulos, para condicionar o que o cliente consegue comprar.
Esses cinco fluxos eu detalho, em linguagem de negócio, na página de integração com ERP. O resto deste artigo trata do que quase nenhum material explica: como isso é construído e o que muda em cada sistema.
Impostos: onde calcular (versão curta)
Só dois modelos existem, e a escolha é um trade-off simples. Cálculo no portal: a plataforma tem motor fiscal próprio e aplica as regras por NCM, origem, destino e tipo de comprador — mais rápido para o usuário, exige manter o motor atualizado com a legislação. Cálculo no ERP por simulação: o portal chama o ERP simulando a nota antes de confirmar — mais preciso, porque usa o mesmo motor que vai emitir o documento, mas mais lento e dependente da disponibilidade do ERP.
Com a Reforma Tributária entrando em cena a partir de 2026 (IBS, CBS e Imposto Seletivo substituindo tributos atuais de forma gradual), quem usa motor fiscal interno vai precisar de um plano de atualização. É uma pergunta legítima para o fornecedor — voltamos a ela mais adiante.
A engenharia da integração: o que separa uma que aguenta operação de uma que quebra
Aqui está a parte que raramente aparece em proposta comercial, mas que decide se a integração vai sobreviver ao primeiro pico de pedidos. Integrar ERP com e-commerce não é "puxar dados"; é desenhar um sistema distribuído entre dois softwares que não foram feitos para conversar, cada um com sua janela de disponibilidade e seu ritmo. Isso vale para qualquer combinação de ERP e plataforma.
Batch vs. tempo real: a decisão que define custo e risco
Não existe "integração em tempo real" como virtude absoluta. Existe o dado certo na frequência certa.
Batch (lote) é o modelo em que blocos de informação são sincronizados em janelas definidas — a cada X minutos, de hora em hora, ou de madrugada para cargas pesadas. É barato, previsível e poupa o ERP. Serve bem para catálogo completo, tabelas de preço, cadastro em massa e reprocessamentos.
Tempo real (ou quase) é o modelo em que o portal consulta ou recebe o dado no momento em que ele importa — normalmente estoque e crédito na hora de montar o carrinho ou confirmar o pedido. É mais caro, mais frágil e depende da disponibilidade do ERP naquele instante.
O erro clássico é querer tudo em tempo real. Isso encarece o projeto, sobrecarrega o ERP e não entrega ganho proporcional. O desenho maduro combina os dois: catálogo e preço em lote, estoque e crédito com consulta sob demanda (ou cache curto validado no fechamento). A regra prática é sincronizar cada dado na menor frequência que a operação tolera — não na maior que a tecnologia permite.
Middleware e iPaaS: quando desacoplar vale a pena
Integrar plataforma direto no ERP, ponto a ponto, é o caminho mais curto — e funciona bem quando o ERP tem API madura e o escopo é enxuto. O problema aparece quando há muitos sistemas (ERP, WMS, TMS, CRM, gateway de pagamento) ou quando o ERP não pode ser exposto direto à internet.
Uma camada de middleware ou uma plataforma de iPaaS (integration platform as a service) resolve isso ao ficar no meio: ela concentra as conexões, traduz formatos, aplica regras de roteamento e — o ponto mais importante — desacopla a plataforma do ERP. Se o ERP cai para manutenção, o middleware segura as mensagens em fila e entrega quando ele volta, em vez de derrubar o portal junto.
O critério não é "todo projeto precisa de iPaaS". É: use uma camada intermediária para reduzir acoplamento e absorver instabilidade, não como enfeite arquitetural. Projeto simples, com um ERP de API boa, muitas vezes dispensa. Projeto com vários sistemas e ERP legado quase sempre agradece.
Filas, idempotência e o pesadelo do pedido duplicado
Esse é o detalhe técnico que mais dói quando é ignorado, então vou ser explícito.
Toda comunicação entre dois sistemas pode falhar no meio: a plataforma envia o pedido, o ERP processa, mas a confirmação se perde na rede. A plataforma, sem resposta, reenvia. Resultado sem proteção: dois pedidos idênticos no ERP. Em operação B2B, isso é faturamento em dobro, expedição errada e cliente furioso.
A proteção se chama idempotência: cada pedido carrega uma chave única (um identificador gerado na origem), e o ERP — ou o middleware — usa essa chave para reconhecer que já processou aquela mensagem e ignorar a repetição. Enviar dez vezes o mesmo pedido com a mesma chave produz exatamente um pedido. Isso não é luxo; é requisito. Se o fornecedor não fala de idempotência quando você pergunta como ele evita duplicação, é um sinal ruim.
O mecanismo que sustenta isso na prática é uma fila de mensagens. Em vez de a plataforma chamar o ERP e esperar de pé, ela publica o pedido numa fila; um consumidor entrega ao ERP no ritmo que ele aguenta, com retentativa automática em caso de erro transitório. Fila absorve pico, ordena o processamento e permite reprocessar sem perder nada.
Reconciliação de pedidos e sincronização de estoque e crédito
Sistemas distribuídos divergem — é da natureza deles. Por isso, além de enviar dados, uma integração séria precisa conferir dados.
Reconciliação de pedidos é o processo, normalmente em lote, que compara o que a plataforma acha que enviou com o que o ERP registrou, e aponta divergências: pedido que saiu do portal mas não apareceu no ERP, status que ficou travado, valor que não bateu. Sem reconciliação, um pedido perdido só é descoberto quando o cliente liga reclamando que não chegou. Com ela, o sistema levanta a mão antes.
Sincronização de estoque vive a tensão entre precisão e performance. Consultar o ERP a cada exibição de produto mata a performance do portal e do próprio ERP; confiar num cache muito velho vende o que não existe. O desenho equilibrado costuma ser: cache de estoque com atualização frequente para a navegação, e validação real no momento da confirmação do pedido — o ponto em que o erro custa caro. Reserva de estoque no ato do pedido, quando o ERP suporta, elimina boa parte do problema.
Sincronização de crédito é parecida, e mais sensível: verificar limite de crédito em tempo real a cada tela impacta o financeiro do ERP. O padrão saudável é consultar o crédito disponível na confirmação do pedido — não na navegação — e tratar o bloqueio como uma resposta de negócio legítima, não como erro de sistema.
Tratamento de erros e reprocessamento
O ERP vai rejeitar pedidos — e isso é normal. Limite de crédito estourado, produto sem estoque confirmado, condição comercial inválida, cadastro bloqueado. O que separa uma integração madura de uma amadora é o que acontece depois da rejeição.
Uma boa integração distingue erro de negócio (o pedido é válido tecnicamente, mas o ERP disse não por uma regra — isso volta ao cliente em linguagem compreensível: "limite de crédito insuficiente", não "erro 500") de erro técnico (timeout, ERP fora do ar, falha de rede — isso vai para a fila de reprocessamento e é tentado de novo automaticamente, sem incomodar ninguém).
O reprocessamento precisa ser seguro — e é aqui que a idempotência fecha o ciclo: reprocessar só é tranquilo porque a chave única garante que a retentativa não duplica. Fechando o pacote, toda integração séria tem observabilidade: log do que entrou, do que saiu, do que falhou e por quê. Peça para ver isso em demo. Fornecedor que não mostra o painel de erros é fornecedor que não tem.
TOTVS Protheus — o mais comum e o mais variado
O TOTVS Protheus é o ERP mais presente no mercado industrial brasileiro de médio e grande porte. É também o que apresenta maior variação entre instalações — porque é altamente customizável e porque muitas empresas têm customizações acumuladas de 10, 15 ou 20 anos.
Meios de integração típicos. As versões mais recentes (linha 12, especialmente da 12.1.2x em diante) trazem APIs REST/JSON nos módulos de gestão, o caminho preferencial hoje. Há também o barramento de integração da TOTVS para orquestrar mensagens entre módulos e sistemas. Versões mais antigas dependem de web services SOAP ou, no pior caso, de integração via banco de dados — que funciona, mas é frágil e cara de manter, porque amarra a integração ao esquema interno do ERP em vez de a um contrato de API estável.
O que varia por instalação:
Tabelas de preço: o Protheus tem estrutura nativa de tabelas de preço, mas muitas empresas a customizaram para comportamentos próprios — desconto por família de produto, preço por unidade de negócio, regras de progressividade fora do padrão. Antes de integrar, é obrigatório mapear como a precificação funciona naquela instalação. Não existe atalho.
Cálculo de impostos: o Protheus tem módulo fiscal completo, mas a parametrização das regras tributárias varia muito. Operações em múltiplos estados e produtos sujeitos a ST costumam ter configurações complexas que precisam ser entendidas antes de qualquer integração fiscal.
Versões antigas: instalações anteriores à linha 12 podem ter limitações de API que tornam a integração REST inviável, empurrando para middleware com arquivos ou banco. É factível, mas o custo de manutenção sobe.
Pergunta obrigatória ao fornecedor: "Quantos projetos vocês entregaram com TOTVS Protheus na versão [a sua], e qual foi a principal complicação?"
Prazo típico de integração: 6 a 14 semanas, conforme versão e nível de customização (estimativa de experiência, não regra).
Nota de rigor: a TOTVS também comercializa outras linhas (Datasul, entre outras), com meios de integração próprios. O raciocínio deste artigo — mapear versão, customização e meio de integração antes de assumir qualquer coisa — vale igual para elas.
Um especialista mostra como ficaria com o seu ERP, a sua tabela de preço e as suas regras de desconto.
Fale com um EspecialistaSAP Business One e S/4HANA — robusto, com peculiaridades locais
O SAP tem forte presença no segmento industrial de grande porte no Brasil. O SAP Business One é muito usado em médias indústrias; o S/4HANA, em grandes corporações.
SAP Business One. Expõe uma camada de serviços REST (a Service Layer) que permite integrar produtos, clientes, pedidos e posição financeira de forma relativamente padronizada, além da interface DI para cenários específicos. A integração com e-commerce B2B por essa via é madura e há bons conectores no mercado. O ponto de atenção é o estoque em empresas com múltiplos armazéns ou controle de lote: a sincronia de disponível por depósito exige configuração cuidadosa para o portal não exibir saldo incorreto.
SAP S/4HANA. É o cenário de maior robustez técnica e maior custo de integração. Trabalha com APIs OData bem estruturadas e integra via a suíte de integração da SAP. É sólido quando bem configurado, mas exige especialistas SAP do lado do ERP — que raramente são as mesmas pessoas que configuram a plataforma de e-commerce. Na prática, o projeto costuma envolver três times: a plataforma, o time SAP interno e, com frequência, um integrador SAP certificado. Alinhar esses três ativamente é o que impede o projeto de travar.
O ponto de atenção geral no SAP: plataformas de e-commerce desenvolvidas fora do Brasil raramente dominam a configuração fiscal do SAP para o mercado local. ICMS-ST, IPI, DIFAL — a parametrização fiscal do SAP para o Brasil tem especificidades que exigem um configurador com experiência nacional. Confirme antes de assinar.
Prazo típico SAP B1: 5 a 10 semanas. S/4HANA: 10 a 20 semanas (estimativas de experiência).
Sankhya — crescendo e amadurecendo
A Sankhya tem ganhado participação no mercado industrial brasileiro, especialmente em médias indústrias e distribuidores que buscam alternativa ao TOTVS com foco local e melhor custo-benefício.
A arquitetura é web e a empresa tem investido na sua camada de integração, com APIs disponíveis e conectores desenvolvidos por parceiros. O que funciona bem: o módulo de gestão comercial — pedidos, faturamento, condições comerciais — tem estrutura clara e documentada, o que facilita a conexão com portais. O que exige atenção: o ecossistema de conectores prontos para e-commerce B2B é menor que o do TOTVS, o que significa menos experiência acumulada no mercado em geral. Pergunte ao fornecedor se ele usa conector homologado pela Sankhya ou integração própria, e quantos projetos reais entregou — não "suporte genérico".
Prazo típico de integração: 5 a 10 semanas, com versões recentes (estimativa).
Senior Sistemas — industrial com boa capacidade de API
A Senior tem presença relevante em indústrias do Sul do Brasil e em setores como têxtil, calçados e distribuição, e tem investido em API e integração nos últimos anos.
Pontos positivos: APIs documentadas, arquitetura mais moderna que muitos ERPs legados e time técnico com boa disposição para apoiar integrações. Pontos de atenção: como no Sankhya, o ecossistema de conectores prontos para e-commerce B2B é menor que o do TOTVS. O critério decisivo é a experiência do fornecedor de plataforma com a versão específica da Senior em operação na sua empresa.
Prazo típico de integração: 5 a 10 semanas (estimativa).
ERPs menos comuns — Winthor, Omie, Nomus e outros
Para quem opera com ERPs de nicho ou legados, o cenário é mais complexo — e o critério de risco muda.
Winthor: muito usado em distribuição e atacado. Integra com e-commerce via APIs disponíveis, mas o ecossistema de parceiros com experiência específica é limitado, o que tende a exigir mais desenvolvimento customizado.
Omie: popular em médias e pequenas empresas, tem API REST bem estruturada e é tecnicamente mais fácil de integrar. A limitação é funcional: não carrega toda a complexidade de tabela de preço e regra fiscal que a operação industrial maior exige.
ERPs muito antigos ou próprios: se não há API e a integração só é possível via banco ou arquivos de troca, o risco técnico sobe. É viável integrar — mas o custo de manutenção ao longo do tempo é maior e a dependência de quem conhece aquela instalação específica vira um risco de projeto real. Esse é exatamente o tipo de decisão que pesa na hora de escolher a plataforma e de dimensionar o investimento.
As 6 perguntas certas para fazer antes de contratar
Com esse contexto, aqui estão as perguntas que separam fornecedor experiente de fornecedor com discurso pronto:
1. Qual versão exata do nosso ERP vocês já integraram, e quantas vezes? Não aceite "integramos com TOTVS". Peça a versão específica e o número de projetos reais.
2. Qual foi o maior desafio na integração com esse ERP específico? A resposta revela a honestidade e a profundidade da experiência. Quem nunca sofreu, nunca integrou de verdade.
3. Como funciona a sincronização de estoque e crédito — qual é a defasagem máxima, e onde vocês validam no fechamento? Entenda o trade-off entre precisão e performance que estão propondo, e se há validação real na confirmação do pedido.
4. Como o portal trata erro de validação do ERP e o que acontece num reprocessamento? Me mostra em demo. Ver, ao vivo, o que acontece quando o ERP rejeita um pedido — e como a fila reprocessa sem duplicar — é o melhor teste de maturidade técnica que existe.
5. Como vai funcionar a atualização das regras fiscais com a Reforma Tributária? Essa pergunta separa quem tem plano de quem improvisa.
6. Posso falar com dois clientes que rodam exatamente o nosso ERP há mais de 12 meses? Referência com o ERP específico, pós go-live, é insubstituível. Nenhuma proposta comercial vale o que vale um cliente falando do que quebrou.
Armadilhas comuns de integração — e como evitá-las
Deixar o escopo de integração para depois do go-live. Toda integração pedida depois que o sistema está no ar tem custo e impacto. O escopo precisa estar definido e validado com o time de TI antes da assinatura. Evite: trate a especificação das integrações como parte do contrato, não como detalhe de implementação.
Assumir que "é o mesmo ERP, então é igual". Duas instalações do mesmo Protheus podem se comportar de formas radicalmente distintas por causa das customizações. Evite: exija uma fase de diagnóstico técnico da sua instalação específica antes de qualquer estimativa firme.
Subestimar o impacto do ERP na performance do portal. Consulta síncrona ao ERP a cada tela derruba o tempo de resposta. Evite: cache inteligente para navegação, validação real só no fechamento, e nada de "consultar o ERP a cada clique".
Ignorar idempotência e reprocessamento. Sem chave única por pedido, qualquer instabilidade de rede vira pedido duplicado. Evite: confirme, por escrito, como o fornecedor garante idempotência e como funciona a fila de retentativa.
Não planejar reconciliação. Sem conferência periódica, pedido perdido só aparece quando o cliente reclama. Evite: exija um processo de reconciliação entre plataforma e ERP, com relatório de divergências.
Começar pela integração mais complexa. Tentar resolver o cenário mais difícil primeiro atrasa o go-live inteiro. Evite: integração em fases, começando pelo que coloca a operação no ar com segurança — exatamente o que uma boa metodologia de projeto prevê.
Tratar integração como assunto só de TI. As regras a integrar são comerciais — tabela de preço, condição de pagamento, limite de crédito. Evite: coloque o time de negócio na mesa desde a especificação, ou a integração vai funcionar tecnicamente e refletir a operação errada.
Conclusão
A integração com o ERP não é um detalhe técnico de um projeto de e-commerce B2B. É o eixo central — o que faz o portal ser um canal de vendas real ou apenas um catálogo bonito sem utilidade operacional.
A boa notícia é que os principais ERPs do mercado industrial brasileiro têm capacidade de integração adequada para e-commerce B2B — via API REST, web services ou conectores especializados. O que faz a diferença não é a marca do ERP; é a engenharia da integração (batch e tempo real bem dosados, filas, idempotência, reconciliação, tratamento de erro) e a experiência do fornecedor com aquela combinação específica de ERP, versão e customização.
Pergunte, investigue as referências, peça demo do que quebra. A integração é onde o projeto ganha ou perde — e é onde os bons fornecedores se separam dos medíocres. Uma plataforma de e-Commerce B2B especializada já chega com essas integrações testadas nos principais ERPs do mercado. Se quiser discutir o seu cenário específico de ERP, fale com nossos especialistas.
Empreendedor e co-fundador da Fastchannel e da Vertis. 26 anos de experiência na transformação digital do canal de vendas B2B — plataforma de e-Commerce B2B e agentes de IA para times de vendas, em mais de 300 projetos para indústrias e distribuidores.
Ver todos os artigosLinkedInMais inteligência para decidir.
Plataforma de e-Commerce B2B e Agentes de IA para indústrias e distribuidores. Uma conversa de 30 minutos, sem compromisso, com quem integra operação comercial a ERP todo dia.
Fale com um EspecialistaVocê também pode gostar
e-Commerce B2BConflito de canal entre indústria e distribuidor — como resolver sem perder ninguém10 min de leitura
e-Commerce B2Be-Commerce B2B: o Guia Completo para Indústrias e Distribuidores13 min de leitura
e-Commerce B2BComo escolher uma plataforma de e-Commerce B2B: os critérios que realmente importam18 min de leitura
Pronto para Acelerar o Crescimento da sua Venda B2B?
Descubra como Indústrias e Distribuidores que são líderes no mercado estão utilizando nossa Plataforma de e-Commerce B2B e nossa Plataforma de Agentes Inteligentes de Venda B2B para impulsionar suas Vendas B2B.