O Banco Nunca Esquece de Cobrar Juros — E Agora Você Vai Entender o Porquê

Você já reparou que a multa, os juros ou o IOF só aparecem na fatura se você deixar passar a data de vencimento? Isso é o resultado de um processo diário, cheio de regras contábeis e validações, que roda de forma automática nos bastidores: os accruals.

Eles são o motor que calcula centavo por centavo do que você deve — e que garante que o sistema financeiro funcione com precisão. Para quem está no backend, isso significa lidar com lógica de negócio delicada, fiscalizada de perto pelo Banco Central, e que não pode falhar.

Neste artigo, vamos explorar como os accruals funcionam, o que são os encargos, como tudo isso se transforma em fatura e por que o regulador se importa tanto com esse processo.

O Ponto de Partida

A fatura é aquele documento que todo mundo já conhece: lista de compras, total a pagar, data de vencimento. Mas isso é só a foto final, o retrato do mês fechado. O que ela não mostra é o “making of”: todo o processo diário que decide se, além das compras, ela vai carregar também juros, IOF ou multa.

No meu artigo anterior, “Acha que Entende a Fatura do seu Cartão? Tente Codificar Uma”, conversamos e entendemos a fatura como estrutura — como ela é montada, quais campos existem e qual lógica a organiza. Se esse é o seu ponto de dúvida, recomendo a leitura.

Aqui, porém, o foco é outro. Vamos além da foto final e olhar para o motor invisível que trabalha dia após dia, calculando se haverá encargos ou não. É nesse nível — o dos accruals e do regime de competência — que o banco garante que nunca se esquece de cobrar os juros devidos.

Esqueça o fechamento do mês por um instante. Pense no dia a dia do sistema. A cada transação, a cada dia que o saldo devedor não é quitado, a cada parcela futura, existe um processo de acúmulo – ou accrual, no jargão contábil. Juros são provisionados diariamente, pontos de um programa de fidelidade são acumulados, encargos por um possível atraso já começam a ser calculados em segundo plano. Bora mergulhar nisso!

O Que Raios é um “Accrual”?

Vamos ser honestos: a palavra Accrual soa como algo saído de um livro de contabilidade empoeirado, daqueles que a gente só abre em caso de emergência. Parece complexo, intimidador e, sejamos sinceros, até difícil de pronunciar.

Mas e se eu te dissesse que você já entende perfeitamente o que é um accrual? Você vive isso todo santo mês 😅. A ideia por trás desse nome complicado é, na verdade, simples e intuitiva.

Vamos esquecer os jargões por um segundo.

Pense no seu salário 💴

Imagine que seu salário é de R$ 6.000,00, pago todo dia 5 do mês seguinte. Agora, responda rápido: no dia 15 do mês, você já ganhou algum dinheiro?

Claro que sim! Você trabalhou por 15 dias. Metade do seu salário, ou R$ 3.000,00, já é seu por direito. O dinheiro ainda não caiu na sua conta, você não pode usá-lo para pagar o almoço, mas o fato econômico já aconteceu: você prestou o serviço, e a empresa agora te deve esse valor.

Pronto. Isso é um accrual.

Dois Lados da Mesma Moeda

Essa analogia mostra perfeitamente os dois lados de um accrual:

• Para você (funcionário): cada dia trabalhado gera um accrual de receita. No dia 15, você tem R$ 3.000,00 provisionados. No dia 30, o valor total de R$ 6.000,00. O evento (o seu trabalho) gerou receita, mesmo que o dinheiro só chegue depois.

• Para a empresa (empregadora): a cada dia, ela registra um accrual de despesa. No dia 15, já tem uma obrigação contábil de R$ 3.000,00, mesmo que o caixa só seja afetado no dia 5 do mês seguinte.

Ou seja: accrual é sempre direito de um e obrigação de outro.

O Ponto-Chave: Competência vs. Caixa

Aqui entramos no coração da contabilidade — e, consequentemente, no coração do código dos sistemas financeiros:

• Regime de Caixa: só olha para o extrato. Receita só existe quando o dinheiro entra. Despesa só quando o dinheiro sai.

• Regime de Competência (accrual): registra a verdade do evento econômico. Se aconteceu, gera obrigação ou direito, independentemente do pagamento.

No mundo bancário, vivemos no regime de competência. É ele que mostra a real saúde financeira e garante consistência nos cálculos.

Accruals no Cartão de Crédito

Quando um banco calcula encargos, ele não espera o pagamento para registrar receita.

• Juros de mora: acumulam diariamente após o vencimento.

• Multa por atraso: registrada como obrigação assim que a fatura vence sem pagamento.

• IOF: provisionado desde a origem da operação.

Cada encargo é um accrual. A cada dia em que a dívida existe, o sistema gera uma provisão automática. Silenciosa. Contínua.

E no fim do mês, a fatura nada mais é do que o consolidado de todos esses accruals que rodaram dia após dia.

Accrual é a lógica que garante que, no dia seguinte ao vencimento, já exista valor a ser cobrado. É o “motor invisível” que transforma fatos econômicos em números exatos na fatura.

Quando o Banco Começa a Fazer Accruals?

Se você chegou até aqui, talvez esteja pensando:

“Tá, entendi o que é accrual… mas afinal, o banco começa a provisionar quando? Todos os dias? Só depois do vencimento da fatura?”

A resposta é: depende do tipo de operação e do tipo de encargo. Vamos detalhar:

• Antes do vencimento da fatura

  Enquanto a fatura está em aberto e dentro do prazo, não há accrual de juros de mora ou multa, porque o cliente ainda está adimplente. O que pode haver são accruals de IOF (em operações de crédito ou compras internacionais, por exemplo), porque o imposto incide desde o dia da transação.

• No dia seguinte ao vencimento (se não houve pagamento integral)

  A partir desse momento, o motor de accruals começa a rodar diariamente:

  • Juros de mora: provisionados a cada dia em atraso, até o pagamento.

  • Multa de atraso: provisionada uma única vez no momento em que a fatura vence sem pagamento. Cada novo dia sem liquidação gera um accrual adicional de juros.

• Durante o ciclo, para operações específicas

  No caso de parcelamento de fatura, crédito rotativo ou compras parceladas com juros1, os accruals começam desde a contratação. Ou seja, não é preciso esperar o vencimento: o banco já lança diariamente a receita de juros correspondente à parcela do contrato.

Então resumindo:

• IOF e juros de parcelamento → accruals desde o dia da operação.

• Juros de mora e multa → accruals a partir do vencimento não pago.

Como o banco já provisiona os juros acordados?

Quando você fecha um contrato de crédito (parcelamento de fatura, rotativo ou compra parcelada com juros), o valor total dos encargos futuros já é conhecido no momento da contratação. Exemplo:

• Você parcela uma fatura de R$ 3.000 em 10x de R$ 400.

• Isso significa que, no final do contrato, você vai pagar R$ 4.000 no total.

• Os R$ 1.000 a mais são justamente os juros acordados.

Mas o banco não reconhece os R$ 1.000 de uma vez só.

Seria incorreto tanto do ponto de vista contábil (regime de competência) quanto regulatório (BACEN/IFRS).

O que ele faz?

• Divide esse valor em pequenas parcelas diárias, accruando juros proporcionalmente ao tempo.

• A cada dia, o sistema registra uma fração da receita de juros, alinhada ao prazo do contrato.

Imagine que esse contrato de 10 meses gera R$ 1.000 de juros no total.

• O banco não pode lançar os R$ 1.000 no D+1.

• Ele vai distribuir esse valor ao longo de ~300 dias (a duração média dos 10 meses).

• Assim, todo dia, o motor contábil lança um pedacinho da receita de juros como accrual.

Quando você paga a primeira parcela (R$ 400), o sistema “casa” o pagamento com os accruals já lançados até aquele momento.

Por que isso?

1. Regulatória: O Banco Central e as normas internacionais (IFRS 9, CPC 48) exigem que os bancos sigam o regime de competência. Receita só pode ser reconhecida à medida que o tempo passa e a obrigação do cliente continua.

2. Justiça financeira: se o cliente quitar antecipadamente, os juros futuros não podem ser cobrados. Como o banco só reconhece o que já foi “accruado”, consegue recalcular e devolver/descontar os encargos ainda não apropriados.

3. Controle de risco: provisionar diariamente garante que balanços e relatórios mostrem a posição real de receita e risco do banco.

Tá mas porque um programador deveria estar interessado nisso?

Por Que Isso deve Te Interessar?

Eu sei o que você pode estar pensando. "Ok, a analogia do salário é legal, a conexão com a fatura faz sentido... mas, no fundo, isso não é um detalhe de contabilidade? Por que eu, o programador, preciso me preocupar com isso?"

A resposta é simples: porque o accrual não é uma teoria contábil abstrata. É a regra de negócio que define a lógica do seu código.

Se o sistema financeiro que você constrói é o "cérebro" de um banco ou de uma fintech, a lógica de accruals é uma de suas funções mais vitais. É o que permite ao cérebro entender a passagem do tempo e as suas consequências financeiras.

Ignorar isso é como tentar programar um jogo de corrida onde a velocidade do carro só é atualizada quando ele cruza a linha de chegada. Não faz sentido, certo? A velocidade precisa ser calculada e "acumulada" a cada instante. No mundo financeiro, é a mesma coisa.

Então pense no seguinte se você, como programador, não entende o conceito de provisão diária, qual seria sua primeira inclinação ao receber a tarefa "calcule os juros do rotativo"?2 Provavelmente, você criaria uma função que pega o saldo devedor na data de fechamento, aplica uma taxa e pronto. Mas isso estaria completamente errado.

Por quê? Porque o saldo devedor do cliente mudou durante o mês! Ele pode ter feito um pagamento parcial no dia 10, uma nova compra no dia 15... A base de cálculo dos juros não é estática. O único jeito de calcular isso de forma precisa é através de um accrual diário, que considera o saldo de cada dia.

Sem entender o regime de competência, o programador acaba criando uma lógica reativa, que só responde a eventos de caixa (pagamento, fechamento). O que você precisa fazer é criar uma lógica proativa, que captura a realidade do que está acontecendo financeiramente, dia após dia. Você não está apenas registrando transações, está codificando a dimensão do tempo no dinheiro.

É por isso que bugs em sistemas financeiros muitas vezes não são erros de sintaxe, mas sim erros de conceito. Um cálculo de juros errado pode gerar prejuízos milionários, problemas com o Banco Central e uma crise de confiança com o cliente. E a raiz desse erro, muitas vezes, está na falha em implementar corretamente a lógica de accrual.

Por Que os Bancos São Tão Dependentes dos Accruals?

Agora, vamos ampliar o zoom. Por que essa necessidade é tão visceral para um banco? Por que eles não podem simplesmente olhar o extrato no fim do dia?

A resposta é que, para um banco, o Regime de Caixa é uma ilusão perigosa. A saúde de um banco não é medida pelo dinheiro que entrou no caixa hoje, mas sim pelos direitos que ele acumulou a receber no futuro.

Pense nisso: qual é o principal ativo de um banco? Empréstimos. Financiamentos. Crédito. Ou seja, dinheiro que ele emprestou e que voltará para ele com juros ao longo do tempo.

Os bancos precisam desesperadamente dos accruals por algumas razões críticas e lógicas:

1. Visibilidade e Saúde Financeira: Um banco precisa saber o quanto ele realmente ganhou hoje, não apenas o quanto recebeu. O accrual diário dos juros de toda a sua carteira de crédito mostra o verdadeiro lucro da operação. Esperar o dinheiro cair na conta para saber se o mês foi bom seria como um piloto só olhar o mapa depois de pousar o avião. É tarde demais.

2. Gestão de Risco: O accrual permite ao banco enxergar problemas antes que eles aconteçam. Ao provisionar os juros diariamente, o sistema consegue identificar imediatamente um cliente que não está pagando e o quanto o risco daquela dívida está aumentando. Isso é fundamental para calcular a Provisão para Devedores Duvidosos (PDD), uma reserva obrigatória que todo banco deve ter para cobrir possíveis calotes.

3. É a Lei! (Regulação e Conformidade): Não é uma escolha. O Banco Central do Brasil e todos os órgãos reguladores do mundo exigem que as instituições financeiras operem pelo Regime de Competência. Isso garante transparência, previsibilidade e segurança para todo o sistema financeiro. É uma regra do jogo para evitar que um banco pareça saudável em um dia e quebre no outro.

4. Tomada de Decisão Estratégica: Como um banco decide se lança um novo produto de crédito? Como ele define as taxas de juros? Baseado nos dados. E esses dados só são precisos por causa dos accruals. Eles permitem criar modelos preditivos, precificar produtos corretamente e apresentar relatórios confiáveis para investidores e para o mercado.

No final das contas, para nós, programadores, entender de accrual é uma questão de precisão técnica. Para o banco, é uma questão de sobrevivência. E é por isso que esse papo, definitivamente, é nosso também.

Accrual é o Verbo, Encargo é o Substantivo

Imagine que você está escrevendo um código. O accrual é o processo, é a função rodando em background. É o for loop que executa a cada dia, a function calcularJuros() que é chamada por um job noturno, o gatilho no banco de dados que dispara quando uma condição é atendida. O accrual é a ação de provisionar, de acumular, de registrar um fato econômico.

O encargo é o resultado final dessa execução. É a variável que, ao final do loop, contém o valor total. É o return da função. O encargo é a coisa, o valor consolidado que aparece na sua fatura com um nome e um número ao lado.

Então, eles não são a mesma coisa, mas a relação entre eles é de causa e consequência.

• O processo de accrual de juros diários...

• ...gera o encargo chamado "Juros do Rotativo" na sua fatura.

• O accrual instantâneo da multa por atraso...

• ...gera o encargo chamado "Multa por Atraso".

Entendido isso, fica muito mais fácil entender a anatomia da "mordida" que vem na sua fatura. Vamos dissecar os principais encargos e ver o motor do accrual funcionando por trás de cada um deles.

Anatomia dos Encargos (IOF, Juros e Mora)

Primeiro, vamos alinhar o conceito principal.

Pense em "Encargos" como uma categoria, uma tag. É a palavra que usamos para agrupar tudo aquilo que aparece na sua fatura e que não é uma compra que você fez. É o termo genérico para juros, tarifas, multas, impostos, etc. A maioria das pessoas joga tudo no mesmo saco ("paguei juros"), mas para nós, que construímos a lógica, entender a diferença é crucial.

Agora, vamos abrir esse guarda-chuva.

1. Juros: O "Aluguel" do Dinheiro

• O que é? Juros são, na sua forma mais pura, o custo do crédito. É o preço que você paga pelo serviço de usar um dinheiro que não é seu. Quando você não paga o valor total da fatura, o banco está, na prática, te emprestando a diferença. Os juros do rotativo são o "aluguel" que o banco cobra por esse empréstimo.

• A Conexão com o Accrual: Este é o nosso exemplo clássico. O banco não inventa um número no final do mês. Ele tem uma taxa de juros diária. O sistema, de forma autônoma, executa um processo de accrual todos os dias: ele olha o seu saldo devedor daquele dia e provisiona o "aluguel" correspondente. Ao final do ciclo, o sistema soma todos esses pequenos "aluguéis" diários e apresenta o valor total para você. Esse valor consolidado é o encargo de juros.

2. Mora: A Penalidade pelo Atraso

• O que é? Muitas pessoas confundem mora3 com os juros do rotativo, mas são coisas diferentes com gatilhos diferentes. A mora é um tipo específico de encargo que só existe se você atrasar o pagamento. Ela é composta por duas partes:

  1. Multa de Mora: Uma multa fixa, geralmente de 2% sobre o valor devido, aplicada uma única vez assim que o vencimento passa.

  2. Juros de Mora: Uma pequena taxa de juros (limitada por lei, em torno de 1% ao mês) que incide a cada dia de atraso sobre o valor devido.

• A Conexão com o Accrual: A lógica aqui é lindamente baseada em eventos.

  • Gatilho: Vencimento da fatura não foi pago integralmente.

  • Ação I (Accrual da Multa): No primeiro instante após o vencimento, o sistema faz um accrual único do valor da multa (2%). O fato gerador (o atraso) aconteceu, a provisão é feita.

  • Ação II (Accrual dos Juros de Mora): A partir daquele momento, inicia-se um processo de accrual diário dos juros de mora. A cada dia que a dívida persiste, um pouquinho mais é provisionado.

  • Na fatura seguinte, você verá o encargo de mora, que é a soma daquela provisão única da multa com a soma de todas as provisões diárias dos juros de mora.

3. IOF: O Imposto do Governo

• O que é? Este é o mais simples de todos. O Imposto sobre Operações Financeiras (IOF) é um imposto federal. O banco não ganha nada com ele; ele apenas atua como um "coletor", repassando o valor para o governo. Ele incide sobre operações de crédito, como quando você entra no rotativo, parcela a fatura ou pega um empréstimo.

• A Conexão com o Accrual: O accrual do IOF também é baseado em um evento. No momento exato em que a sua conta entra no crédito rotativo, o sistema calcula o valor do IOF devido (com base nas regras do governo) e faz um accrual instantâneo daquele valor. Não é um acúmulo diário, mas um registro único disparado por uma ação específica. A fatura, mais uma vez, apenas te apresenta esse encargo, essa provisão que já foi feita lá atrás nos sistemas do banco.

Entender essa anatomia te dá poder. Você para de ver a fatura como um monólito de números e passa a enxergar a lógica, os gatilhos e os processos rodando por trás. E quando você entende a regra do jogo, você programa um jogo muito melhor.

Deixe um comentário

Uma Pausa Para Respirar: Dúvidas Comuns

Calma, não chegamos ao fim do artigo. Pense neste tópico como um checkpoint. Um momento para a gente tomar um fôlego, organizar as ideias e esclarecer aquelas perguntas que podem parecer óbvias, mas que são a chave para entender tudo o que conversamos.

Vamos lá.

Minha fatura só gera accruals se ela vencer ou se eu não pagar o total?

Essa é a pergunta de um milhão de reais. A resposta é: Não.

O sistema está sempre fazendo accruals, mas de tipos diferentes. Os accruals que mais nos preocupam – os de juros e multas – são, de fato, acionados por um evento de inadimplência (pagar após o vencimento) ou financiamento (pagar menos que o total).

Porém, mesmo que você seja o cliente mais pontual do mundo, outros tipos de accruals estão acontecendo:

• Pontos de Fidelidade: A cada compra, o sistema faz um accrual de pontos para você, que é uma obrigação (uma despesa provisionada) para o banco.

• Controle de Parcelas: Se você fez uma compra parcelada, o sistema está gerenciando o accrual dessas parcelas futuras, reconhecendo a cada mês a parcela que se tornou devida no ciclo atual.

Portanto, a resposta curta é: os accruals mais "dolorosos" só aparecem se você atrasar, mas o sistema está sempre trabalhando com provisões.

Então, toda fatura gera accruals?

Sim, toda fatura é o resultado de accruals. A diferença está em quais accruals serão convertidos em encargos que você efetivamente paga.

Se você paga tudo em dia, sua fatura é, basicamente, a consolidação de todas as suas compras mais, talvez, a anuidade. Os accruals de juros por atraso ou de rotativo foram calculados em potencial, mas como você cumpriu a condição de pagar em dia, eles nunca foram materializados como um encargo.

Eu pago do meu bolso pelos accruals se pagar a fatura em dia e no total?

Aqui está a beleza do sistema para o consumidor consciente: NÃO.

Esta é a distinção mais importante que você precisa entender. O accrual é uma provisão, um cálculo interno, um "rascunho" que o sistema faz para estar preparado.

Pense assim: o sistema está, a todo momento, se perguntando: "E se o cliente não pagar? Quanto eu teria que cobrar de juros e mora?". Ele faz esse cálculo (o accrual) e deixa o valor "de prontidão".

No momento em que você paga a fatura integralmente na data correta, você envia um sinal para o sistema: "Pode rasgar esse rascunho". Todas aquelas provisões de juros e multas que estavam prontas para se tornarem encargos são simplesmente zeradas, descartadas. Elas nunca chegam a se materializar na sua conta.

Você só paga pelo accrual quando ele se transforma em um encargo real na sua fatura, e isso só acontece se você não cumprir o combinado do pagamento.

Recapitulando os Pontos Altos

Para garantir que estamos na mesma página, vou deixar o resumo da nossa conversa até agora:

• Fatura é a 'foto', Accrual é o 'filme': A fatura é o resultado final, enquanto o accrual é o processo contínuo que acontece durante todo o mês.

• Accrual é o PROCESSO, Encargo é o RESULTADO: O accrual é a ação de calcular e provisionar. O encargo (juros, multa) é o valor final que nasce desse processo.

• Nós vivemos no Regime de Competência: Como programadores, nossa lógica não se baseia no dinheiro que entra ou sai, mas no momento em que o fato econômico (uma dívida de juros, o direito a pontos) acontece.

• Juros, Mora e IOF são Encargos Diferentes: Cada um tem um gatilho e uma lógica de accrual específicos, e entender essa diferença é a chave para construir sistemas financeiros precisos.

Pronto. Respire fundo.Vamos em frente.

De Onde Vêm Esses Números? (A Lógica por Trás da Cobrança)

Quando a fatura com encargos chega, os valores não foram criados magicamente no dia do fechamento. Eles são o resultado de uma série de gatilhos e cálculos precisos, baseados em eventos que aconteceram no ciclo anterior. Vamos entender exatamente quando o banco pode, e vai, aplicar cada encargo.

• Juros (do Rotativo ou Parcelamento): O Custo do Financiamento

  • Gatilho: Você paga qualquer valor menor que o total da sua fatura, mas igual ou maior que o mínimo.

  • Quando começa? A partir da data de vencimento da fatura anterior. O sistema pega o saldo que você não pagou (o saldo devedor) e o "rola" para o próximo mês. É sobre esse valor que os juros remuneratórios (o "aluguel" do dinheiro) começarão a ser calculados e acumulados diariamente.

• Mora: A Penalidade pelo Atraso

  • Gatilho: Você paga um valor menor que o mínimo ou simplesmente não paga nada até a data de vencimento.

  • Quando começa? A cobrança é acionada no primeiro dia útil após a data de vencimento. É neste dia que o sistema aplica a multa de 2% (de uma só vez) e começa o accrual diário dos juros de mora (que são menores, em torno de 1% ao mês). A mora é uma penalidade específica por quebrar o contrato, por estar "em atraso".

• IOF (Imposto sobre Operações Financeiras): O Pedágio do Governo

  • Gatilho: Você realiza uma operação de crédito.

  • Quando acontece? No momento exato em que a operação é efetivada. Isso acontece quando:

    1. Você entra no crédito rotativo (não paga o total).

    2. Você faz um parcelamento da fatura.

    3. Você realiza um saque usando o limite do cartão de crédito.

       O IOF é calculado e provisionado (via accrual) instantaneamente, e a cobrança é consolidada na próxima fatura.

Agora vamos para a matemática disso tudo!

A Matemática do Accrual Diário: Como a Dívida Cresce

Ok, mas como o sistema calcula esses valores a cada dia sobre uma fatura vencida? Aqui a precisão matemática é fundamental. Um erro de arredondamento pode gerar problemas regulatórios e financeiros gigantescos.

Vamos simular o cálculo para uma fatura de R$ 1.000,00 que não foi paga.

Nossas Variáveis:

• Saldo Devedor Inicial: R$ 1.000,00

• Taxa de Juros do Rotativo: 14% ao mês (explico mais na nota)

• Multa por Atraso: 2% (fixa)

• Juros de Mora: 1% ao mês (fixo por lei)

A Conversão Crucial para Taxas Diárias

O erro mais comum seria pegar a taxa mensal e dividir por 30. Isso está errado, pois ignora o efeito dos juros compostos. A fórmula correta, que todo sistema financeiro usa, para converter uma taxa mensal em diária é:

• Taxa Diária do Rotativo: ((1+0,14)^(1/30))−1 ≈ 0,00438 ou 0,438% ao dia.

• Taxa Diária de Mora: ((1+0,01)^(1/30))−1 ≈ 0,00033 ou 0,033% ao dia.

O Loop Diário do Sistema

Cenário: A fatura venceu na segunda-feira e não foi paga.

Terça-feira (Dia 1 após o vencimento): O Gatilho

• Multa: aplicada uma única vez sobre o saldo original.

  → R$ 1.000,00 × 2% = R$ 20,00

• Juros (Mora + Rotativo): calculados no primeiro dia sobre o saldo original.

  → Juros do Dia 1 = R$ 1.000,00 × (0,438% + 0,033%) = R$ 4,71

• Novo Saldo: 1.000,00 + 20,00 + 4,71 = R$ 1.024,71

Quarta-feira (Dia 2 após o vencimento): O Efeito Composto

• Juros incidem sobre o novo saldo devedor (que já contém a multa e os juros do dia anterior).

  → Juros do Dia 2 = R$ 1.024,71 × 0,471% = R$ 4,83

• Novo Saldo: 1.024,71 + 4,83 = R$ 1.029,54

A Persistência do Processo

Esse processo se repete incansavelmente, todos os dias (incluindo fins de semana e feriados), até que um pagamento seja efetuado. Se houver pagamento parcial, ele abate o saldo devedor, e os juros continuam incidindo diariamente sobre o valor restante.

Observações importantes

1. Rotativo + Mora:

   Na prática, alguns bancos calculam o rotativo e a mora de forma separada, mas no efeito final ambos somam-se ao saldo devedor. Para fins didáticos, simplificamos mostrando como se fossem aplicados juntos.

2. Rotativo em 2025:

   Desde 2017, o Banco Central limitou o rotativo do cartão: o cliente só pode permanecer nele até o próximo fechamento da fatura. Se não pagar, o banco é obrigado a oferecer um parcelamento.

   ➝ Até o dia do fechamento, porém, a lógica de accrual diário que mostramos é exatamente a que roda nos sistemas.

Para o sistema financeiro, essa precisão diária não é um exagero — é a única forma de refletir corretamente o custo do dinheiro ao longo do tempo. E como programador, sua responsabilidade é traduzir essa lógica matemática implacável em um código igualmente preciso e robusto.

Como um Accrual se Torna uma Linha na Fatura

Até agora, nós mergulhamos fundo no motor do sistema: o que é um accrual, como ele alimenta os diferentes tipos de encargos e qual a matemática que o rege. Agora, vamos para o momento mais importante: a hora em que esse trabalho invisível, que acontece nos bastidores por 30 dias, se transforma em algo real e tangível para o cliente.

Para construir essa ponte, vamos reforçar um ponto fundamental que já comentamos, e que é a ideia mais importante que você precisa levar deste artigo:

A sua fatura não é calculada no dia do fechamento. Ela é consolidada no dia do fechamento.

Pense no dia do fechamento não como o dia em que um grande e complexo cálculo é feito do zero, mas sim como o dia do "fechamento do diário de bordo". É o momento em que o sistema simplesmente para de registrar novos eventos para aquele ciclo e executa um grande SELECT SUM() em todos os pequenos registros (accruals) que foram meticulosamente anotados, dia após dia.

Vamos visualizar o filme acontecendo, em vez de só olhar a foto:

Imagine o ciclo da sua fatura.

• Semana 1: Você não pagou o total da fatura anterior, então R$ 500,00 entraram no crédito rotativo. O sistema, já no primeiro dia, faz um accrual instantâneo do IOF sobre essa operação. E, a cada noite, silenciosamente, ele executa aquele job que já detalhamos: calcula os juros do rotativo sobre o saldo devedor daquele dia usando a taxa diária e anota (faz o accrual de) alguns centavos ou reais em uma tabela de provisões.

• Semana 2: Você faz uma compra no supermercado. O sistema registra a transação e, ao mesmo tempo, faz o accrual dos pontos de fidelidade correspondentes. O trabalho de acumular os juros do rotativo continua, noite após noite, somando-se ao montante provisionado.

• Semana 3: A fatura anterior, além de não ter sido paga integralmente, foi paga com dois dias de atraso. Lembra da lógica da mora? O sistema, lá atrás, no momento do atraso, fez um accrual único da multa de 2% e, por dois dias, fez o accrual diário dos juros de mora. Esses valores estão lá, guardados, esperando o próximo "fechamento de diário".

• Dia do Fechamento: Chegou o grande dia. O que o sistema faz?

  1. Corta o cordão: Nenhuma compra a partir deste momento entrará nesta fatura.

  2. Roda o último accrual: Executa pela última vez o cálculo dos juros diários do rotativo para este ciclo.

  3. A Consolidação (A Ponte é Cruzada): Agora, o sistema executa a "soma de tudo". Ele vai buscar todos os registros provisionados para o seu CPF naquele ciclo:

     • A soma de todas as suas compras.

     • A soma de todos os juros do rotativo que foram provisionados diariamente.

     • A soma de todos os juros de mora que foram provisionados diariamente lá no início.

     • O valor daquela multa por atraso que foi provisionada de uma só vez.

     • O valor daquele IOF que foi provisionado no instante em que você entrou no rotativo.

É neste momento que o accrual cruza a ponte. Cada uma dessas somas se torna uma linha na sua fatura. O valor abstrato e interno, a "provisão", ganha um nome ("Encargos de Rotativo", "Multa por Atraso") e se materializa como um número real que compõe o seu saldo a pagar.

A fatura, portanto, não é um ato de criação, mas um ato de revelação.

Por que o BACEN se Importa (e Muito) com seus Accruals

Até agora, falamos sobre como os accruals impactam a fatura de um cliente ou a lógica de um sistema. Mas por que uma entidade tão poderosa como o Banco Central, responsável por zelar por trilhões de reais, estaria interessada nesses pequenos cálculos diários de juros e provisões?

A resposta é simples e direta: para impedir crises financeiras.

O BACEN não enxerga o accrual como um detalhe contábil. Ele o enxerga como um detector de fumaça. É o mecanismo que permite ao regulador ver um incêndio em potencial (um risco de calote em massa) muito antes das chamas (a inadimplência real) se tornarem visíveis para todo mundo. Os accruals são, para o BACEN, a ferramenta mais poderosa de supervisão e gestão de risco sistêmico que existe.

Para entender essa relação visceral, precisamos primeiro esclarecer algumas dúvidas que, com certeza, surgiram.

Provisionamento é a mesma coisa que Accrual?

Essa dúvida aparece muito e a resposta é simples: não são a mesma coisa, mas estão intimamente ligados.

O accrual é o conceito guarda-chuva do Regime de Competência. Ele garante que uma empresa registre seus eventos econômicos no momento em que acontecem, e não apenas quando o dinheiro entra ou sai do caixa. Isso vale tanto para receitas quanto para despesas. É a lógica que faz com que o balanço de um banco reflita a realidade econômica dia após dia.

Já o provisionamento é um tipo específico de accrual. Ele aparece quando existe uma obrigação ou perda provável cujo valor ou data ainda não são totalmente certos. É por isso que, no dia a dia, usamos o termo “provisão” quase sempre para despesas ou perdas, como o risco de inadimplência ou um processo judicial.

Dá pra resumir assim: todo provisionamento é um accrual, mas nem todo accrual é provisionamento. Além disso, os accruals podem ser positivos (por exemplo, receitas de juros que ainda não entraram no caixa, mas já foram geradas), enquanto as provisões tendem a ser negativas, ligadas a perdas esperadas.

Um exemplo prático ajuda a visualizar: quando o banco registra diariamente os juros do rotativo, isso é um accrual de receita — a dívida já existe, logo o registro também. Já quando ele calcula a PCLD (Provisão para Perdas de Crédito de Liquidação Duvidosa), trata-se de um provisionamento. A inadimplência ainda não aconteceu, mas a chance de acontecer é grande o suficiente para que a despesa seja reconhecida desde já.

Bora para uma analogia simples: o accrual é como anotar na lista de compras tudo que você já colocou no carrinho — o fato já aconteceu, só falta pagar no caixa. O provisionamento é como anotar algo que você ainda não pegou, mas tem quase certeza de que vai precisar. Você não sabe exatamente a marca ou a quantidade, mas já se prepara para esse gasto provável.

Então existem “tipos” de Accruals?

Sim, existem. Do ponto de vista de um banco — e também do BACEN — podemos dividir os accruals em duas grandes famílias:

• Accruals de Operação: são os registros do dia a dia, que refletem a atividade normal do negócio. Aqui entram, por exemplo, os juros a receber de um cliente ou os salários a pagar dos funcionários. É a contabilidade acompanhando o fluxo natural de receitas e despesas que já aconteceram, mesmo que o dinheiro ainda não tenha trocado de mãos.

• Accruals de Risco (Provisionamentos): esses são os que mais chamam a atenção do regulador, porque mostram a capacidade do banco de se proteger contra perdas futuras. O exemplo clássico é a PCLD que registra antecipadamente o risco de inadimplência da carteira de crédito. É como se o banco dissesse: “sei que parte desse dinheiro não vai voltar, então já vou me preparar desde agora”.

Enquanto os accruals de operação mantêm o negócio rodando de forma transparente, os accruals de risco são o termômetro da solidez financeira. É por isso que o BACEN olha para eles com lupa: eles revelam se o banco está sendo prudente e realista na forma como enxerga sua própria exposição a perdas.

Onde o Accrual se Torna a Espinha Dorsal da Regulação

Aqui a nossa conversa se conecta diretamente com o coração da supervisão do BACEN. A regulamentação sobre este tema evoluiu muito, mas para entender a essência do conceito de forma simples, vamos usar como exemplo a lógica da famosa Resolução CMN nº 2.682/1999. Embora ela não esteja mais em vigor, seu modelo, baseado em "perda incorrida", foi a base do sistema por mais de 20 anos e é bom citar para fins didáticos.

Naquele modelo, o Banco Central OBRIGAVA as instituições a fazerem o seguinte:

1. Classificar TODAS as operações de crédito em níveis de risco, de AA (mínimo) a H (máximo).

2. O critério principal? O atraso. A classificação piorava drasticamente conforme os dias de atraso no pagamento aumentavam.

3. Fazer um Provisionamento (Accrual de Risco) Obrigatório para cada nível de risco.

Vamos a um exemplo prático baseado nessa lógica histórica:

• Um cliente tem uma dívida de R$ 10.000,00.

• Atraso de 1 a 30 dias (Nível B): O risco era baixo. O banco devia provisionar 1% do valor (R$ 100,00).

• Atraso de 61 a 90 dias (Nível D): O risco aumentava. A provisão subia para 50% (R$ 5.000,00).

• Atraso acima de 360 dias (Nível H): Considerado prejuízo. Provisão de 100% (R$ 10.000,00).

O que isso significava? O banco era forçado a reconhecer a perda muito antes de desistir da cobrança, criando um "colchão de segurança" baseado em dados, não em otimismo.

Hoje, a regra evoluiu. A norma em vigor é a Resolução CMN nº 4.966/2021, que alinhou o Brasil ao padrão internacional IFRS 9. A filosofia mudou de um modelo reativo ("perda incorrida") para um modelo proativo e muito mais complexo: o de "perda de crédito esperada".

Agora, os bancos não podem mais esperar o cliente atrasar. Eles precisam, desde o primeiro dia do empréstimo, usar modelos estatísticos e preditivos para estimar a probabilidade de calote no futuro, considerando o cenário econômico, o perfil do cliente e a evolução de sua saúde financeira. Isso tornou o processo de accrual de risco ainda mais sofisticado e crucial, exigindo uma capacidade de análise de dados imensamente maior.

Por que o Accrual é Tão Valioso para o BACEN?

Agora a resposta fica ainda mais clara. Os accruals são valiosíssimos para o BACEN porque eles são a matéria-prima para o cálculo de risco, seja pelo modelo antigo ou pelo atual.

Ao forçar os bancos a operarem no Regime de Competência e a fazerem esses complexos accruals de risco, o BACEN ganha uma visão raio-x, em tempo real, da verdadeira saúde do sistema financeiro nacional. Ele não precisa esperar os bancos quebrarem; ele consegue ver a "febre" (o aumento das provisões para perdas esperadas) muito antes.

Quando um banco envia seus relatórios ao BACEN (como o famoso Arquivo 3040/4040 do SCR), ele está, na verdade, confessando o resultado de todos os seus processos de accrual. Ele está dizendo: "com base nos complexos modelos de risco que meu sistema alimenta diariamente, aqui está o nível de risco da minha carteira e o 'colchão de segurança' que eu fui obrigado a construir".

O Papel das Processadoras e Plataformas de Core Banking

Até este ponto da nossa conversa, detalhamos a imensa complexidade que vive nos bastidores de uma simples fatura de cartão. Falamos de accruals diários, juros compostos, regras do BACEN, provisionamento de risco e uma infinidade de cenários de exceção que o código precisa prever.

Diante de tudo isso, uma pergunta pragmática surge para nós, programadores: "Eu realmente teria que construir cada pedaço dessa engrenagem do zero?"

Imagine ser contratado por uma nova fintech que quer lançar um cartão de crédito. Sua equipe teria que passar anos-luz estudando a regulamentação, construindo um motor de cálculo de juros à prova de balas, garantindo a conformidade com o BACEN, obtendo certificações de segurança caríssimas... tudo isso antes mesmo de começar a pensar no aplicativo que o cliente final usará. Este é o dilema clássico do "Build vs. Buy" (Construir vs. Comprar) aplicado ao coração do sistema financeiro.

Construir um "Core Banking" do zero é como decidir escrever seu próprio sistema operacional antes de criar um aplicativo. É possível? Sim. É viável e inteligente na maioria dos casos? Absolutamente não.

É exatamente para resolver esse dilema que existe um ecossistema de empresas de tecnologia financeira cuja única missão é fornecer o "motor" pronto. São as chamadas processadoras de pagamentos ou plataformas de Core Banking-as-a-Service. Pense em nomes como Pismo (agora parte da Visa), Dock, Mambu, entre outras.

O objetivo delas é simples e poderoso: elas já construíram, testaram exaustivamente e certificaram toda aquela infraestrutura complexa que discutimos. Elas oferecem esse "motor" através de APIs, permitindo que qualquer empresa – seja um banco, uma fintech ou uma varejista – possa "plugar" em seu sistema e começar a oferecer produtos financeiros em meses, em vez de anos.

Elas cuidam de toda a "plumbing" (o encanamento) financeiro para que seus clientes possam focar naquilo que realmente os diferencia no mercado: a experiência do usuário, o design do aplicativo, o atendimento ao cliente e a estratégia de negócio.

É por causa dessa separação de papéis que conseguimos entender como cenários extremamente complexos, como a alteração de uma taxa de juros no meio do ciclo, são gerenciados na prática. E isso nos leva a uma questão interessante que ilustra perfeitamente essa dinâmica.

Por Dentro do Motor: Como as Processadoras Orquestram os Accruals

Nós estabelecemos que a fintech não escreve a lógica de accrual, ela apenas "chama uma API" da processadora. Mas o que acontece do outro lado dessa chamada? Como uma plataforma como a Pismo garante que o cálculo de juros de milhões de contas seja feito de forma precisa, auditável e em conformidade com as regras de cada cliente?

A magia acontece através da combinação de três pilares fundamentais: um Ledger Imutável, uma Arquitetura Orientada a Eventos e um Motor de Regras Configurável.

Pilar 1: O Ledger - A Verdade Absoluta

No coração de qualquer plataforma de processamento existe um ledger (livro-razão contábil). Pense nele como o sistema de controle de versão git para o dinheiro.

• Contabilidade de Dupla Entrada: Cada evento financeiro não é apenas um número que muda em uma tabela. Ele gera, no mínimo, duas entradas: um débito em uma conta e um crédito em outra. Por exemplo, uma compra de R$100 debita a conta do cliente (aumenta sua dívida) e credita a conta da loja.

• Imutabilidade: Esta é a regra de ouro. Você nunca altera ou apaga um registro do ledger. Se um erro foi feito, você cria uma nova transação que o reverte. Isso garante uma trilha de auditoria perfeita e incorruptível.

Como isso se conecta aos accruals? Um accrual de juros não é apenas um UPDATE clientes SET saldo = saldo + juros. Ele é um evento de ledger. O sistema gera uma entrada debitando a conta do cliente (aumentando sua dívida de juros) e creditando uma conta de "Juros a Receber" do banco. Tudo fica registrado, datado e justificado.

Pilar 2: A Arquitetura Orientada a Eventos - O Sistema Nervoso

A plataforma não é um roteiro linear que roda do início ao fim. Ela é um sistema nervoso que reage a eventos. Milhares de eventos acontecem a cada segundo, e cada um pode ser um gatilho para uma ação.

Alguns eventos-chave:

• TransaçãoAutorizada

• PagamentoRecebido

• FaturaFechada

• DataDeVencimentoUltrapassada

• EstornoConfirmado

Como isso se conecta aos accruals? A lógica de accrual é acionada por esses eventos. O evento DataDeVencimentoUltrapassada é o gatilho que dispara a primeira provisão da multa e o início do accrual diário dos juros de mora. O evento FaturaFechada (com pagamento parcial) é o gatilho que move o saldo para o rotativo e inicia o accrual dos juros remuneratórios. O sistema está constantemente "ouvindo" esses gatilhos para aplicar a lógica correta no momento exato.

Pilar 3: O Motor de Regras - O Cérebro Configurável

Este é o pilar que responde à pergunta de como a Pismo atende centenas de clientes diferentes com regras de negócio distintas. A lógica de cálculo não é hard-coded. Ela é controlada por um motor de regras altamente configurável.

Quando uma fintech se torna cliente de uma processadora, ela não recebe um software "engessado". Ela passa por um processo de onboarding onde configura centenas de parâmetros que definem o comportamento de seus produtos financeiros.

Pense nisso como um painel de controle gigante, onde a fintech define:

• Produto "Cartão Gold":

  • TaxaJurosRotativo: 14% a.m.

  • PercentualMultaAtraso: 2%

  • TaxaJurosMora: 1% a.m.

  • DiaFechamentoFatura: 20

  • PercentualPagamentoMinimo: 15%

• Produto "Cartão Universitário":

  • TaxaJurosRotativo: 9% a.m.

  • PercentualMultaAtraso: 2%

  • TaxaJurosMora: 1% a.m.

  • DiaFechamentoFatura: 15

  • PercentualPagamentoMinimo: 10%

Juntando Tudo: A Rotina do Job de Accrual Diário

Com esses três pilares, podemos finalmente visualizar o que o job noturno de accrual realmente faz:

1. Seleção: O job seleciona todas as contas que estão em uma situação que exige accrual (ex: saldo em rotativo).

2. Consulta às Regras: Para cada conta, ele consulta o Motor de Regras: "Quais são os parâmetros de juros para o produto desta conta hoje?". Isso permite, por exemplo, que taxas que mudaram no meio do ciclo sejam aplicadas corretamente.

3. Execução do Cálculo: O motor de cálculo, que é genérico, pega os parâmetros específicos daquela conta e aplica a fórmula matemática padrão para calcular o valor dos juros do dia.

4. Geração do Evento: O cálculo gera um evento, como JurosProvisionados, contendo o ID da conta, o valor, a data, a taxa usada, etc.

5. Registro no Ledger: O sistema de ledger "ouve" esse evento e cria as entradas contábeis imutáveis correspondentes, finalizando o processo de forma segura e auditável.

Portanto, as processadoras cuidam dos accruals através de uma arquitetura robusta que separa o "o quê" (as regras de negócio, configuradas pela fintech) do "como" (o motor de cálculo, a reação a eventos e o registro contábil, garantidos pela plataforma). É essa separação que permite que elas ofereçam um serviço tão complexo de forma segura e escalável para todo o mercado.

E como tudo o que conversamos se conecta com você?

Sua Responsabilidade Como Programador

Chegamos ao ponto crucial para nós, desenvolvedores. Entendemos a teoria, a regulação e a matemática, mas como isso se transforma em código robusto e confiável? O que nosso código deve prever? Onde estão as armadilhas?

Se você achou que accruals e encargos eram complicados no conceito, espere até ver a complexidade de implementá-los no mundo real. A seguir, vamos explorar os cuidados, os desafios e as boas práticas que separam um sistema financeiro funcional de uma bomba-relógio.

1. A Obsessão pela Precisão: Adeus, Float!

A primeira regra do clube da programação financeira é: você não usa float para dinheiro.

• O Problema: Tipos de ponto flutuante (float, double) são representações binárias aproximadas de números decimais. Isso significa que eles podem gerar pequenas imprecisões de arredondamento. Para um carrinho de compras de e-commerce, uma diferença de R$ 0,000001 é irrelevante. Para um sistema que calcula juros de milhões de contas diariamente, essa poeira de imprecisão se acumula e vira uma tempestade de areia, gerando diferenças contábeis, problemas com o BACEN e a fúria dos clientes.

• A Solução: Use tipos de dados criados para precisão absoluta.

  • Decimal ou BigDecimal: A maioria das linguagens modernas (Python, Java, C#) oferece um tipo Decimal que armazena o número como uma representação decimal exata, ideal para cálculos financeiros.

  • Trabalhar com Inteiros: Uma abordagem muito comum e robusta é tratar todos os valores monetários como inteiros, representando a menor unidade da moeda (centavos). R$ 1.029,54 vira o inteiro 102954. Todos os cálculos são feitos com inteiros (que são exatos) e a conversão para decimal só acontece na hora de exibir o valor para o usuário.

2. Idempotência é Rei: O Medo do "Job" Duplicado

Imagine o job noturno que roda o accrual de juros de todas as contas do banco. Ele começa a rodar, processa 50% das contas e, por uma falha de rede, cai. O sistema de monitoramento, espertamente, o reinicia. A pergunta que tira o sono de qualquer dev financeiro é: o que acontece com as 50% de contas que já foram processadas?

• O Risco: Se a operação de accrual não for idempotente, os juros daquele dia serão calculados e somados duas vezes para metade dos clientes. Um desastre.

• A Solução: Seu código deve ser construído para ser idempotente. Isso significa que uma operação, mesmo que executada múltiplas vezes, produzirá sempre o mesmo resultado final.

  • Controle de Transação: Use um identificador único para cada execução do job diário. Antes de calcular o accrual de uma conta, verifique se já não existe um registro de provisão para aquela conta naquele dia específico. Se já existir, simplesmente pule.

  • Lógica "UPSERT": Em vez de um simples INSERT na tabela de provisões, use uma lógica de UPSERT (UPDATE se já existe, INSERT se não existe), garantindo que o registro daquele dia para aquela conta seja único.

3. A Defesa Contra o Mundo Real: Lidando com os Edge Cases

A lógica matemática é linda no papel, mas o mundo real é uma bagunça. Seu código precisa ser um castelo fortificado, preparado para todos os cenários, especialmente os inesperados (edge cases).

• Pagamentos Parciais e Inesperados: O cliente pode pagar qualquer valor, a qualquer hora. Como seu sistema lida com um pagamento que quita a multa e parte dos juros, mas não o principal? A ordem de quitação (geralmente, encargos primeiro, depois principal) precisa estar clara e corretamente implementada.

• Estornos e Chargebacks: Uma compra de R$ 300,00 que já teve accrual de pontos é estornada. Seu sistema precisa reverter não apenas o valor da compra, mas também os pontos provisionados. Se juros já incidiram sobre essa compra no rotativo, o recálculo precisa ser preciso.

• Fuso Horário e Feriados: O job roda à meia-noite. Meia-noite de qual fuso? O que acontece quando o vencimento de uma fatura cai em um feriado bancário? A data de vencimento e o início da cobrança de mora precisam ser empurrados para o próximo dia útil, e seu código precisa conhecer o calendário de feriados nacionais.

• Alterações de Contrato: O que acontece se a taxa de juros do cliente mudar no meio do ciclo de fatura? O accrual diário precisa pegar a taxa correta para cada dia, não uma única taxa para o mês todo.

4. A Rede de Segurança: A Importância Crítica dos Testes de Unidade

Em sistemas financeiros, testes não são uma "boa prática", são uma condição de sobrevivência.

• Teste Cada Cenário: Sua suíte de testes precisa ser exaustiva. Teste o cálculo de juros para 1 dia, 30 dias, 31 dias. Teste com saldo zerado, com pagamento parcial, com pagamento em excesso. Teste o que acontece no dia 29 de fevereiro de um ano bissexto.

• Testes de Regressão: Se você corrigiu um bug no cálculo de mora, precisa garantir que sua correção não quebrou o cálculo de juros do rotativo. Uma suíte de testes de regressão robusta roda a cada alteração no código e é sua principal defesa contra a introdução de novos erros.

• Use Dados Reais (Anonimizados): Sempre que possível, alimente seus testes com cenários que vieram de situações reais de produção (devidamente anonimizados, claro). Eles revelarão edge cases que você nunca imaginaria.

No final das contas, o código que você escreve não está apenas manipulando números; está gerenciando o dinheiro e a confiança das pessoas. Cada linha de código em um sistema de accruals e encargos carrega uma responsabilidade imensa. Ser paranoico com a precisão, obcecado pela idempotência, defensivo contra o caos do mundo real e rigoroso com os testes não é exagero.

Compartilhar

Agradeço por ter lido até o final e espero que o artigo tenha ajudado a entender melhor alguns conceitos financeiros com mais clareza e simplicidade! Até o próximo artigo! 💪🏼