O SPED foi desenhado para cruzar dados sem parar. A governança fiscal que o alimenta tem data de fim

Todo projeto de governança fiscal tem data de início e data de fim: escopo definido, cronograma, relatório final. O sistema que vai auditar o resultado desse projeto depois, o SPED, não foi desenhado com data de fim nenhuma. Ele foi desenhado, por objetivo declarado da própria Receita Federal, para cruzar dados de forma contínua e permanente. Essa assimetria, entre um esforço que termina e uma fiscalização que nunca para, é onde a maior parte do risco de exposição fiscal se acumula sem que ninguém tenha decidido isso de propósito.

O que a Receita Federal declara como objetivo do SPED

A própria página oficial do SPED (Sistema Público de Escrituração Digital, sped.rfb.gov.br, http://sped.rfb.gov.br/item/show/967) lista três objetivos, entre outros. A primeira é "promover a integração dos fiscos, mediante a padronização e compartilhamento das informações contábeis e fiscais". A segunda é "racionalizar e uniformizar as obrigações acessórias para os contribuintes, com o estabelecimento de transmissão única de distintas obrigações acessórias de diferentes órgãos fiscalizadores". A terceira, a mais direta para quem pensa em risco, é "tornar mais célere a identificação de ilícitos tributários, com a melhoria do controle dos processos, a rapidez no acesso às informações e a fiscalização mais efetiva das operações com o cruzamento de dados e auditoria eletrônica".

Nenhuma dessas três frases descreve um evento único. Integração de fiscos, transmissão de obrigação acessória e cruzamento de dados para auditoria eletrônica são, pela própria redação do objetivo, atividades permanentes do sistema, não uma entrega que se conclui e arquiva. O SPED não foi concebido para verificar uma empresa uma vez; foi concebido para que a verificação continue acontecendo, módulo após módulo, período após período, enquanto a empresa existir.

Este blog já defendeu, no post "Governança Fiscal Não É Projeto. É Rotina. E Quase Ninguém Faz Certo", que tratar governança fiscal como projeto fechado é um erro observado na prática, em diagnóstico com CFOs. O que este artigo acrescenta não é a tese, é a âncora oficial: o SPED, pela finalidade que a própria Receita Federal declara para ele, não foi desenhado para conviver com um esforço que termina. Deixa de ser boa prática recomendada e passa a ser incompatibilidade estrutural, verificável por qualquer leitor na fonte primária.

O SPED não pergunta se a governança fiscal de uma empresa "já foi resolvida". Ele continua cruzando dados independente da resposta.

A lógica de projeto que a empresa aplica do outro lado

Quando uma empresa contrata uma iniciativa para "colocar a governança fiscal em dia", o formato mais comum é o de projeto: escopo fechado, cronograma definido, entrega marcada. Isso funciona bem para corrigir um problema específico já identificado, mas trata como evento pontual algo que precisa de continuidade: detecção de risco, revisão de regra fiscal e monitoramento de divergência não têm início e fim natural, porque o sistema do outro lado (o Fisco, via SPED) também não tem. O projeto termina, o relatório final é entregue, e a pergunta que raramente é respondida por escrito é: quem, com que orçamento e com que cadência, mantém essa detecção funcionando depois que o projeto formal se encerrou?

Essa pergunta importa porque o SPED, pelos seus próprios objetivos declarados, não vai parar de cruzar dado contra dado só porque o projeto interno da empresa encerrou. Uma parametrização fiscal no SAP que ficou correta no dia da entrega do projeto pode divergir do que a legislação exige seis meses depois, seja por mudança de regra, seja por uma nova operação que o desenho original não previu. O sistema que audita isso continua rodando; o sistema que corrige isso, dentro da empresa, pode ter sido desligado junto com o projeto.

Por que "transmissão única" também é um argumento contra o formato de projeto fechado

O segundo objetivo declarado do SPED, a transmissão única de diferentes obrigações acessórias para diferentes órgãos fiscalizadores, tem uma implicação direta para arquitetura de sistema fiscal. Se um único evento de escrituração alimenta mais de um órgão fiscalizador ao mesmo tempo, um erro de parametrização não gera uma exposição isolada; ele se propaga, na mesma transmissão, para todas as obrigações acessórias que dependem daquele mesmo dado. Isso eleva o custo de um erro não corrigido: não é um formulário errado, é uma base de dado compartilhada entre fiscos, alimentada de forma recorrente.

Um projeto de governança fiscal que termina sem deixar um responsável fixo e uma cadência de revisão definida está, na prática, apostando que a parametrização corrigida no dia da entrega vai continuar correta indefinidamente, num sistema que foi desenhado, pela própria Receita Federal, para verificar essa mesma informação de forma contínua. A aposta pode até se sustentar por um tempo. O ponto de falha aparece quando a legislação muda, uma nova operação surge, ou um novo item de catálogo entra em produção sem passar pela mesma revisão que o projeto original fez.

O que muda quando a governança vira capacidade, não entrega

Tratar governança fiscal como capacidade permanente, em vez de projeto com data de fim, muda três coisas concretas na forma como ela é orçada e estruturada. A primeira é o orçamento: uma capacidade permanente tem uma linha de custo recorrente, não uma verba única aprovada uma vez. A segunda é a responsabilidade: existe um nome, dentro da empresa, dono da revisão periódica de regra fiscal, não um fornecedor externo cujo contrato termina junto com o projeto. A terceira é a cadência: revisão de parametrização fiscal vinculada a um calendário formal (mudança de legislação, fechamento de período, entrada de novo item de catálogo), em vez de depender de alguém perceber, por acaso, que algo divergiu.

Nenhuma dessas três mudanças exige reabrir um projeto de implementação nem renegociar contrato de licenciamento. Exige decidir, explicitamente, que a detecção de divergência entre a parametrização do SAP e a exigência legal vigente é uma rotina orçada e nomeada, do mesmo jeito que o próprio SPED trata a integração dos fiscos: como algo permanente, não como um marco a ser riscado de uma lista.

Essa distinção também redesenha como o próprio time é composto. Um projeto de implementação costuma reunir especialistas por um período fixo, dimensionado para o escopo daquele momento. Uma capacidade permanente exige o oposto: um núcleo pequeno e contínuo, com conhecimento tanto da regra fiscal vigente quanto da configuração real do SAP em produção, revisando o mapa de parametrização com a mesma regularidade com que a legislação e o catálogo de itens da empresa mudam, não com a regularidade de um cronograma de projeto que foi fechado antes de qualquer uma dessas mudanças acontecer.

Onde essa lacuna aparece dentro do motor fiscal do SAP

Dentro de um sistema SAP, a parametrização fiscal (tax code, regra de tributação por CFOP e NCM, condição de cálculo) é o ponto onde a exigência legal vira comportamento executável. Um projeto de implementação ou de correção fiscal revisa essa parametrização até um ponto no calendário, com base na legislação e no catálogo de itens vigentes naquele momento. A partir do dia seguinte ao encerramento formal do projeto, qualquer mudança de legislação, qualquer item novo de catálogo, qualquer operação nova que a empresa passa a realizar, entra num sistema cuja parametrização parou de ser revisada com a mesma disciplina que o projeto aplicou.

O sistema não avisa quando isso acontece. Ele continua processando, gerando nota fiscal, fechando período, exatamente como fazia antes. A divergência entre o que a parametrização calcula e o que a legislação vigente exige não aparece como erro técnico visível; aparece quando alguém, de fora, cruza o dado declarado contra a regra vigente, que é exatamente o papel que o SPED, pelo seu próprio objetivo declarado, foi desenhado para cumprir de forma contínua. Um projeto fechado revisa a parametrização uma vez; o sistema que audita essa parametrização revisa continuamente, e a diferença de ritmo entre os dois é onde o risco se acumula.

Governança contínua também é rastreabilidade de decisão, não só correção de regra

Manter a parametrização fiscal atualizada é metade do problema. A outra metade, mais próxima do que o cluster de compliance, auditoria e evidência trata, é conseguir demonstrar, depois, com que critério cada decisão de parametrização foi tomada. Um sistema de auditoria eletrônica contínua, como o próprio SPED, não pergunta apenas se o valor declarado está certo; ele permite ao fiscalizador comparar declarações ao longo do tempo, o que expõe qualquer mudança de critério que não tenha sido documentada no momento em que aconteceu.

Isso desloca a exigência de evidência para antes do questionamento, não depois. Não basta a parametrização estar correta hoje; é preciso conseguir mostrar, com data e responsável, quando ela foi revisada pela última vez e por qual motivo, exatamente o tipo de registro que uma rotina permanente de governança produz e que um projeto fechado, por definição, para de produzir assim que a entrega é assinada. A decisão sobre qual regra tributária aplicar continua sendo do cliente; o que uma governança contínua entrega é a evidência documentada de que essa decisão foi tomada com base na regra vigente, e não presumida a partir de uma configuração antiga que nunca mais foi revisitada.

A pergunta que sustenta a resposta, se a governança for questionada

Para o Compliance ou o Diretor Fiscal que precisar demonstrar, numa fiscalização ou numa auditoria interna, que a governança fiscal da empresa é robusta, a pergunta central é simples de formular e difícil de responder de improviso: existe, hoje, um responsável nomeado e uma cadência formal para revisar a parametrização fiscal do SAP contra mudança de legislação, e essa revisão está documentada, ou a última verificação real aconteceu dentro de um projeto que já foi encerrado? A resposta a essa pergunta é, na prática, a diferença entre uma governança que continua funcionando enquanto o SPED continua cruzando dado, e uma governança que parou no dia em que o projeto foi dado como concluído.

Vale registrar o que essa mudança não exige: não é necessário um projeto novo, nem um orçamento maior do que o já destinado à conformidade fiscal hoje. É possível, a partir do próximo fechamento de período, nomear formalmente quem revisa a parametrização, definir a cadência dessa revisão e registrar por escrito cada verificação feita, ainda que o volume inicial seja pequeno. Esse primeiro registro já estabelece a diferença entre presumir que a parametrização segue correta porque nada travou, e conseguir demonstrar que ela segue correta porque alguém, com data e nome, confirmou isso.

Se a última verificação real da parametrização fiscal da sua operação aconteceu dentro de um projeto já encerrado, vale medir a distância entre o que está configurado e o que a legislação exige hoje. O Diagnóstico Fiscal Estruturado começa exatamente por essa medição.