DeRE pede revisão do XSD do PGCC antes de mudar a integração

Por Patrícia Bastos
11 de novembro de 2026

A Receita Federal e o Comitê Gestor do IBS (CGIBS) programaram para as 7h desta quarta-feira, 11 de novembro, uma atualização da Produção Beta da Declaração de Regimes Específicos (DeRE). A orientação noticiada é atualizar o XSD do evento PGCC, o Plano Geral de Contas Comentado. Para quem mantém a integração, o ponto crítico é confirmar qual esquema está disponível e qual versão o sistema realmente utiliza.

A orientação sobre o PGCC informa que a implantação foi planejada sem interrupção dos serviços. Isso não equivale a confirmar sua conclusão. Também não significa que arquivos preparados antes da mudança continuarão compatíveis com o esquema esperado pelo ambiente.

O impacto imediato é técnico: revisar a geração do XML, a validação local e o tratamento dos retornos. O aviso descrito na notícia não anuncia mudança no prazo de entrega. Tampouco permite tratar uma atualização do Beta como nova exigência já vigente em produção.

O que está anunciado e o que ainda precisa de confirmação

O comunicado da Receita Federal sobre a atualização do ambiente Beta foi identificado com publicação em 10 de novembro. Sua identificação delimita o assunto ao ambiente de testes. Os detalhes de horário, continuidade do serviço e atualização do PGCC são relatados pela notícia que repercute o aviso.

Há uma lacuna importante para a implantação: a notícia informa que o comunicado não identifica o número da versão do XSD nem discrimina os campos modificados. Portanto, não há base para publicar uma lista de alterações específicas ou indicar uma versão numérica como aplicável.

O cruzamento das referências permite separar o anúncio de atualização da decisão de implantar. Para fechar essa decisão, a equipe precisa conferir a íntegra do comunicado e os artefatos oficiais da DeRE. Uma data programada não substitui a confirmação de disponibilização; o nome do arquivo, isoladamente, também não comprova seu conteúdo.

Identifique o pacote antes de substituir o XSD

XSD é o esquema que descreve a estrutura admitida para um XML. Ele pode definir elementos, tipos de dados, ordem dos campos e quantidade de ocorrências. Se o emissor usa um esquema antigo, sua validação interna pode aprovar um arquivo que não atende ao esquema utilizado pelo destinatário.

A primeira providência recomendada é registrar a situação atual: pacote instalado, origem do download, data de obtenção e componente que o utiliza. Depois, compare essas informações com o pacote oficial destinado ao ambiente e ao evento em questão. Quando houver identificador de versão, registre-o; não crie uma versão interna como se fosse oficial.

Verifique também arquivos importados ou incluídos pelo esquema principal. Substituir apenas o XSD mais visível pode deixar dependências antigas no validador. Esse cuidado faz parte do trabalho de adaptar a integração quando muda o leiaute do SPED: a atualização precisa alcançar o conjunto efetivamente carregado pelo sistema.

Se a solução for terceirizada, peça evidência da versão instalada e do pacote utilizado nos testes. A declaração genérica de que o produto está atualizado não demonstra, sozinha, qual esquema validou o XML do PGCC.

Compare campos e validações sem presumir mudanças

Sem o pacote técnico, não é possível afirmar que determinado campo passou a ser obrigatório, mudou de tamanho ou ganhou novos códigos. O caminho seguro é comparar o esquema anterior com o disponibilizado oficialmente e confrontar as diferenças com os leiautes e as regras de validação correspondentes.

A comparação deve procurar, como roteiro de análise — e não como lista de mudanças já confirmadas:

• Inclusão, exclusão ou renomeação de elementos e atributos.
• Alterações de obrigatoriedade, sequência e quantidade de ocorrências.
• Mudanças de tipo, tamanho, precisão, padrão de preenchimento ou valores permitidos.
• Modificações em namespaces e dependências entre esquemas.

O resultado precisa ligar cada diferença ao componente afetado: cadastro de origem, mapeamento, geração do XML ou validador. Um campo novo, por exemplo, pode exigir dado que o integrador ainda não recebe do ERP. Já uma restrição de formato pode demandar ajuste na transformação, sem alterar o cadastro.

Também é essencial distinguir validação estrutural de regra de negócio. Passar no XSD não comprova que as informações estejam corretas ou que o evento será aceito. Na DeRE, vale preservar a separação entre tabelas, eventos mensais e controles de fechamento, sem transformar a revisão do PGCC em conclusão sobre toda a declaração.

Os testes recomendados e as evidências a guardar

O plano de testes deve decorrer das diferenças efetivamente identificadas. As verificações abaixo são recomendações de controle de implantação. Não representam novas obrigações fiscais anunciadas pela Receita ou pelo CGIBS.

Comece pela validação local de arquivos representativos com o pacote atualizado. Quando houver alteração confirmada, acrescente casos que exercitem seus limites: ausência de elemento obrigatório, formato inválido ou quantidade de ocorrências fora da regra. O objetivo é comprovar tanto a aceitação do arquivo correto quanto a detecção do erro previsto.

Depois, execute o fluxo no Beta, respeitando a documentação aplicável. Separe falha de comunicação, rejeição estrutural e rejeição por regra de negócio. Essa classificação evita corrigir o cadastro quando o problema está no esquema ou alterar o XML quando a falha é de transporte.

Para cada cenário, convém guardar:

• Identificação do pacote XSD e da versão do sistema testado.
• Ambiente, data, cenário e resultado esperado.
• XML utilizado, retorno recebido e resultado observado.
• Defeito encontrado, correção aplicada e evidência do novo teste.

Envio não encerra a conferência do processamento

A notícia recomenda acompanhar o resultado do evento e preservar XML e mensagem do sistema. O protocolo de envio, isoladamente, não comprova processamento bem-sucedido. O integrador precisa interpretar o retorno e tornar o resultado visível para a equipe fiscal.

A distinção é semelhante àquela já discutida sobre envio e autorização de uso na NF-e, embora os fluxos não sejam intercambiáveis. O princípio de controle é o mesmo: comprovar que uma mensagem saiu não basta para concluir que o destinatário a aceitou.

Os números do IMTT — Índice de Maturidade Tecnológica em Tax, da Confeb, de 2026, ajudam a contextualizar o desafio. Entre os profissionais das empresas respondentes, 49% apontaram integrações entre sistemas como complexidade na adaptação à reforma tributária, e 53% citaram estrutura e qualidade dos dados. Esses resultados reforçam a utilidade de testar o percurso completo da informação, não apenas o arquivo final.

Libere a mudança com responsáveis e pendências explícitas

Na prática, Tax deve validar o significado e a origem das informações; TI, a geração, a validação e os retornos; e o fornecedor, quando houver, a atualização entregue. A aprovação interna deve identificar o que foi testado e o que permanece pendente.

Antes de liberar a atualização, confirme três pontos: pacote aplicável identificado, diferenças avaliadas e resultados documentados no ambiente correto. Se faltar documentação oficial ou houver divergência entre esquema e retorno, registre a pendência e encaminhe a dúvida pelo canal de suporte indicado na documentação.

O critério de conclusão não é ter trocado um arquivo na aplicação. É demonstrar que o sistema utiliza o pacote correto, gera o PGCC compatível e interpreta o processamento no Beta. Qualquer aplicação em produção depende de confirmação própria, sem converter o cronograma de testes em prazo tributário.

Este conteúdo foi produzido com apoio de inteligência artificial e revisado pela equipe editorial da Live University.