E-Financeira 2026: mudanças dos Manuais 2.1 e 2.1.1 e impactos na operação

O que mudou na e-Financeira 2026?

A adequação não se limita a acrescentar colunas no CSV. Ela alcança dados cadastrais, regras de produto, abertura de conta, pagamentos internacionais, correções pontuais e consistência do XML transmitido ao SPED.

Quais campos foram incluídos para o CRS 3.0?

O Declarado_YYYYMMDD.csv recebeu tpPartSocietaria, motivoNoTINReasonB, inDeclaracaoPropriaCRS, DataNasc e o grupo InfoNascimento: Município, Bairro, País e AntigoNomePais.

A REGRA_VALIDA_TP_PART_SOCIETARIA_CONTA determina que, quando tpPartSocietaria estiver preenchido, as contas associadas sejam do tipo 3 - Investimento.

O que mudou em OperacoesFinanceiras?

O arquivo passou a contemplar dtAberturaConta, formaAberturaConta, celularAberturaConta e MACAddressAberturaConta. A REGRA_OBRIGATORIO_CELULAR_MACADDRESS prevê corte em 01/01/2027 para determinadas contas de depósito abertas virtualmente.

Também foram incluídos tpPgto e totPgtosAcum. Eles identificam o tipo de pagamento FATCA/CRS e o total acumulado no ano-calendário. Mais de um tipo de pagamento na mesma conta exige registros separados.

Como funcionam as validações cruzadas?

tpConta, subTpConta, tpNumConta, tpPgto e tpPartSocietaria precisam ser coerentes. Entre as regras estão REGRA_VALIDA_TP_NUM_CONTA_DIN_ELETRONICO, REGRA_VALIDA_IBAN_TP_CONTA e REGRA_VALIDA_TP_NUM_CONTA_SEGURO.

Por que o evtCadDeclarante é crítico?

O evento deve refletir Modalidade declarante CRS, Declarante FATCA e Tipo de entidade financeira. Sem a retificação, transmissões posteriores podem ser bloqueadas pela Receita Federal.

O tipo de entidade é multivalorado: Depository Institution, Custodial Institution, Investment Entity e Specified Insurance Company podem coexistir. Consórcios devem ser enquadrados conforme a conta declarada.

O que é ExclusaoPontual_YYYYMMDD.csv?

O arquivo permite excluir individualmente um evento enviado indevidamente, usando nrReciboEvento, CNPJ da entidade e tipo de exclusão. Isso evita retificar um lote inteiro em correções pontuais.

Como preparar a operação?

· atualizar onboarding e evtCadDeclarante;

· completar dados CRS, FATCA, nascimento e abertura de conta;

· revisar classificações e parametrizações;

· adequar os três arquivos de entrada;

· homologar validações antes da produção;

· preservar recibos e trilha de correção.

Como o e-commply apoia a adequação?

O e-commply consolida dados, executa validações e gera reportes. Aliado à experiência de mais de 30 anos da ecomm|it, apoia onboarding, homologação e acompanhamento da obrigação.

Por que a atualização exige revisão de dados?

Os novos campos ampliam o nível de detalhe esperado e criam relações entre cadastro, conta, produto e pagamento. Se a informação não é coletada no onboarding ou não está disponível na origem, acrescentar a coluna ao arquivo não resolve a obrigação. A instituição precisa mapear disponibilidade, formato, qualidade, responsável e regra de atualização de cada dado.

Essa revisão deve considerar dados históricos e novos cadastros. Corrigir apenas o fluxo futuro pode deixar lacunas em contas já existentes que continuarão sendo reportadas. A análise de impacto precisa definir quando será necessária complementação, retificação cadastral ou tratamento de exceção.

CRS, FATCA e coerência cadastral

Campos relacionados ao CRS e ao FATCA não podem ser avaliados isoladamente. A classificação da entidade, a participação societária, a residência fiscal e o tipo de conta precisam formar um conjunto coerente. Validações cruzadas foram desenhadas justamente para identificar combinações incompatíveis ou incompletas.

Termos técnicos e domínios devem seguir o manual aplicável. Traduções livres ou abreviações internas não substituem os valores esperados pelo layout. Uma matriz de regras ajuda a relacionar campo, condição, origem, domínio, validação e área responsável, tornando a implementação verificável.

Impactos no onboarding

O onboarding é um ponto crítico porque parte dos novos dados nasce na abertura ou na atualização do relacionamento. Formulários, APIs, telas, documentos e procedimentos podem precisar de revisão. A mudança deve preservar experiência do cliente sem comprometer completude e evidência.

Quando o dado depende de declaração do cliente, a instituição precisa definir validação, periodicidade de atualização e tratamento para respostas ausentes ou inconsistentes. Também deve ser possível demonstrar qual informação foi recebida, quando foi alterada e como alimentou o reporte.

Como testar os arquivos de entrada?

Os testes devem começar pela estrutura e avançar para regras de negócio. É importante usar cenários com campos preenchidos, ausentes, inválidos e combinados de maneiras incompatíveis. Casos negativos confirmam se as validações realmente impedem um arquivo inadequado de seguir para transmissão.

Totais e amostras podem ser reconciliados com os sistemas de origem. Além de aceitar o arquivo, a homologação precisa demonstrar que o conteúdo representa corretamente contas e eventos. Resultados, correções e novas execuções devem ser documentados para formar evidência.

O papel do evtCadDeclarante

O evtCadDeclarante funciona como referência para características da entidade declarante. Por isso, sua atualização não deve ser tratada como detalhe administrativo. Modalidade CRS, condição FATCA e tipo de entidade financeira precisam refletir o enquadramento real da instituição e estar coerentes com os eventos posteriores.

Antes de transmitir novos movimentos, é recomendável confirmar o status do evento, recibo e eventuais rejeições. Uma inconsistência nessa etapa pode bloquear o fluxo seguinte, mesmo que os arquivos estejam tecnicamente corretos. Responsabilidade e prazo para a retificação devem constar no plano de implantação.

Exclusão pontual e governança de correções

A possibilidade de excluir um evento específico melhora a precisão das correções, mas exige controle. O nrReciboEvento precisa estar correto, e a instituição deve preservar o motivo, a aprovação e a relação com o envio original. A funcionalidade não elimina a necessidade de investigar por que o evento indevido foi produzido.

Correções recorrentes indicam fragilidade na origem, parametrização ou validação. Um processo maduro mede causas, atualiza regras e reduz reincidência. Dessa forma, a exclusão pontual atende à necessidade imediata sem se tornar substituta de controles preventivos.

Plano de implantação e monitoramento

O plano deve reunir inventário de campos, lacunas de dados, ajustes de sistema, atualização do onboarding, configuração do evtCadDeclarante, adequação dos arquivos, testes e preparação da produção. Cada entrega precisa de responsável, prazo, critério de aceite e evidência.

Após a entrada em produção, convém monitorar rejeições, campos incompletos, correções, tempo de resolução e divergências com a origem. O e-commply, combinado à experiência dos especialistas da ecomm|it, apoia consolidação, validação, geração e acompanhamento, conectando obrigação regulatória à realidade operacional.

Governança entre áreas

A e-Financeira reúne temas cadastrais, tributários, tecnológicos e operacionais. Compliance ou fiscal pode coordenar a obrigação, mas dados são produzidos por outras áreas. Uma matriz deve indicar quem define a regra, quem mantém a origem, quem valida e quem aprova. Essa clareza evita que uma inconsistência circule sem responsável.

Mudanças de produto e onboarding também precisam passar por avaliação de impacto regulatório. Se um novo fluxo altera a forma de abertura, a classificação da conta ou os pagamentos, os campos e validações da e-Financeira devem ser considerados antes da implantação, e não somente durante a geração periódica.

Checklist antes da transmissão

Confirme a atualização do evtCadDeclarante, a versão dos manuais, os domínios aplicáveis e a completude dos arquivos. Execute validações cruzadas, reconcilie totais com a origem e revise ocorrências. Verifique acesso ao SPED, responsáveis e procedimento de contingência. Por fim, preserve arquivo aprovado, protocolo, recibo e evidências das verificações.

Depois da transmissão, trate rejeições e retificações com causa e trilha. O primeiro ciclo deve alimentar melhorias no onboarding, nas integrações e nas regras. Assim, a e-Financeira 2026 deixa de ser apenas um arquivo periódico e passa a orientar uma governança de dados mais consistente.

Erros frequentes na adequação

Tratar os novos campos como simples alteração técnica é um dos principais erros. Sem revisão da origem, o arquivo pode conter valores padrão, incompletos ou incoerentes. Também é inadequado validar apenas a estrutura, ignorando relações entre classificação, conta e pagamento. A aceitação técnica não substitui a qualidade do conteúdo declarado.

Outro risco é atualizar o onboarding sem planejar a base existente. Clientes antigos podem continuar com lacunas e exigir uma estratégia específica de complementação. A instituição deve dimensionar volume, prioridade, comunicação e evidência, evitando que o problema apareça somente no ciclo de reporte.

Como sustentar a qualidade dos dados

Regras preventivas na captura reduzem correções posteriores. Campos condicionais devem aparecer no momento adequado, domínios precisam ser controlados e combinações incompatíveis devem gerar alerta. Quando uma exceção for aceita, a justificativa e a aprovação devem ficar registradas.

Indicadores podem acompanhar completude, inconsistências por campo, rejeições, retificações e tempo de resolução. A análise por produto ou canal ajuda a localizar a origem. Com governança contínua, a adequação produz um benefício adicional: dados cadastrais e operacionais mais confiáveis para outras decisões da instituição.