Há três lugares para calcular o imposto do pedido B2B: dentro do ERP, em um motor fiscal dedicado no checkout, ou em uma camada de middleware. A tese que orienta a escolha é direta: o ERP não foi desenhado para calcular imposto síncrono no checkout. Ele é ótimo no back-office (faturamento, contabilidade, NF-e) e frágil no momento em que o comprador decide, quando o preço com imposto precisa sair em tempo real.
Em resumo
O ERP nasceu para o back-office: apurar imposto depois do fato gerador, em lote. O checkout B2B é o oposto: cálculo síncrono, sobre um carrinho hipotético, com variação por comprador. Quem decide arquitetura precisa escolher onde o cálculo vive. A recomendação, na maioria dos casos, é complementar, não substituir: o motor fiscal calcula no checkout, o ERP registra e emite a NF-e. A matriz abaixo compara ERP, motor no checkout e middleware por volume, canal, TI disponível e latência.
A história: como o ERP virou sinônimo de fiscal
O ERP nasceu nos anos 80 e 90 para centralizar processos fragmentados: pedido, estoque, transporte, nota fiscal e livro fiscal, tudo em um sistema. Parte central foi calcular o imposto ao gerar a nota, armazenando o resultado para conferência posterior. Naquele contexto, e-commerce não existia: o cliente decidia comprar antes de qualquer checkout, então calcular imposto no ERP fazia sentido, porque o ERP era o lugar certo para isso.
Back-office vs checkout: a diferença ignorada
O ERP tende a ser eficiente no back-office: faturamento (a nota com o imposto), contabilidade (o imposto direto em conta), estoque e relatórios fiscais. O back-office é o ponto de chegada da venda. O checkout é o ponto de decisão do comprador, e é aí que o ERP costuma não caber:
- Operação síncrona em tempo real: o carrinho precisa do preço final com imposto naquele instante; ERPs foram projetados para lote ou para o próprio fluxo de faturamento.
- Validação cadastral rápida: consultar CNPJ, IE e regime em banco relacional a cada carrinho tende a ter latência incompatível com checkout.
- Cálculo com múltiplas variáveis em paralelo: o mesmo item tem preço final diferente por regime do comprador.
- Performance sob pico de e-commerce e integração via API moderna (VTEX, Shopify, stacks custom).
Cada fornecedor de ERP tem capacidades diferentes, e algumas plataformas evoluíram além do padrão histórico; o ponto é conceitual.
A decisão: ERP, motor no checkout ou middleware
| Critério | Cálculo no ERP | Motor fiscal no checkout (dedicado) | Middleware / integrador |
|---|---|---|---|
| Latência no checkout | Alta: não foi feito para síncrono | Baixa: desenhado para tempo real | Depende do integrador, com custo extra de salto |
| Pico de e-commerce | Arriscado sob carga | Suporta carga de checkout | Depende do dimensionamento |
| Múltiplos canais (VTEX, Shopify, ERP) | Acoplado ao ERP | Uma API para todos os canais | Orquestra canais, com mais peças para manter |
| TI disponível | Exige customizar o ERP (vira dívida técnica) | Integração por API, sem trocar o ERP | Exige manter o middleware |
| Manutenção da regra fiscal | Vira código e customização | Regra atualizada pelo fornecedor | Depende de quem mantém a regra |
| Divergência checkout x NF-e | Alta quando usa aproximação | Baixa: mesmo cálculo no pedido e na nota | Depende da consistência entre camadas |
Quando cada um faz sentido: o ERP é o lugar certo para o back-office e a emissão da NF-e. O motor fiscal no checkout faz sentido quando há checkout B2B síncrono, múltiplos canais, pico de tráfego e quando a divergência entre o preço do carrinho e o da nota é um problema. O middleware cabe quando já existe um integrador orquestrando muitos sistemas e o cálculo pode viver ali, aceitando mais peças para manter e algum overhead de latência.
Sintomas de que o ERP está no lugar errado
- Aprovação manual de pedidos: o pedido cai em fila para alguém validar cadastro, regime e cálculo à mão; o tempo pode chegar a horas.
- Cálculo lento ou divergente: o checkout usa aproximação e a nota sai com valor diferente, gerando chamado de suporte.
- Cancelamento por dado fiscal: o pedido vai ao ERP, que descobre CNPJ ou IE em situação divergente e rejeita a nota, quando o bloqueio deveria ter ocorrido no checkout.
O que um motor fiscal nativo do checkout faz diferente
Opera de forma síncrona (regras compiladas em memória, cache local), usa o perfil fiscal do comprador pré-validado (CNPJ, IE e regime coletados e validados no cadastro, consultados em memória no checkout, sem revalidar a cada carrinho) e expõe uma API simples: o checkout faz a requisição, o motor devolve o cálculo, sem acoplar ao estoque ou à emissão, que seguem no ERP.
O modelo complementar: ERP + motor fiscal
Na maioria dos casos, a solução não é substituir o ERP, é complementar:
- O comprador monta o carrinho na plataforma de e-commerce.
- O checkout chama o motor fiscal por API e recebe o preço final com imposto.
- O comprador confirma e a plataforma gera o pedido.
- O pedido vai ao ERP com dados já validados.
- O ERP emite a NF-e coerente com o que foi apresentado no checkout, reduzindo divergência.
Onde a Mastery entra
O Motor Fiscal B2B da Mastery é a camada de cálculo no checkout: recebe o carrinho, o CNPJ, a UF de origem e destino e o NCM, e devolve ICMS, ICMS-ST, IPI, PIS/COFINS e DIFAL quando aplicável, em tempo real, sem substituir o ERP. A integração é fácil, por API (VTEX, Zydon, GoDeep, Shopify, SAP, Oracle, TOTVS, Sankhya). A Mastery calcula na origem; não recolhe nem paga tributos e não emite a nota.
Perguntas frequentes
Onde calcular o imposto do pedido B2B: no ERP, no checkout ou em middleware?
No back-office e na emissão, no ERP. No momento do checkout, em um motor fiscal dedicado, que responde em tempo real. O middleware cabe quando já há um integrador orquestrando muitos sistemas. A escolha depende de volume, canal, TI disponível e exigência de latência.
O ERP resolve tributação B2B?
No back-office, sim (faturamento, contabilidade, nota). No momento da decisão de compra, costuma resolver menos bem, porque foi feito para processar depois, não para responder em tempo real no carrinho.
Preciso trocar meu ERP por um motor fiscal?
Em geral, não. O ERP segue no back-office e o motor fiscal atua no checkout. Dois sistemas, dois propósitos, um fluxo integrado por API.
Middleware é melhor que um motor fiscal dedicado?
Depende. O middleware orquestra vários sistemas, mas adiciona peças e algum overhead de latência. Um motor dedicado no checkout tende a ser mais direto quando o requisito principal é latência baixa e consistência entre o cálculo do carrinho e o da nota.
Como evitar divergência entre o preço do checkout e o da NF-e?
Usando o mesmo cálculo nos dois momentos: o motor calcula no pedido e o ERP emite a nota com o valor já validado. Aproximações no checkout são a principal fonte de divergência.
Quando preciso de um motor fiscal complementar ao ERP?
Quando há checkout lento, aprovação manual demorada, cancelamento por motivo fiscal, divergência entre carrinho e nota, ou perda de receita por abandono fiscal.
Fontes oficiais
Este conteúdo tem caráter informativo e não substitui orientação contábil, fiscal ou jurídica especializada. Regras tributárias podem variar conforme UF, regime tributário, operação, produto, NCM, CNAE e perfil do comprador. Valide seu cenário com profissional habilitado.
Próximo passo: diagnóstico de arquitetura fiscal com a Mastery: ERP, checkout ou middleware.
Leituras relacionadas: Por que projetos de e-commerce B2B travam na arquitetura fiscal · Checkout B2B: a tributação é a maior fricção invisível · Guia de automação fiscal para e-commerce B2B
Soluções por plataforma e ERP: veja as soluções fiscais para e-commerce B2B com SAP, TOTVS e Oracle.