Depois de fechar a folha, ainda falta pagar. Fazer transferência uma a uma pelo internet banking funciona para cinco colaboradores, mas se torna inviável quando o quadro cresce: é lento, é repetitivo e basta um erro de digitação numa conta para gerar um pagamento errado que só aparece depois. O jeito padrão do mercado para resolver isso é gerar um arquivo de remessa CNAB e subir esse arquivo de uma vez só no banco, um upload cobrindo todos os créditos da competência. O detalhe que passa despercebido até alguém tropeçar nele é que "CNAB" não é um formato único e intercambiável entre bancos.
O que é o CNAB 240
CNAB é o padrão definido pela FEBRABAN para troca de arquivos entre empresa e banco. O CNAB 240 organiza cada registro em 240 posições fixas e cobre pagamentos em geral: salários, fornecedores, tributos, PIX. Um arquivo CNAB 240 típico tem um header de arquivo, um ou mais lotes de pagamento organizados por tipo, os registros individuais de cada favorecido dentro daquele lote e um trailer que fecha o arquivo com os totais.
O problema prático aparece na implementação: cada banco lê esse layout com particularidades próprias. Códigos de segmento diferentes, tratamento distinto para PIX, campos obrigatórios que variam de instituição para instituição, e até a forma de indicar a conta destino muda de um banco para outro. Um arquivo que o Itaú aceita sem reclamar pode ser rejeitado de cara pelo Bradesco, mesmo que os dois sigam, em teoria, o mesmo padrão FEBRABAN. É por isso que um sistema de folha que se preocupa com esse detalhe mantém um layout homologado banco por banco, em vez de tentar gerar um "CNAB genérico" que teoricamente serviria para todos e na prática falha em vários.
Bancos homologados no ActaOne
O ActaOne gera o CNAB 240 já no layout homologado de nove instituições: Itaú, Bradesco, Caixa, Banco do Brasil, Santander, Inter, Sicredi, Sicoob e Banestes, com suporte a PIX como forma de crédito em todos eles. Para bancos que ficam fora dessa lista, existe um fallback que gera o arquivo no layout FEBRABAN padrão, cobrindo o caso geral quando não há homologação específica disponível.
Como funciona a triagem por favorecido
A sub-aba CNAB, dentro do fechamento, não é um botão único de "gerar tudo" que processa a competência inteira de uma tacada. É uma triagem, item por item. Um favorecido, nesse contexto, pode ser o líquido de um colaborador ou uma pensão alimentícia associada a ele, que aparece aninhada dentro do próprio card do titular da pensão. Para cada favorecido da lista, o operador toma três decisões em sequência.
- Escolhe se aquele favorecido entra ou não no arquivo desta competência específica.
- Marca o item como "pronto", sinalizando que a conferência daquela linha já foi feita.
- Define a conta bancária pagadora, que pode ser aplicada de forma global a todos os favorecidos de uma vez ou individualmente, linha por linha. Por padrão, a conta já vem sugerida a partir do que está cadastrado no colaborador, mas pode ser ajustada antes de gerar o arquivo.
Depois que a triagem termina, o sistema gera um arquivo .rem para cada conta pagadora que estiver efetivamente em uso naquela competência, e não um arquivo único misturando contas diferentes. A data de pagamento gravada dentro do arquivo é a mesma que já foi definida na sub-aba Lançamentos da Folha, aquela que também alimenta o S-1210 do eSocial, então não existe uma segunda data para configurar separadamente aqui.
O que acontece depois do congelamento
Depois que o arquivo é gerado pela primeira vez, a triagem daquela competência congela: não é mais possível trocar a conta pagadora de um favorecido, nem mover alguém de dentro para fora do arquivo. A única ação disponível a partir desse ponto é "Gerar de novo", que reproduz exatamente o mesmo conteúdo já congelado; cada vez que isso é feito, um contador de gerações é incrementado, mas o conteúdo em si não muda. Esse congelamento é irreversível e não existe um botão de "reabrir" escondido em algum lugar. A lógica por trás dessa rigidez é proteger um princípio simples: o arquivo que efetivamente foi enviado ao banco e o registro que o sistema guarda daquela remessa precisam ser sempre idênticos, sem margem para alguém alterar a triagem depois que o pagamento já pode ter sido processado.
O que o CNAB não faz
Vale ser explícito sobre os limites dessa funcionalidade, porque é comum alguém assumir mais do que ela entrega.
- Não é conexão com o banco. O ActaOne não acessa a conta da empresa nem movimenta dinheiro diretamente. Ele apenas gera o arquivo; o upload desse arquivo e a autorização final do pagamento continuam sendo feitos por você, dentro do internet banking da instituição.
- Não substitui a conferência. Antes de subir o arquivo no banco, ainda vale a pena olhar o total do arquivo gerado contra o total que apareceu no fechamento, como uma última checagem antes de autorizar a remessa de verdade.
Como isso se encaixa no fechamento
O CNAB é a última etapa dentro da seção Folha do fechamento, vindo depois das sub-abas Lançamentos e Demonstrativo. Ele reaproveita o líquido que já foi calculado nessas etapas anteriores, a conta pagadora escolhida por favorecido e a data de pagamento definida para a competência inteira. Não existe redigitação em nenhum ponto da cadeia: o arquivo de remessa sai exatamente do mesmo dado que já gerou o holerite e o evento correspondente no eSocial.
O ganho de tempo de pagar em lote só se realiza de fato se o banco aceitar o arquivo de primeira, sem rejeição, e é justamente o layout homologado por banco, e não um "CNAB genérico" que serve mais ou menos para todo mundo, que garante essa aceitação. Comparado a lançar cada crédito manualmente pelo internet banking, um por um, a diferença já fica evidente na primeira competência em que o arquivo sobe sem nenhuma linha rejeitada.