O eSocial foi detestado, ovacionado, temido, julgado, criticado, elogiado e muito mais. Várias pessoas que operam os sistemas de folha de pagamentos (ou outras designações para sistemas de pagadoria de pessoal) têm reclamado da complexidade do sistema.

Já escrevi nesta coluna, e disse em tantas palestras pelo Brasil afora, que a complexidade não tem origem no sistema. A origem está na legislação de regulação sobre as relações de trabalho. Não me cabe entrar no mérito das proteções aos trabalhadores, tampouco aos riscos trabalhistas dos empregadores. Não se trata disso.

Como é sabido pelos operadores e operadoras dos sistemas de pagamentos do trabalho, temos regulações legais no âmbito tributário-previdenciário que dificultam a prestação de informações unificadas.

No âmbito previdenciário, o regime temporal é exclusivamente pelo regime de competência na incidência da contribuição individual e patronal. Já o Imposto de Renda trata o tema exclusivamente pelo regime de caixa.

Isso traz à tona uma discussão ultrapassada quanto a unificação dos regimes nos dois tributos. Ultrapassada porque não há mais argumentos a apresentar ao legislativo e ao executivo não foram sensíveis ao tema. O chamado "Custo Brasil" embute o duplo processamento e controle das informações de pagamentos de funcionários e contratados.

No eSocial, teremos o seguinte modelo de partilha de informações com os fiscos:
*  três eventos que serão administrados conforme a necessidade. O primeiro que é o demonstrativo de pagamentos ou contracheque, ou ainda o holerite (para quem é do tempo dos mainframes) chamado de S-1200. Nele estará descrito os proventos e descontos que compõe as bases de cálculo e valores a pagar. Como o próprio nome refere demonstra o valor a pagar - no futuro.
* O segundo evento será o S-1210 que se refere ao pagamento do evento anterior, ou seja, um evento S-1200 ou S-2299 ou S-2399 ou S-1202 ou S-1207. Como trata-se de pagamento entende-se o regime distinto da origem que seguiu o regime de competência. Por exemplo, o pagamento da remuneração de janeiro em fevereiro.
* Para a vinculação entre o demonstrativo da remuneração e seu pagamento há no evento S-1210 informações como o grupo de informações classificadas como infoPgto. Uma remuneração que tenha sido parcelada poderia gerar a partir de um evento S-1200 vários eventos S-1210.
Ocorre que, para efeitos de apuração de valores de retenção do Imposto de Renda na fonte, outras informações são necessárias, como dependentes específicos para IRPF, pensão de alimentos, contribuição previdenciária e outras que atualmente estão descritas na DIRF.

O que fez a Receita Federal do Brasil? Criou o terceiro evento (da série) para recepcionar estas informações, obviamente em granulosidade superior a DIRF. Este evento recebeu o código S-1220. A justificativa é que o conjunto de eventos é necessário para não o tornar ainda mais complexo o cumprimento da obrigação, pois o regime temporal os impede do cumprimento único.

Nos cursos que tenho ministrado e nas consultorias que faço percebo que ao entender esta situação a primeira parte do problema se resolve: a revolta pela insatisfação de mudança nos processos e sistema impactados caia praticamente a zero. Aqui utilizei o exemplo de folha de pagamentos de funcionários, mas a complexidade se estende aos contribuintes individuais contratados pela fonte pagadora e outras situações que terão reflexos na EFD-REINF (meu próximo artigo aqui).

Se você gostou deste tema e quer saber mais, me acompanhe aqui, no Portal Contábeis, e nas redes sociais. Procure por @mauronegruni e compartilhe este conteúdo para ajudar outras pessoas.
Fonte: Contábeis