Muitas empresas calculam a folha em um sistema e transmitem o eSocial em outro. Funciona assim: um "transmissor" recebe o arquivo já pronto, assina com certificado digital e envia ao governo. O arranjo não é errado, mas empilha mais uma peça entre o cálculo e o envio, com mais um acesso para gerenciar, mais um contrato para renovar e mais um ponto onde a informação pode se perder na tradução entre os dois sistemas. A transmissão nativa elimina essa peça porque os eventos partem do próprio sistema de folha, sem passar por lugar nenhum no meio do caminho.
O que é o eSocial, em uma frase
O eSocial é o canal único pelo qual o empregador presta contas ao governo sobre a relação de trabalho. Admissão, alterações cadastrais, afastamentos, folha de pagamento, desligamento e o fechamento de cada competência: cada um desses fatos vira um evento, com layout e regras de validação próprios. Os mais frequentes no dia a dia de um departamento de pessoal são o S-2200 (admissão), o S-1200 (remuneração), o S-1210 (pagamento), o S-2299 (desligamento) e o S-1299 (fechamento da competência), mas a lista de eventos possíveis é bem mais longa e cobre praticamente tudo que muda na vida do colaborador.
A configuração, feita uma vez
Antes de qualquer evento sair do sistema, três coisas precisam estar prontas, e isso só acontece uma vez, na implantação.
A primeira é a procuração eletrônica no e-CAC. A empresa outorga uma procuração eletrônica para o CNPJ do ActaOne no portal e-CAC da Receita Federal, especificamente para os serviços do eSocial. É essa procuração que autoriza o sistema a assinar e enviar eventos em nome da empresa, sem que ela precise contratar uma certificadora separada só para essa finalidade. Sem a procuração ativa, não existe transmissão nativa possível: o sistema simplesmente não tem autorização para falar com o governo em nome daquele CNPJ.
A segunda é o cadastro de FPAS e código de terceiros. São os códigos que definem para quais entidades a empresa recolhe contribuição, como INSS, Sistema S e salário-educação. Eles ficam registrados no cadastro da empresa e entram direto no cálculo dos encargos patronais, então um FPAS errado no cadastro gera guia de recolhimento errada lá na frente, mesmo que a folha em si esteja calculada corretamente.
A terceira é o evento de teste. Antes de operar de verdade, o sistema envia um evento de teste ao ambiente do eSocial e confirma que a comunicação está funcionando: certificado válido, procuração ativa, empresa habilitada no ambiente correto. É a checagem que evita descobrir um problema de configuração só quando o primeiro evento real é rejeitado.
O que passa a ser transmitido de dentro
Concluída essa configuração inicial, o dia a dia do eSocial acontece sem sair da plataforma, porque cada rotina de RH já dispara o evento correspondente no momento em que o fato acontece:
- Admissão (S-2200): ao cadastrar o colaborador e disparar o evento, sem precisar montar um arquivo separado para outro sistema.
- Afastamentos (S-2230): férias, atestado, licença, acidente, tudo a partir do próprio registro de ausência que o RH já preenche no dia a dia.
- Alterações cadastrais e contratuais (S-2205, S-2206): mudança de dados pessoais, de cargo, de salário, refletidas no eSocial no mesmo momento em que são registradas no cadastro do colaborador.
- Remuneração e pagamento (S-1200, S-1210): gerados automaticamente a partir do fechamento da folha da competência, com os mesmos valores que aparecem no holerite.
- Fechamento (S-1299): disparado quando todos os eventos daquela competência já foram aceitos pelo governo.
- Desligamento (S-2299): ao registrar a rescisão, junto com as verbas calculadas.
A assinatura digital de cada envio usa o certificado do próprio sistema, amparado pela procuração outorgada no e-CAC. Não existe um segundo software para abrir, nem um arquivo para exportar e depois subir em outro lugar: o mesmo cadastro que gerou o evento é o que assina e transmite.
O que ainda é responsabilidade da empresa
Transmissão nativa não é sinônimo de piloto automático sem nenhuma conferência humana. Três pontos continuam dependendo do time de DP, e é aí que a maioria dos problemas reais acontece.
O primeiro é o cadastro correto. Quando um evento é rejeitado pelo eSocial, quase sempre a causa é um dado faltando ou inconsistente no cadastro do colaborador: CBO informado errado, categoria previdenciária incompatível com o tipo de vínculo, dependente sem data de nascimento, ou um vínculo que já foi encerrado em outro evento e não bate mais com o que está sendo enviado agora. Nenhum sistema, nativo ou não, corrige um cadastro incompleto por conta própria.
O segundo são os pré-requisitos externos. A procuração eletrônica no e-CAC tem validade e precisa ser renovada; se ela vencer sem que ninguém perceba, os envios simplesmente param até a renovação, mesmo que o cálculo da folha continue rodando normalmente por dentro do sistema.
O terceiro é a conferência da competência. O sistema calcula e transmite os valores, mas validar se aqueles valores estão corretos, se o colaborador certo recebeu o adicional certo, se a base de cálculo bateu, continua sendo função do time de DP. Isso importa especialmente porque o encerramento da competência é irreversível: depois de fechada, não há como voltar atrás e corrigir um evento que já foi aceito naquele mês.
O que muda sendo nativo
No ActaOne, o eSocial é nativo de ponta a ponta. O painel do eSocial mostra cada evento da competência com o status correspondente, seja pendente, enviado, aceito ou rejeitado, e o encerramento da competência só é liberado quando não há mais nada pendente naquela lista. Os eventos de admissão, folha, afastamentos, desligamento e fechamento são gerados e transmitidos de dentro do próprio sistema, com assinatura digital e consulta de status ao governo, sem transmissor externo nem certificadora à parte. A autorização para tudo isso vem da mesma procuração eletrônica outorgada no e-CAC durante a implantação.
O ganho real de ter cálculo e transmissão no mesmo sistema não é a velocidade do envio em si, porque o eSocial processa o evento no tempo dele, independentemente de quem envia. O ganho é não precisar reconciliar dois sistemas que, teoricamente, deveriam sempre concordar entre si, mas que na prática divergem quando alguém corrige um valor de um lado e esquece de refletir do outro. É exatamente nesse intervalo entre o sistema que calcula e o sistema que transmite que costuma morar o retrabalho de toda auditoria de eSocial: horas gastas comparando planilha com arquivo XML, tentando entender por que o valor que saiu no holerite não é o mesmo que foi transmitido três dias depois.