contato@taxup.com.br   São Paulo · Rio de Janeiro · Brasília
PT EN
ANáLISE TéCNICA

ERP SaaS e reforma tributária: como testar a adequação

Os testes de ERP para SaaS na reforma tributária precisam acompanhar a operação do contrato ao fechamento. A emissão prevista no art. 60 da LC 214/2025 é parte desse percurso, mas uma nota autorizada não demonstra que classificação, retenções, eventos e apuração estão corretos. Este roteiro propõe 16 cenários para uma empresa SaaS, com entradas e critérios de conferência. Eles são controles sugeridos, não uma lista imposta pela lei. Nenhum dos testes descritos foi executado em sistema de cliente, e o material não certifica a conformidade de um ERP.

Fontes do requisito documental: LC 214, arts. 60 e 62 e Decreto 12.955/2026, arts. 115 a 144.

Testes de ERP para SaaS: acompanhar o fornecimento

Eu não consideraria suficiente um teste que termina na mensagem de autorização. O sistema pode transmitir corretamente uma classificação errada ou conservar na apuração um documento já substituído. A conferência precisa alcançar o significado do dado e o resultado posterior.

O primeiro conjunto de cenários deve representar a carteira de operações: licença, implantação, suporte, intermediação, compras e eventos posteriores. Não é necessário copiar informações reais de clientes para isso. Dados sintéticos permitem demonstrar a regra sem expor contratos, pessoas ou valores identificáveis.

Teste do ERP SaaS até o fechamento: contrato, documento, autorização, eventos e conciliação.
Percurso de controle sugerido. Uma resposta de autorização não encerra a conferência.LC 214, arts. 60 e 62; manual da API de NFS-e, itens 1.2 a 1.5.
Baixar figura (PNG)

A NFS-e em software e SaaS fornece a ponte entre os fatos e os campos. Antes de testar um cClassTrib, o fiscal precisa ter definido o tratamento correspondente. Antes de testar um repasse, o jurídico precisa ter concluído a análise de conta e ordem e reembolso de despesas. O teste técnico não substitui essas decisões.

Registrar a versão e o ambiente antes de interpretar a resposta

O plano deve identificar o modelo do documento, a nota técnica, o esquema, as tabelas e o ambiente. Um resultado obtido em produção restrita não demonstra, por si, que a mesma função foi implantada em produção. Os índices oficiais da NFS-e publicam pacotes próprios para cada ambiente. Documentação de produção e produção restrita.

O mesmo vale para cronogramas. A NT 2025.002 v1.51 remete a implementação em produção da UB12-10 à data futura. Um teste de NF-e sem grupo IBS/CBS precisa registrar o que o ambiente fez e qual regra estava ativa; não pode considerar a autorização como prova de dispensa jurídica. NT 2025.002 v1.51, p. 42.

Na NFS-e, a publicação da NT 009 não equivale à disponibilidade dos seus grupos. O portal RTC explicitou a indisponibilidade em agosto de 2026 no cronograma consultado. O histórico oficial de implantação precisa ser cotejado com a documentação RTC.

Registro mínimo proposto Por que guardar
Data, ambiente e autorizador Permitir reproduzir o contexto da resposta
Versão da NT, XSD e tabelas Identificar a regra efetivamente testada
Operação e fundamento Relacionar o campo à conclusão fiscal
Entrada e resultado esperado Evitar interpretar qualquer retorno como aprovação
Retorno recebido e protocolo Demonstrar o que ocorreu no sistema
Reflexo no fechamento Conferir se o documento produziu o efeito esperado

Essa ficha é uma proposta de governança. Os formatos obrigatórios de documento e evento devem ser conferidos nas fontes próprias.

Dezesseis cenários para uma bateria que encontre erros

Uma bateria útil inclui situações corretas e situações que devem provocar rejeição, impedimento interno ou revisão. Se o teste aceita tudo, ele não demonstra que o controle consegue detectar um problema.

ID Entrada sintética Critério de conferência proposto
T01 Contrato com licença, implantação e suporte Cada fornecimento recebe classificação fundamentada; não copiar um código indiscriminadamente
T02 NF-e de emitente regular sem grupo IBS/CBS Registrar resposta e regra ativa; autorização não vira conclusão de conformidade material
T03 Grupo informado com estrutura ou CST incompatível Identificar a validação pertinente e demonstrar que o erro não foi ignorado
T04 Débitos próprios e retenções de valores diferentes Conferir campos, líquido e ausência de abatimento duplicado
T05 Contratante A, destinatário B e pagador C Preservar os papéis reais; não deslocar o adquirente para gerar crédito
T06 Repasse comprovado e custo próprio de igual valor Aplicar as conclusões jurídicas distintas, sem deixar o campo decidir a base
T07 Substituição vinculada à nota anterior Relacionar original, evento e nova nota; evitar dupla apuração
T08 Pedido de cancelamento fora da hipótese admitida Manter a pendência quando o evento não for aceito
T09 Falha de comunicação após o envio Consultar a situação antes de retransmitir e criar duplicidade
T10 Contingência simulada Seguir o procedimento do documento e a regularização cabível
T11 Operação nos períodos de 2026, 2027 e 2029 Usar parâmetros do período, sem retroagir tabelas futuras
T12 Fornecedor no DAS e, depois, no regime regular Preservar regime e tratamento de cada período
T13 Servidor imobilizado e mercadoria nova em estoque Distinguir as trilhas dos arts. 380 e 381 da LC 214
T14 Boleto vinculado, mas não pago Não converter vínculo de pagamento em quitação
T15 Serviço de segurança elegível e software genérico Aplicar benefício apenas após comprovação dos requisitos
T16 Lote com emissões, rejeições, cancelamentos e substituições Reconciliar documentos válidos, eventos e valores, não apenas respostas recebidas

As fontes dos critérios variam: NT 007, item 2, c, para retenções; manual da API de NFS-e, itens 1.2 a 1.5, para consulta, substituição e eventos; LC 214, arts. 142, 380 e 381, para exceções e transição.

O caderno de homologação organiza o registro desses casos. Os 16 cenários não são quantidade de testes aprovados; são o ponto de partida proposto para uma execução que ainda precisa ocorrer.

Uma substituição pode revelar erro de R$ 10 mil no fechamento

Considere uma NFS-e fictícia com valor de serviço de R$ 10.000. Por hipótese, é admitida e aceita sua substituição por uma nova nota de R$ 9.000. O documento original recebe o evento correspondente. O objetivo deste exemplo é conferir o conjunto documental válido, não calcular imposto ou presumir que qualquer redução de preço permite substituição.

Estado do exemplo Valor Tratamento na conferência
Nota original substituída R$ 10.000 Conservar no histórico, identificada como substituída
Nova nota válida R$ 9.000 Relacionar ao evento e à chave de origem
Soma indevida das duas como válidas R$ 19.000 Resultado que o controle deve detectar
Valor dos documentos válidos nessa hipótese R$ 9.000 Resultado esperado para esse objeto de conferência
Substituição fictícia: nota válida de R$ 9 mil versus soma indevida de R$ 19 mil; diferença é erro de contagem, não economia.
Original de R$ 10 mil substituída, por hipótese admitida, por nota de R$ 9 mil. Diferença de R$ 10 mil é erro de contagem, não economia tributária.Tabela do texto; manual da API, itens 1.3.2 e 1.5. Nenhum teste real realizado.
Dados da figura
Categoria Valor
Valor válido esperado R$ 9.000,00
Soma indevida das duas notas R$ 19.000,00

CSV

Baixar figura (PNG)

A diferença de R$ 10.000 nasce da contagem indevida do documento anterior. Não é economia tributária nem crédito recuperado. Um sistema pode ter recebido corretamente a nova nota e ainda assim carregar a original no relatório utilizado pela controladoria.

O manual da API explica a geração de nova NFS-e e do evento de cancelamento por substituição nas condições pertinentes. O teste precisa observar essa cadeia e a resposta real. Trocar apenas o status na tela do ERP não comprova que o autorizador processou o evento. Manual da API, itens 1.3.2 e 1.5.

Pagamento, contingência e comunicação merecem testes separados

A NT 2026.006 da NF-e prevê vinculação entre operação e transação de pagamento em preparação para o split payment. Seu cronograma e seu caráter preparatório não devem ser resumidos como obrigação universal em 2026. Boleto identificado não é boleto liquidado. O teste T14 existe para impedir que o sistema transforme uma referência técnica em baixa financeira. NT 2026.006, p. 3 e itens 1 a 5.

O T09 examina outra falha comum de desenho: o sistema não sabe se a transmissão foi processada porque perdeu a resposta. A consulta prevista no fluxo da DPS/NFS-e ajuda a distinguir documento existente de nova tentativa. O comportamento concreto deve observar o manual e os identificadores aplicáveis, sem inventar uma regra de retransmissão universal.

Na contingência, a equipe deve usar o procedimento do modelo, inclusive a regularização posterior cabível. Os arts. 135 a 144 do Decreto 12.955 tratam de aspectos como documento auxiliar, contingência e eventos. A forma operacional precisa ser conferida no documento específico. Decreto 12.955, arts. 135 a 144.

Quem aprova cada camada do resultado

O fiscal deve aprovar a classificação e a memória de cálculo. TI precisa demonstrar que o sistema envia, recebe e interpreta as respostas conforme a versão. A controladoria confere a reconciliação com faturamento e apuração. O jurídico examina as exceções e os fatos contratuais que alteram o tratamento.

Essa divisão é sugerida, não uma exigência de criar cargos ou comitês específicos. O ponto verificável é que cada conclusão tenha responsável e evidência. Uma única pessoa pode acumular funções; isso não elimina a necessidade de conferir as camadas distintas.

O teste de crédito também precisa estar ligado ao regime do fornecedor e aos documentos da compra. O teste de benefício deve remeter à redução para segurança da informação. O software não pode conceder uma exceção apenas porque a descrição contém “segurança”.

Critério de liberação e tratamento das pendências

Antes da liberação, a equipe precisa conhecer quais cenários foram executados, quais passaram e quais continuam sem conclusão. Ausência de teste não deve ser classificada como sucesso. Falha corrigida exige nova execução no contexto pertinente, com preservação do resultado anterior.

O critério proposto é liberar a função quando a operação tiver fundamento validado, resposta compatível com a regra do ambiente e reflexo reconciliado no fechamento. Quando houver mudança de NT, tabela ou parametrização, o responsável deve identificar os casos afetados e repetir a conferência necessária.

O diagnóstico de adequação para tecnologia e SaaS pode delimitar esse escopo por operação e risco. A entrega útil é um conjunto reproduzível de evidências e pendências, com responsáveis, e não uma declaração genérica de que o ERP está pronto.

Caderno de testes para ERP e faturamento SaaS

Este caderno contém 24 casos propostos, todos não executados. Os 16 primeiros detalham a bateria apresentada neste artigo; os oito seguintes acrescentam controles de crédito, preço, datas e operação internacional. Sua finalidade é registrar resultados reproduzíveis. Não se trata de certificado de homologação, pacote oficial de testes ou prova de que um ERP já está preparado.

O art. 60 da LC 214 dá o contexto documental. A versão do leiaute, o ambiente, a regra de validação e o documento efetivamente processado precisam ser identificados em cada execução. Uma regra prevista para implementação futura não pode ser registrada como rejeição obrigatória já ativa.

Baixar o caderno editável em CSV. Os campos “resultado observado”, “evidência” e “executor” começam vazios. O status inicial de todas as linhas é “não executado”.

Preparação que antecede o envio

Use dados de teste permitidos pelo ambiente e documentos sintéticos. Registre versão do ERP, data, pacote XSD, tabelas utilizadas, emissor e configurações relevantes. Não envie dados de clientes para ambientes ou ferramentas que não tenham autorização para recebê-los. O ensaio deve ocorrer na homologação adequada, com responsáveis definidos e sem emissão fiscal real por engano.

Antes do teste, escreva o resultado esperado em dois campos conceituais: resposta do autorizador e decisão do controle interno. Nem sempre serão iguais. Se a validação automática ainda não foi ativada, pode haver autorização; isso não elimina o dever de classificar corretamente a operação nem autoriza concluir que o documento está materialmente correto. NT 2025.002 v1.51, regra UB12-10.

Casos e critérios de aceitação do controle

ID Caso sintético O que precisa ser demonstrado
T01 Licença, implantação e suporte no mesmo relacionamento Classificações fundamentadas por fornecimento; nenhuma herança indiscriminada de código
T02 NF-e sem grupo IBS/CBS Resposta real vinculada à versão da regra; autorização não encerra a conferência jurídica
T03 Grupo informado com estrutura incompatível Erro estrutural identificado pela validação aplicável ou pelo controle interno, sem aceitação silenciosa
T04 Contribuição própria diferente da retenção Campos, soma e valor líquido corretos, sem reduzir duas vezes a mesma retenção
T05 Adquirente, destinatário e pagador distintos Preservação dos papéis comprovados; pagador não substitui automaticamente adquirente
T06 Custo próprio e gasto em conta e ordem de igual valor Bases tratadas conforme os fatos e documentos, não pelo nome da conta ou do campo
T07 Substituição admitida de nota de R$ 10 mil por R$ 9 mil Cadeia original/evento/nova nota preservada e total documental válido de R$ 9 mil
T08 Cancelamento pedido sem enquadramento ou não aceito Pendência mantida, sem retirar silenciosamente a nota válida da apuração
T09 Comunicação interrompida após o envio Consulta de situação e tratamento da resposta antes de retransmissão indevida
T10 Contingência, quando admitida para aquele documento Procedimento, justificativa e regularização do modelo utilizado
T11 Mesma operação em 2026, 2027 e 2029 Parâmetros de cada período preservados, sem aplicar regra futura ao passado
T12 Fornecedor muda do DAS para regime regular Tratamento vinculado à vigência efetiva do regime em cada operação
T13 Bem do imobilizado e mercadoria nova em estoque Trilhas dos arts. 380 e 381 separadas, sem tratar licença SaaS como estoque material
T14 Documento vinculado a boleto ainda não pago Vínculo não convertido em extinção de débito ou disponibilidade de crédito
T15 Segurança da informação elegível e software genérico Redução condicionada à prova dos requisitos, sem decisão baseada apenas no CNAE
T16 Lote com autorização, rejeição, cancelamento e substituição Reconciliação por documento, estado, evento e valor, além da contagem de respostas
T17 Compra com documento, mas extinção ainda não demonstrada Crédito classificado conforme arts. 47 e 48 e a implementação pertinente, sem presumir disponibilidade
T18 Recolhimento já realizado por split payment Saldo não deduz novamente o valor já conciliado como extinto
T19 Crédito recebido em documento emitido para outra pessoa Divergência de identidade bloqueia o tratamento automático e exige correção apropriada
T20 Preço total e preço líquido com taxa de teste de 26% Sobre R$ 126 mil totais, base de R$ 100 mil; sobre R$ 126 mil líquidos, total de R$ 158.760
T21 Pagamento anterior à exigibilidade em assinatura continuada Cronologia alimenta o evento legal pertinente e eventual ajuste, sem copiar a competência contábil
T22 Adquirente estrangeiro e destinatário brasileiro Controle não classifica exportação imaterial apenas pelo país do pagador
T23 Documento estrangeiro com câmbio bancário distinto da PTAX aplicável Base regulamentar reconciliada com a taxa e a data exigidas, sem substituir por câmbio econômico
T24 Cliente atrasado e contrato ainda executado Atraso não cria automaticamente cancelamento ou crédito por dívida inadimplida

Os casos T04 e T07 exigem leitura dos campos da NT 007 e dos procedimentos do manual da API nacional. Os casos de crédito usam os arts. 45, 47 e 48 da LC 214. A conversão do T23 observa o art. 13, § 4º, do regulamento da CBS. Esses critérios não inventam códigos de rejeição para o autorizador.

Resultado esperado não é resultado observado

No T07, o resultado de R$ 9 mil pressupõe uma substituição juridicamente admitida e efetivamente aceita. Se o evento foi rejeitado, o executor registra a rejeição e conserva o estado documental real. Não se altera a evidência para fazer a linha “passar”. No T20, 26% é uma taxa arbitrária para verificar aritmética; não representa alíquota aprovada de SaaS. O primeiro cálculo é 126.000 ÷ 1,26; o segundo é 126.000 × 1,26.

Cada evidência deve permitir a outra pessoa refazer a conclusão: identificador de teste, entrada sintética, resposta, evento, versão e relatório final. Captura de tela isolada pode ajudar, mas não substitui o documento processado e a conciliação quando estes são necessários para entender o resultado.

Como encerrar uma rodada

Separe “aprovado no controle”, “reprovado”, “bloqueado por dependência” e “não executado”. Compare o total planejado com os quatro grupos e explique qualquer item retirado ou duplicado. Não transforme dependência em aprovação. Um caso bloqueado por funcionalidade ainda não disponível informa uma lacuna operacional; não prova descumprimento do fornecedor nem dispensa a obrigação aplicável.

O parecer da rodada deve indicar quais combinações foram ensaiadas e quais ficaram de fora. A homologação de uma licença mensal doméstica não demonstra que importação, exportação, plataforma e cancelamento funcionam pelo mesmo caminho. Use o calendário de transição para delimitar datas, o guia de NFS-e para software para o leiaute e a matriz de revisão contratual para ligar cada mudança comercial ao teste correspondente.

Perguntas frequentes

A lei exige exatamente esses 16 testes?

Não. A bateria é uma proposta de controle construída a partir das obrigações e da documentação técnica consultadas. A empresa precisa adaptar os casos às suas operações. Não há certificação de sistema ou execução real embutida neste artigo.

Uma nota autorizada é suficiente para aprovar a homologação?

Não. É preciso verificar a conclusão fiscal que gerou os campos, as regras ativas no ambiente e o efeito posterior na apuração. O sistema pode aceitar um arquivo que não demonstra a correção material do fornecimento.

O teste pode ser feito apenas em produção restrita?

Esse ambiente é adequado às verificações que comporta, mas o resultado deve ser relacionado à sua versão e às funções disponíveis. A passagem para produção exige conferir o cronograma, o pacote aplicável e os procedimentos de implantação. Não se deve presumir que os ambientes são idênticos.

Como evitar duplicidade depois de uma falha de comunicação?

O roteiro deve prever a consulta da situação do documento pelos identificadores pertinentes antes de decidir a retransmissão. A regra concreta depende da API e do modelo. O teste precisa demonstrar que uma resposta perdida não virou duas operações no fechamento.

Os dados sintéticos substituem a conferência jurídica dos contratos?

Não. Eles permitem testar o comportamento esperado sem expor dados de clientes. A conclusão que define esse comportamento precisa ser fundamentada. Na implantação efetiva, a empresa deve verificar se seus contratos e operações correspondem às hipóteses testadas.

Diagnóstico gratuito

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.