Na validação tributária de um projeto de ERP, a empresa precisa separar decisão fiscal, parametrização, teste, reconciliação e aceite. A autorização do documento eletrônico não demonstra, sozinha, que o tratamento tributário esteja correto: o art. 132, I, da Resolução CGIBS nº 6/2026, para o IBS, e o art. 132, I, do Decreto nº 12.955/2026, para a CBS, dizem expressamente que a autorização não implica validação das informações contidas no documento fiscal.
Esse ponto muda o contrato do projeto. “Emitir sem rejeição” pode ser uma evidência técnica, mas não encerra a revisão da operação, do cadastro, da regra fiscal, da apuração nem dos efeitos contábeis e financeiros. Um aceite confiável liga cada conclusão a uma fonte versionada, registra o resultado esperado e observado e identifica quem tinha competência para decidir.
O roteiro abaixo foi construído para CFOs, diretores fiscais, controllers, responsáveis por tecnologia, jurídicos, patrocinadores do projeto e integradores. Ele é uma proposta de governança da TaxUp, não uma certificação do sistema nem um checklist imposto literalmente pela lei.
Quando a implantação exige uma decisão tributária
Fonte: TaxUp; elaboração editorial própria.
Uma regra do ERP pode parecer apenas técnica até que alguém precise responder por que determinada operação recebeu aquela classificação, base, alíquota, crédito ou evento. O sistema executa uma decisão; ele não cria sozinho a premissa jurídica que sustenta a decisão.
A primeira camada é a relação com o Fisco. Os arts. 121 e 123 do CTN distinguem o sujeito passivo definido pela legislação e as convenções particulares. O contrato pode organizar obrigações e consequências entre cliente, integrador e consultores, mas não muda, por si, quem a lei coloca na posição de contribuinte ou responsável perante a Fazenda Pública.
A segunda camada é contratual. O art. 421-A, I e II, do Código Civil permite que contratos civis e empresariais estabeleçam parâmetros objetivos e alocação de riscos definida pelas partes. O art. 422 exige probidade e boa-fé. Isso dá utilidade prática a um escopo que mostre premissas, entregáveis, dependências, exclusões, critérios de aceite e procedimento de mudança.
A terceira camada é operacional. Alguém precisa traduzir a premissa em cadastro e configuração, executar cenários positivos e negativos, guardar a evidência e reconciliar o resultado. Quando as três camadas ficam misturadas, a empresa pode aprovar uma entrega técnica sem ter aprovado a conclusão tributária — ou cobrar do integrador uma decisão que nunca foi incluída no contrato.
O que contratar e o que deixar fora do escopo
Fonte: TaxUp; elaboração editorial própria.
“Validação tributária do ERP” não descreve um objeto único. Duas propostas com o mesmo título podem entregar trabalhos muito diferentes. Antes de comparar preço, transforme a necessidade em modalidade, produto verificável e limite.
| Modalidade | Entrega esperada | O que não deve ser presumido |
|---|---|---|
| Revisão de premissas | Matriz de operações, fontes, interpretações, responsáveis e pontos pendentes. | Configuração do ERP, teste executado ou parecer jurídico completo. |
| Tradução funcional | Requisitos tributários rastreáveis para cadastros, regras, documentos, eventos e integrações. | Desenvolvimento, correção de código ou garantia de compatibilidade de terceiros. |
| Acompanhamento da homologação | Revisão de cenários, resultados esperados, evidências e divergências durante os testes. | Execução de toda a bateria, fornecimento da massa ou disponibilidade dos ambientes. |
| Revisão do aceite | Relatório de aprovados, reprovados, bloqueados, ressalvas, responsáveis e decisão de liberação. | Certificação absoluta, eliminação de risco ou aprovação de item não testado. |
O contrato deve dizer quais entidades, estabelecimentos, regimes, operações, documentos fiscais, integrações, módulos e períodos estão incluídos. Também deve indicar se o trabalho alcança dados mestres, obrigações acessórias, apuração, contabilização, financeiro, contingência e eventos posteriores à emissão.
Exclusões merecem a mesma precisão. Auditoria contábil, opinião legal formal, saneamento de cadastro, desenvolvimento, suporte pós-produção e reteste após nova versão não entram automaticamente. O que depende de acesso, amostra, área interna ou fornecedor deve aparecer como dependência, com prazo e consequência se não for entregue.
Quem decide, executa, testa e aceita
Fonte: TaxUp; elaboração editorial própria.
A matriz de responsabilidades não altera a lei e não serve para deslocar ao fornecedor a posição tributária da empresa. Sua função é evitar decisões sem dono e entregas aceitas por quem não tinha informação ou competência para avaliá-las.
| Decisão ou atividade | Dono sugerido | Participação necessária | Evidência mínima |
|---|---|---|---|
| Qualificar a operação | Fiscal/Jurídico | Negócio, contratos e contabilidade | Premissa, fatos considerados, fonte e data. |
| Traduzir em requisito | Fiscal funcional | TI e integrador | Regra funcional ligada à premissa. |
| Parametrizar ou desenvolver | TI/Integrador | Fiscal funcional | Configuração, versão e registro de alteração. |
| Preparar e executar o teste | Equipe de homologação | Fiscal, TI, integrador e negócio | Massa, passos, saída, protocolo e status. |
| Reconciliar ponta a ponta | Fiscal/Contabilidade | Financeiro e TI | Pedido, DFe, apuração, razão e financeiro conciliados. |
| Aceitar ou liberar com ressalva | Patrocinador designado | Donos do risco e da operação | Decisão, pendências, responsável, prazo e gatilho. |
Um mesmo profissional pode ocupar mais de uma função em estruturas menores, desde que a concentração seja explícita. Para pontos materiais, uma revisão independente pode ser útil quando quem configurou também produziu a única evidência e aprovou o próprio resultado.
O art. 147 da Resolução CGIBS nº 6/2026, para o IBS, e o art. 147 do Decreto nº 12.955/2026, para a CBS, atribuem ao emitente a responsabilidade pela “veracidade e exatidão das informações”. Isso reforça a necessidade de um dono interno para a conclusão, sem transformar o integrador em responsável universal por fatos, cadastros e decisões que a empresa não forneceu.
Quais informações preparar antes de pedir proposta
Imagem editorial ilustrativa criada para a TaxUp; não retrata cliente ou projeto real.
Uma proposta precisa conhecer o perímetro sem exigir que a empresa exponha toda a sua base no primeiro contato. Comece por uma ficha de escopo: entidades e regimes, atividades, catálogo de operações, documentos emitidos e recebidos, módulos do ERP, integrações, cronograma, ambientes disponíveis e responsáveis internos.
Na etapa seguinte, organize contratos e fluxos relevantes, cadastros fiscais, exemplos anonimizados de documentos, regras existentes, mapa de interfaces, plano de contas, forma de apuração e divergências já conhecidas. Quando a massa contiver dados pessoais, a LGPD, no art. 6º, III, exige a “limitação do tratamento ao mínimo necessário”, e o art. 46 exige medidas aptas a “proteger os dados pessoais de acessos não autorizados”. Para segredo comercial e informação de cliente, a proposta operacional da TaxUp é delimitar acesso, finalidade, ambiente e canal antes de compartilhar a amostra. Uma massa sintética costuma bastar para muitos testes estruturais; testes semânticos podem exigir amostras representativas devidamente protegidas.
Registre também a base técnica: ato normativo, nota técnica, manual, XSD, pacote, endpoint, ambiente e data. A página oficial da documentação de produção da NFS-e é separada da página de produção restrita. Um teste sem essa identificação pode ser impossível de reproduzir depois.
Para transformar as operações em casos executáveis, use o caderno de 24 testes de ERP para a Reforma Tributária como referência de estrutura. Para a frente de documentos eletrônicos, consulte também a análise do layout da NF-e na NT 2025.002, sempre conferindo a versão técnica efetivamente aplicada ao projeto. Os casos são propostas de teste e precisam ser adaptados e executados; não provam que um sistema específico passou.
Como comparar propostas sem comparar objetos diferentes
Fonte: TaxUp; elaboração editorial própria.
Preço por hora e número de reuniões dizem pouco quando o objeto continua aberto. Compare as propostas na mesma grade e peça que cada concorrente indique expressamente o que entrega, de quem depende e qual conclusão poderá sustentar.
| Critério | Pergunta de comparação | Sinal de lacuna |
|---|---|---|
| Perímetro | Quais CNPJs, operações, DFe, módulos e integrações entram? | “Todos os cenários” sem inventário. |
| Entregáveis | Haverá matriz, requisitos, evidências, relatório e termo de aceite? | Atividade descrita sem produto verificável. |
| Nível da conclusão | A entrega revisa premissa, configuração, resultado ou reconciliação? | “Validação completa” sem separar camadas. |
| Dependências | Quem fornece dados, ambiente, massa, acesso e decisão? | Prazo sem condição de início ou bloqueio. |
| Mudança | O que acontece se norma, NT, XSD ou processo mudar? | Reteste e atualização não tratados. |
| Aceite e retrabalho | Como se registra reprovação, correção, ressalva e nova submissão? | Aceite tácito sem trilha ou prazo de saneamento. |
A TaxUp preparou um modelo editável de termo de escopo e aceite tributário em CSV. Ele contém campos para operação, premissa, fonte, versão, responsáveis, evidência, dependências, exclusões, pendências e decisão. As linhas preenchidas são exemplos sintéticos; o arquivo é um ponto de partida educacional, não uma cláusula contratual pronta, certificação ou parecer.
O que constitui evidência suficiente para o aceite
Fonte: TaxUp; elaboração editorial própria.
O aceite deve permitir que outra pessoa reconstrua o que foi decidido e testado. Para cada cenário, preserve a identificação da operação e da entidade, a premissa tributária, a fonte oficial e sua versão, o responsável pela decisão, a configuração relacionada, a entrada usada, o resultado esperado, a saída observada e o aprovador.
Inclua provas positivas e negativas. Uma autorização esperada mostra que o fluxo aceitou um caso válido. Uma rejeição esperada, com o motivo correto, mostra que o sistema barrou um caso inválido. A regulamentação do IBS classifica como inidôneo, no art. 122, IV, da Resolução CGIBS nº 6/2026, o documento que não corresponde efetivamente à operação. Por isso, validar apenas XML, schema e retorno técnico não cobre a correspondência material.
A trilha deve alcançar contingência e eventos. Para o IBS, os arts. 136 a 138 da Resolução CGIBS nº 6/2026 preveem a transmissão ao autorizador depois de cessado o problema técnico; os arts. 140, 144 e 145 condicionam os efeitos do evento ao registro aceito. Para a CBS, os arts. 136 a 138, 140, 144 e 145 do Decreto nº 12.955/2026 trazem a disciplina paralela. Cancelamento, correção ou manifestação não estão provados apenas porque o documento original foi autorizado.
| Estado | Significado | Decisão permitida |
|---|---|---|
| Aprovado | Resultado esperado e observado coincidem, com evidência completa. | Aceitar o item no recorte e na versão testados. |
| Reprovado | Há divergência reproduzível entre requisito e resultado. | Corrigir e submeter a novo teste. |
| Bloqueado | Dependência impediu a execução ou a conclusão. | Resolver a dependência; não converter em aprovação. |
| Não executado | O cenário não foi rodado. | Manter fora da cobertura declarada. |
| Aceito com ressalva | O risco foi compreendido e assumido por responsável competente. | Registrar alcance, impacto, responsável, prazo e gatilho de fechamento. |
A reconciliação deve acompanhar o fluxo relevante: pedido ou contrato, faturamento, XML, autorização, evento, financeiro, escrituração, apuração e razão. Ela aumenta a qualidade da evidência, mas não garante ausência de erro ou risco futuro.
Como tratar mudança de versão, regra ou processo
Fonte: TaxUp; elaboração editorial própria.
O aceite é sempre limitado ao recorte e à baseline testados. Uma alteração de nota técnica, XSD, manual, endpoint, cadastro, contrato, operação ou código pode invalidar parte da evidência anterior. O procedimento de mudança deve identificar o gatilho, avaliar os cenários afetados, atualizar o requisito, retestar e registrar nova decisão.
O Ato Conjunto RFB/CGIBS nº 4/2026 ilustra por que um cronograma único é insuficiente: o art. 1º distribui marcos diferentes conforme o documento e o perfil do contribuinte. NF-e e NFC-e receberam marco em 3 de agosto de 2026; a NFS-e tem recortes em 1º de outubro e 1º de dezembro de 2026; e o §1º trata do Simples Nacional em 1º de janeiro de 2027. Essas datas não provam que toda regra esteja disponível no mesmo ambiente e versão.
O Ato Conjunto RFB/CGIBS nº 5/2026 descreve adaptação assistida em 2026, com aumento progressivo do preenchimento correto, resposta a comunicações e correção de inconsistências. Isso não representa aprovação automática do ERP. A tolerância transitória do art. 348, §§3º e 4º, da LC nº 214/2025 é limitada aos fatos geradores de 2026 e às condições ali previstas; não é anistia geral nem dispensa de saneamento.
O registro mínimo de mudança contém fonte anterior e nova, data da comparação, operações impactadas, testes reabertos, decisão temporária e responsável. Sem isso, a empresa pode apresentar como atual uma evidência produzida em outro ambiente ou contra uma versão superada.
Como levar a decisão à diretoria
Fonte: TaxUp; elaboração editorial própria.
A diretoria não precisa receber centenas de capturas de tela. Precisa entender o que foi coberto, quais riscos permanecem, quanto custa cada caminho e quem assume a decisão. O relatório executivo deve ser rastreável ao detalhe, sem transportar toda a documentação técnica para a primeira página.
Considere um exemplo sintético. Uma empresa testa 42 cenários materiais: 33 são aprovados, quatro reprovados, três bloqueados e dois não executados. Informar apenas “79% aprovado” esconde diferenças decisivas. Se um bloqueado envolve o principal fluxo de faturamento e um reprovado afeta cancelamentos de alto valor, a média não sustenta a liberação.
| Opção | Condição | Efeito a apresentar |
|---|---|---|
| Liberar | Cenários críticos aprovados; demais itens têm cobertura e evidência compatíveis. | Risco residual, monitoramento e responsáveis. |
| Liberar parcialmente | Operações delimitadas podem funcionar; outras permanecem bloqueadas. | Perímetro liberado, trava operacional e prazo. |
| Liberar com ressalva | Pendência compreendida e aceita por quem tem competência. | Impacto, contingência, dono, data e gatilho de revisão. |
| Não liberar | Falha material, ausência de evidência ou dependência crítica. | Correção necessária, custo, prazo e nova rodada de teste. |
O memorando deve mostrar baseline, cobertura por processo, itens críticos, alternativas, recomendação, orçamento e decisão requerida. Contagem sem materialidade não é painel de risco. Ressalva sem responsável e prazo é apenas uma pendência escondida no rodapé.
Perguntas frequentes sobre validação tributária no ERP
Fonte: TaxUp; elaboração editorial própria.
O que deve entrar no escopo da validação tributária de um ERP?
O escopo deve identificar entidades, regimes, operações, documentos, módulos, integrações, datas e ambientes, além de separar revisão de premissas, tradução funcional, parametrização, execução de testes, reconciliação e revisão do aceite. Dependências e exclusões precisam ser expressas para que a proposta não prometa uma cobertura que os dados ou o contrato não permitem demonstrar.
Qual é a diferença entre homologação técnica e validação tributária?
A homologação técnica verifica se integrações, campos, formatos e retornos funcionam conforme o requisito. A validação tributária examina também se a premissa e o resultado correspondem à operação real e à fonte aplicável. As duas atividades se conectam, mas uma resposta técnica de autorização não substitui a conclusão tributária.
Quem deve definir a regra tributária usada pelo sistema?
A empresa precisa designar um responsável com acesso aos fatos e competência para aprovar a premissa, normalmente com participação fiscal e jurídica. O integrador pode traduzir e implementar requisitos, mas não deve ser presumido como dono de informações, contratos e decisões que não recebeu. A distribuição final depende da estrutura e do contrato concretos.
O integrador assume a responsabilidade tributária da empresa?
Não automaticamente. Os arts. 121 e 123 do CTN impedem que uma convenção particular altere, por si, a definição legal do sujeito passivo perante o Fisco. O contrato pode disciplinar deveres de entrega, correção, cooperação, responsabilidade civil e alocação de riscos entre as partes, sempre conforme seus limites e a legislação aplicável.
Uma nota autorizada prova que a tributação está correta?
Não. O art. 132, I, da Resolução CGIBS nº 6/2026, para o IBS, e o art. 132, I, do Decreto nº 12.955/2026, para a CBS, afirmam que a autorização não implica validação das informações do documento fiscal. É preciso conferir operação, cadastro, regra, valores, eventos e reflexos posteriores.
É possível liberar o sistema com pendências?
É possível que a governança admita uma liberação parcial ou com ressalva, mas a decisão deve delimitar o perímetro, explicar o risco, prever controle temporário, indicar responsável e prazo e definir o gatilho de fechamento. Item bloqueado ou não executado não deve ser silenciosamente convertido em aprovado.
Quando o suporte do fornecedor basta e quando contratar revisão independente?
O suporte do fornecedor pode bastar para uma configuração técnica de baixo risco, apoiada em documentação clara, quando a empresa define a premissa, executa testes representativos, reconcilia os resultados e mantém uma revisão interna competente por pessoa diferente de quem parametrizou. Uma revisão independente tende a ser útil em operações materiais, interpretações controvertidas, grande concentração de funções ou situações em que a mesma parte decidiu, configurou, testou e aprovou. O próprio integrador pode contratar o revisor com ciência do cliente e papéis separados, mas essa camada não substitui os fatos fornecidos pela empresa nem a decisão final de aceite.
Quando o aceite precisa ser reaberto?
Reabra os itens afetados quando mudar a norma, a nota técnica, o XSD, o manual, o endpoint, o ambiente, o cadastro, a operação, o contrato ou o código. A avaliação de impacto deve apontar quais requisitos e testes perderam validade e qual baseline passará a governar a nova decisão.
A TaxUp certifica que o ERP está correto?
Não se deve prometer certificação absoluta. Um trabalho pode revisar premissas, requisitos, cenários, evidências, reconciliações e critérios de aceite dentro de um perímetro definido. A conclusão precisa declarar amostra, versão, ambiente, limitações e pendências; mudanças posteriores podem exigir nova análise.
Fontes, atualização e limites
Este artigo foi conferido em 7 de setembro de 2026 com a LC nº 214/2025 consolidada, o CTN, o Código Civil, a LGPD, a Resolução CGIBS nº 6/2026, o Decreto nº 12.955/2026, os Atos Conjuntos RFB/CGIBS nº 4 e nº 5 de 2026 e a documentação técnica oficial de NFS-e. O Decreto regulamenta a CBS; a Resolução sustenta os dispositivos paralelos do IBS. Jurisprudência e doutrina não foram usadas porque as fontes primárias respondem diretamente às premissas desta peça. O método deve ser adaptado ao contrato, ao tipo de DFe, ao regime, à operação e às versões efetivamente disponíveis.
Para delimitar um projeto, reúna o mapa de entidades e operações, os documentos e módulos envolvidos, o cronograma, a versão do ambiente e as decisões ainda sem responsável. A página de consultoria para adequação à Reforma Tributária apresenta o trabalho da TaxUp; empresas de tecnologia também podem consultar a frente para tecnologia e SaaS. Para conversar sobre um caso concreto, agende um diagnóstico.
Discutir um caso concreto da sua empresa
30 minutos com consultor sênior. Mapeamos o cenário tributário específico, identificamos as oportunidades aplicáveis e indicamos o caminho técnico — independentemente de você seguir conosco.
Agendar diagnóstico gratuito 30 minutos com consultor sênior. Sem compromisso.