> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Como funciona a apropriação

> O que uma rotina de apropriação faz: o mês contábil que ela reconhece, o valor que calcula, o que a rotina produz e para onde vai o posting resultante.

O Lender não reconhece juros de forma contínua. Ele reconhece juros em uma **rotina de apropriação**. Uma rotina cobre uma data de negócio e, para cada empréstimo que seleciona, reconhece exatamente um mês contábil.

## Um mês por empréstimo, no aniversário do próprio empréstimo

***

O mês contábil de um empréstimo é a sua **competência**. Quem ancora esse mês é a data de desembolso, não o calendário. Um empréstimo desembolsado no dia 12 fecha cada competência no dia 12 dos meses seguintes. Um desembolso no fim do mês se ajusta ao último dia de um mês mais curto.

A **data de negócio** que você passa para uma rotina seleciona a competência. Um empréstimo reconhece apenas quando a data de negócio é um dos seus próprios aniversários. Uma rotina no dia 12 reconhece então os empréstimos com data de desembolso no dia 12, e passa por cima dos demais.

Planeje o calendário a partir disso. Para cobrir a carteira inteira ao longo de um mês, dispare uma rotina em cada data de negócio.

## O que uma rotina faz

***

`POST /api/v1/accrual-runs` recebe a data de negócio e o **modo** da rotina, e, opcionalmente, até 100 ids de produto de empréstimo que restringem a rotina. Tanto `businessDate` quanto `mode` são obrigatórios. O driver agendado envia `monthly`.

<Steps>
  <Step title="O Lender seleciona os empréstimos">
    Você não envia uma lista. O Lender lê a própria carteira e toma cada conta de empréstimo de uma proposta desembolsada ou ativa, dentro dos produtos que você restringiu. Uma conta de empréstimo já liquidada fica de fora. Uma rotina varre até 10.000 contas de empréstimo, então restrinja uma carteira maior por produto e dispare mais de uma rotina.
  </Step>

  <Step title="O Lender reconhece os juros">
    Para cada empréstimo, o Lender resolve a taxa de juros efetiva do cronograma contratual e toma a linha daquela competência. O reconhecimento trabalha sobre os fluxos de caixa contratuais. O que o tomador pagou não altera isso.
  </Step>

  <Step title="O Lender escreve o reconhecimento e a intenção de posting">
    Uma única transação de banco de dados grava a rotina, um item por reconhecimento e a intenção de posting balanceada por trás de cada item. Ou tudo fica durável, ou nada fica.
  </Step>

  <Step title="O relay entrega o posting">
    Depois do commit da rotina, o relay do outbox contabiliza a transação balanceada no Midaz, e o Midaz a registra.
  </Step>
</Steps>

## O valor que o Lender reconhece

***

O reconhecimento segue o método dos juros efetivos. O custo amortizado começa no principal que o cronograma amortiza, menos a tarifa de originação. As retenções ficam fora dele: no Brasil, o IOF é um pass-through e nunca entra no custo amortizado.

O Lender resolve a taxa a partir do próprio cronograma, então os juros reconhecidos reproduzem o contrato em vez de uma taxa separada que você mantenha.

Onde a jurisdição tributa a receita de juros, a rotina reconhece também esse tributo. O tributo é um segundo valor sobre o mesmo empréstimo e a mesma competência, com o seu próprio posting balanceado. Juros e tributo nunca compartilham uma transação.

## Uma vez por empréstimo, por mês, por valor

***

Um reconhecimento é único em três coisas: a conta de empréstimo, a competência e o tipo de valor. Uma segunda rotina para a mesma data de negócio não reconhece nada novo para um empréstimo já reconhecido. Ela não dobra os juros e não enfileira um segundo posting.

Essa unicidade é a garantia da rota do dinheiro. Ela também torna seguro repetir uma rotina depois de uma interrupção.

## O que uma rotina produz

***

Uma rotina responde com:

* O identificador da rotina e o status da rotina.
* Uma **referência de lançamento** — o identificador contábil da rotina.
* O **id de correlação** que o Lender deriva do modo, da data de negócio e dos produtos restringidos.

Por trás dessa resposta, a rotina guarda um item para cada reconhecimento: a conta de empréstimo, a competência, o tipo de valor e o valor. É desses itens que o Lender monta os postings.

Use o id da referência de lançamento para amarrar a rotina aos seus próprios registros contábeis: ele identifica uma única rotina de forma exata. O registro da referência também guarda o id de correlação e, como o Lender deriva esse id do modo, da data de negócio e dos produtos restringidos, uma leitura por id de correlação devolve a rotina mais recente que o compartilha. [Contabilidade e rotinas de apropriação](/pt/lender/accounting-and-accrual-runs) cobre as duas operações que a leem.

## A rotina não escreve o lançamento no ledger

***

Esse limite importa. Uma rotina reconhece os juros e enfileira uma intenção de posting. Ela não chama o Midaz e não espera uma contabilização. O relay contabiliza depois, e o ledger registra a transação. Uma rotina bem-sucedida significa que o reconhecimento e a sua intenção são duráveis — não que o ledger já mostre o lançamento.

Configure duas coisas antes que um posting possa ser contabilizado:

* Dê ao perfil contábil da versão do produto uma regra para o evento `accrual`, com lançamentos balanceados. Onde a jurisdição tributa a receita de juros, adicione também a regra opcional `accrual_tax`, para que o tributo tenha lançamentos próprios.
* Habilite o outbox e configure a conexão com o ledger. Veja [Configuração e implantação](/pt/lender/configuration-and-deploy).

Configure o perfil antes da primeira rotina. Sem uma regra de apropriação, o Lender não tem lançamentos para montar um posting, e a rotina deixa esse empréstimo de fora.

## Empréstimos que uma rotina passa por cima

***

Um empréstimo selecionado ainda pode não reconhecer nada:

* A jurisdição suspende a apropriação dele. No Brasil, os dois estágios mais profundos da escada de provisão suspendem a apropriação — veja [Pacote regulatório do Brasil](/pt/lender/brazil-regulatory-pack).
* A data de negócio não é um dos seus aniversários.
* Os juros dele para aquela competência são zero.

Nenhum desses casos falha a rotina. Uma rotina reconhece o que pode e informa o que reconheceu.

## Apropriação em uma agenda

***

A rotina também tem um driver agendado dentro do serviço. Ele fica desligado até você habilitar, e você define a expressão cron dele, que por padrão aponta para o primeiro dia de cada mês. Dê a ele uma expressão diária: cada empréstimo reconhece no próprio aniversário, então só um driver diário cobre a carteira inteira ao longo de um mês.

Sob multi-tenancy o driver roda uma vez para cada tenant ativo, contra os dados daquele tenant. O caminho agendado e o caminho da API usam o mesmo código. Uma rotina disparada por cron e uma rotina disparada por uma chamada se comportam do mesmo jeito.

## Próximos passos

***

<CardGroup cols={2}>
  <Card title="Contabilidade e rotinas de apropriação" icon="calculator" href="/pt/lender/accounting-and-accrual-runs">
    Perfis contábeis, regras de posting e as operações de referência de lançamento.
  </Card>

  <Card title="Arquitetura do Lender" icon="diagram-project" href="/pt/lender/lender-architecture">
    Os cinco domínios, a costura de jurisdição e o outbox que leva o dinheiro para fora.
  </Card>

  <Card title="Definir um produto de empréstimo" icon="layer-group" href="/pt/lender/define-a-loan-product">
    Produtos, versões e o perfil contábil do qual uma rotina depende.
  </Card>

  <Card title="Pacote regulatório do Brasil" icon="brazilian-real-sign" href="/pt/lender/brazil-regulatory-pack">
    Estágios de provisão, tributos e as divulgações que o perfil brasileiro adiciona.
  </Card>
</CardGroup>
