Fechamento fiscal pós go-live no SAP: o teste que o cronograma de implantação não agenda

Um go-live aprovado pelo faturamento ainda não foi aprovado pelo fiscal. Em operações de varejo alimentar de proximidade, essa diferença custa caro justamente no mês em que menos se espera erro. O projeto termina, a diretoria comemora, a imprensa registra o marco. Só que a aprovação que realmente importa para quem assina o resultado do mês não acontece no dia da virada de chave. Acontece semanas depois, quando o primeiro fechamento fiscal roda no sistema novo e precisa bater com o livro, com o SPED e com a realidade da operação.

Faturamento sobe, estoque bate, loja funciona. Isso prova pouco sobre fiscal.

O que fica de fora do escopo de go-live

Projetos de implantação SAP em redes de varejo alimentar costumam ser desenhados em torno de três frentes visíveis: loja, logística e programa de fidelidade. Faz sentido: é o que o cliente final enxerga, é o que justifica o investimento perante o conselho. O módulo fiscal entra como anexo técnico, não como entregável com peso próprio, tratado como parametrização herdada do sistema anterior em vez de projeto com critério de aceite independente.

O problema não é a prioridade em si. É que a arquitetura fiscal de uma rede com operação multiloja e multiestado só se revela por completo quando passa por um ciclo fechado de apuração. Cadastro de produto, tabela de preço e integração de caixa podem ser validados loja por loja, transação por transação, sem dizer nada sobre o comportamento agregado do mês. Regra fiscal não se testa por amostragem de transação. Se testa fechando o mês inteiro e comparando com o que a legislação exige naquela competência.

Isso significa que times de projeto aprovam o go-live com o critério errado para a parte fiscal. Testam se a nota sai. Não testam se a nota, multiplicada por todas as lojas e todos os CFOP do período, fecha com o SPED sem glosa, sem divergência de ICMS-ST e sem ajuste manual de última hora. O teste que falta não está no plano de corte.

Aparece sozinho, no primeiro fechamento, sem aviso prévio.

Em redes que trocam de sistema fiscal, é comum conviver por meses com dois critérios de parametrização dentro do mesmo cadastro: o que foi migrado como estava no sistema antigo e o que foi configurado do zero no projeto novo. Quando o fechamento mistura CFOP de origens diferentes, natureza de operação herdada de regra antiga e Tax Code configurado sob a lógica nova, a apuração de ICMS passa a depender de exceção manual para não distorcer o resultado. Essa exceção manual raramente é documentada como risco. É tratada como ajuste pontual, até virar rotina.

Por que o calendário de outubro a dezembro aperta justamente agora

Quem planejou o go-live para o segundo semestre de 2026 provavelmente mirou a estabilização antes do pico de fim de ano. É decisão operacional defensável. O problema é que o calendário fiscal não negociou esse prazo com ninguém: o Ajuste SINIEF 23/26, do CONFAZ, entra em vigor produzindo efeitos a partir de 5 de outubro de 2026, trocando a obrigatoriedade de NF-e no lugar de NFC-e sempre que o adquirente aproveita crédito de ICMS. Para varejo alimentar com venda para pessoa jurídica no balcão, revenda ou food service, essa regra muda o documento fiscal certo a emitir, não um detalhe de layout.

No mesmo período, está em curso a Nota Técnica 2026.007, versão 1.00, do Portal Nacional da NF-e, divulgada em julho de 2026, que atualiza as regras de validação de NF-e e NFC-e para contribuinte sujeito a IBS e CBS, incluindo verificação de cadastro contra a Lista Centralizada de Contribuintes (data exata de entrada em produção não conferida nesta leitura). Rede com sistema novo, calendário recém-concluído e ainda sem um ciclo fechado de apuração vai validar essa mudança, somada ao Ajuste SINIEF, no momento em que a equipe de projeto já declarou vitória e está de olho na operação de fim de ano.

Encaixar essas duas mudanças é trabalho de parametrização fina: tabela de CFOP, regra de determinação de documento, DRC e mapeamento de cadastro fiscal, revisados sob pressão de prazo regulatório, não de cronograma de projeto. Cada venda de balcão para pessoa jurídica com aproveitamento de crédito passa a exigir que o sistema decida, no momento da emissão, entre NF-e e NFC-e, uma decisão que antes do ajuste não existia como bifurcação obrigatória no fluxo de caixa de loja.

A pior combinação possível é sistema novo mais regra nova mais inventário de 31 de dezembro acontecendo ao mesmo tempo, sem que nenhum dos três tenha sido o motivo original do projeto.

O inventário de fim de ano, por si só, já expõe falha de parametrização de estoque em qualquer migração recente. Combinado com mudança regulatória de validação de nota fiscal entrando em vigor na mesma janela, o que seria um fechamento de dezembro comum vira um teste de estresse não planejado. É simplesmente o calendário público de 2026 colidindo com um cronograma de projeto pensado antes de essas normas serem publicadas.

O primeiro fechamento como prova real do projeto

Em qualquer migração para S/4HANA ou reimplantação de ECC em varejo, existe um momento em que a empresa descobre se o desenho fiscal foi feito de verdade ou foi herdado por cópia do sistema anterior. Esse momento é o primeiro fechamento de competência inteira no ambiente novo. Antes disso, o sistema roda transação por transação e qualquer inconsistência parece isolada. No fechamento, as inconsistências se somam, aparecem no livro fiscal e precisam ser explicadas antes da transmissão da EFD.

Um padrão que tende a se repetir nesse perfil de pós go-live: quando o desenho fiscal entra depois do desenho de loja e logística, o time fiscal recebe o sistema pronto e descobre, só no fechamento, que determinada combinação de CFOP e natureza de operação não foi parametrizada para o cenário real da rede. A correção vira ajuste manual, o ajuste manual vira exceção recorrente, e a exceção recorrente é o início de uma arquitetura fiscal que ninguém documentou de propósito.

O risco aqui não é técnico no sentido estrito. É de responsabilidade.

Quem assina o fechamento assume que o número bate com a legislação vigente naquela competência, inclusive as mudanças que entraram em vigor no meio do caminho. Se o sistema foi aceito pelo critério de faturamento e estoque, mas nunca passou por um ciclo fiscal completo antes de ir para produção, a pessoa que assina está testando ao vivo, na competência real, algo que deveria ter sido testado em ambiente controlado. Isso vale tanto para a apuração de ICMS no regime normal quanto para a conferência de ICMS-ST em operações com substituição tributária, onde o erro de base de cálculo herdado da parametrização antiga só aparece quando o volume real do mês passa pelo motor fiscal inteiro.

Em redes com múltiplos CNPJ ou inscrições estaduais, o problema se multiplica por unidade: cada estabelecimento pode ter herdado uma variação própria da parametrização antiga, e o primeiro fechamento consolidado é o único momento em que essas variações aparecem lado a lado, comparáveis, e muitas vezes contraditórias entre si.

Ajuste SINIEF 23/26, CONFAZ: "Este ajuste entra em vigor na data da sua publicação no Diário Oficial da União, produzindo efeitos a partir de 5 outubro de 2026."

O que o mercado costuma fazer, e por que não resolve

A resposta mais comum da indústria para esse risco é reforçar suporte no período crítico: mais gente de plantão, mais horas de sustentação contratadas, mais reunião de acompanhamento diário na primeira semana depois do go-live. Isso ajuda a apagar incêndio pontual. Não ajuda a provar que a arquitetura fiscal do sistema novo está correta antes do fechamento acontecer de verdade.

Suporte reage ao que já quebrou; plantão resolve o sintoma, não revisa a arquitetura que o produziu. A única evidência de que a arquitetura foi revisada, e não apenas sustentada, é um relatório de simulação de fechamento anterior à competência real, com data e responsável, não um histórico de chamados resolvidos.

Outra resposta comum é aumentar o número de aprovações manuais no fechamento, como se mais revisão humana compensasse parametrização não testada. Funciona uma vez, no primeiro mês. No segundo, a mesma exceção reaparece, porque a causa raiz continua na configuração.

Evidências que sustentam a prova de fechamento

Existe um conjunto mínimo de evidências que qualquer diretor fiscal deveria reunir antes de assinar o primeiro fechamento pós go-live, independente de quem assina a entrega do projeto de TI. Primeiro: simulação de apuração de ICMS e, onde aplicável, ICMS-ST, cruzando saída fiscal com o livro, feita antes da competência real fechar. Segundo: validação de que a tabela de CFOP e a determinação de tipo de documento já refletem o Ajuste SINIEF 23/26, incluindo os casos de venda com aproveitamento de crédito pelo adquirente.

Terceiro: teste de geração de NF-e e NFC-e contra as regras de validação da NT 2026.007, incluindo a verificação de cadastro na Lista Centralizada de Contribuintes para quem já é sujeito a IBS e CBS. Quarto: reconciliação entre inventário físico de 31 de dezembro e o saldo fiscal apurado no sistema novo, porque é o primeiro ponto em que erro de parametrização de estoque vira divergência fiscal visível. Quinto: documentação de quem validou cada ponto e quando, porque auditoria futura não aceita "o sistema está funcionando" como evidência de conformidade.

Um sexto ponto, menos óbvio, costuma decidir se os cinco primeiros têm valor: rastreabilidade de quem alterou cada regra fiscal depois do go-live, e por quê. Em ambiente novo, é comum liberar ajuste rápido de Tax Code para destravar o fechamento do mês. Sem registro de quem mudou o quê e com que justificativa, a correção de hoje vira a dúvida de amanhã, no momento em que a auditoria pede explicação sobre uma divergência pontual.

Isso é trabalho de configuração e de prova, não de opinião tributária. A decisão sobre como tratar cada operação do ponto de vista fiscal continua sendo do cliente e do time jurídico-tributário. O papel de quem desenha e configura o sistema é garantir que a decisão tomada esteja refletida no comportamento do SAP e do motor fiscal, e que isso esteja provado antes de a competência fechar, não descoberto depois.

Quem assina a prova do primeiro fechamento

A pergunta que normalmente não aparece em nenhuma ata de projeto é simples de fazer e difícil de responder sob pressão: qual é o plano de fechamento fiscal da primeira competência depois do go-live, e quem assina essa prova. Em muitos projetos, a resposta é "o time fiscal vai acompanhar de perto", o que não é plano, é expectativa. Plano tem checklist, data de simulação prévia, critério objetivo de aceite fiscal separado do critério de aceite de loja e logística.

Quando esse plano não existe, a pessoa exposta não é quem aprovou o cronograma de TI. É quem assina o fechamento fiscal do mês, geralmente o diretor ou gerente fiscal, que herda um sistema testado pelos critérios de outra área e precisa provar, sozinho, que ele também funciona para o que realmente importa na apuração. A diferença entre o critério que aprovou o go-live e o critério que fecha o mês é exatamente o espaço onde mora o risco fiscal não mapeado de uma implantação recente.

Em redes que atravessam essa janela sem plano próprio, o padrão observável vira perceptível já no segundo ou terceiro mês fechado: a equipe sênior passa a gastar mais horas corrigindo rodadas sucessivas de SPED do que planejando a operação de 2027, e esse desequilíbrio raramente é medido até alguém perguntar por que o fechamento de um sistema novo ainda não estabilizou.

Na DFSpro, projetamos, configuramos e provamos o comportamento fiscal do sistema antes de ele carregar uma competência real. Em operações de varejo com SAP novo cruzando com mudanças regulatórias de prazo público, como o Ajuste SINIEF 23/26 e a NT 2026.007, o Diagnóstico Fiscal Estruturado mapeia o que ainda não foi testado sob critério fiscal, antes do fechamento virar o teste de aceitação que ninguém agendou. Depois do primeiro ciclo, o AMS Fiscal sustenta o que foi provado, sem prometer resultado tributário que não é decisão nossa a tomar.