Projetos de e-commerce B2B travam menos por UX e mais por arquitetura fiscal. Quando o cálculo do imposto foi delegado ao ERP, com integração síncrona no checkout, o projeto herda um sistema que não foi feito para responder em tempo real. O resultado é pedido manual, abandono sem causa clara e cancelamento pós-emissão. A decisão de onde calcular o imposto está no canônico: ERP, checkout ou middleware.

Em resumo

O B2B não é "B2C com CNPJ no cadastro": o cálculo depende de regime, IE, tipo de operação e UF, o ticket é maior e o erro fiscal vira disputa comercial. Quando a camada fiscal fica dentro do ERP, a arquitetura colapsa sob o checkout síncrono. Quem sente: projetos com pedido manual, abandono e cancelamento. O caminho é tratar o fiscal como camada desacoplada, com API e SLA próprios, e devolver ao ERP o papel de sistema de registro.

Por que o B2B é diferente do B2C no fiscal

No B2C, o destino é quase sempre pessoa física, com regra relativamente estável por estado e NCM. No B2B, o cálculo depende do regime do comprador (Simples, Presumido, Real), do tipo de operação (revenda, uso e consumo, industrialização), da IE e das UFs de origem e destino: um mesmo SKU pode ter alíquotas diferentes para dois compradores na mesma rua. A jornada ainda precisa decidir se aceita o pedido, com qual prazo e limite, cruzando crédito, dados cadastrais e perfil fiscal antes de fechar o carrinho. Ticket maior e ciclo mais longo fazem o erro fiscal virar disputa, não devolução de loja.

Sintomas de projeto B2B travando

Sintoma O que costuma indicar
Pedido manual e fila de aprovação Cadastro e regime não validados antes do checkout
Abandono sem causa clara no funil Cálculo lento ou divergência de valor no checkout
Cancelamento após a emissão Imposto errado, crédito que não fecha ou NF-e rejeitada
Replanejamento recorrente do roadmap A regra fiscal virou customização dentro do ERP

A causa raiz: arquitetura monolítica baseada em ERP

O padrão é construir o e-commerce sobre o ERP e delegar o cálculo fiscal a ele, com integração síncrona no checkout. Só que ERPs foram projetados para apurar imposto após o fato gerador, em lote, com tolerância de minutos; o checkout exige tempo real, sobre um carrinho ainda hipotético, com variação por comprador. Para forçar o ERP a responder rápido, o time customiza módulos e escreve regras em campos livres, e cada exceção vira código: em pouco tempo, a TI vira refém da própria customização. Com plataforma no front, ERP no meio e legado embaixo, a cadeia tem três pontos de falha, e basta um ficar lento para o pedido travar.

A alternativa: camada fiscal desacoplada

Tratar o fiscal como camada autônoma, com API e SLA próprios. O motor fiscal roda em paralelo ao ERP, recebe o carrinho, o CNPJ, as UFs e o NCM e devolve o cálculo completo em tempo de checkout. Antes do checkout, o cadastro é enriquecido com o perfil fiscal do comprador (regime, IE, situação cadastral), o que reduz o "pedido manual de revisão". O ERP segue importante, mas no papel certo: registrar a operação, gerar a NF-e e alimentar a contabilidade. A decisão de "vende ou não vende, por qual preço, com qual imposto" sai para a camada fiscal dedicada. Onde exatamente esse cálculo deve viver (ERP, checkout ou middleware) está detalhado no canônico da decisão.

Onde a Mastery entra

O Motor Fiscal B2B da Mastery é essa camada desacoplada: cálculo no checkout por API, com o perfil fiscal do comprador validado pelo Aprova CNPJ, sem substituir o ERP. Observações internas da Mastery, na base de clientes B2B, indicam que a fricção fiscal é uma causa relevante de cancelamento e de pedido manual; são leituras internas, não verificadas externamente.

Perguntas frequentes

Por que meu projeto B2B continua travando mesmo após trocar de plataforma?

Porque a plataforma trocou, mas a camada fiscal continuou dentro do ERP. Sem desacoplar o cálculo, o sintoma volta na próxima release.

Posso usar o ERP para cálculo fiscal no checkout B2B?

Pode, mas a probabilidade de gargalo é alta: ERPs foram pensados para apuração após o fato gerador, não para resposta em tempo real no carrinho. Veja a comparação ERP, checkout e middleware no canônico.

O motor fiscal da Mastery substitui meu ERP?

Não. O ERP continua como sistema de registro e emissor da NF-e; o motor cobre a decisão no checkout, antes da emissão.

Como saber se meu projeto trava por arquitetura fiscal?

Se há pedido manual, fila de aprovação, cancelamento pós-faturamento e replanejamento recorrente por "regra fiscal nova", a hipótese é forte.

Em quanto tempo um projeto se estabiliza com motor fiscal desacoplado?

Depende do ponto de partida, mas operações com dados cadastrais minimamente organizados costumam ver redução de pedido manual e cancelamento já no primeiro trimestre.

Trocar de plataforma resolve o projeto B2B travado?

Nem sempre. Se a camada fiscal continua dentro do ERP, o sintoma volta na próxima release. O que resolve é desacoplar o cálculo fiscal para uma camada dedicada, com o ERP no papel de registro e emissão.

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: solicitar um diagnóstico de projeto travado com a Mastery.

Leituras relacionadas: Cálculo fiscal no ERP, no checkout ou em middleware · Checkout B2B: a tributação é a maior fricção invisível · Guia de automação fiscal para e-commerce B2B