> ## 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. # Contabilidade e rodadas de apropriação > Como o Lender contabiliza no ledger: perfis contábeis e regras de lançamento, intenções de lançamento duráveis, rodadas de apropriação e referências de diário. Eventos de dinheiro, como um desembolso, um pagamento ou uma apropriação de juros, chegam ao ledger (O livro financeiro central que registra todas as transações, saldos e operações de uma organização. É a fonte única de verdade para as finanças de uma unidade de negócio.). A camada contábil do Lender é como eles chegam lá. Um produto declara as regras de lançamento dele uma vez. Daí em diante, cada um desses eventos é contabilizado de forma automática e rastreável. ## Perfis contábeis e regras de lançamento *** Um **perfil contábil** vincula uma versão de produto ao ledger. Ele define as **regras de lançamento**: as pernas de partidas dobradas (Todo movimento financeiro é registrado como pelo menos duas operações: um débito de uma conta e um crédito para outra, de modo que o sistema está sempre equilibrado.) que disparam para cada tipo de evento financeiro. Ele também define a organização de ledger e o ledger em que as transações resultantes são contabilizadas. Você cria um perfil por produto: `POST /api/v1/loan-products/{id}/accounting-profiles` O Lender valida as regras de lançamento quando você cria o perfil. Um produto, portanto, não entra em produção com pernas que não fechariam. Um perfil precisa de ao menos dez regras, e cada perna declara a `nature` da conta dela. [Definir um produto de empréstimo](https://docs.lerian.studio/pt/products/lender/define-a-loan-product.md) as lista. ## Intenções de lançamento e o relay *** O Lender não chama o ledger inline. Quando um evento financeiro acontece, o Lender persiste uma **intenção de lançamento** durável. Essa gravação acontece na mesma transação de banco de dados que muda o estado do domínio. Um relay então lança a transação balanceada no Midaz de forma assíncrona. Estas propriedades tornam as contabilizações confiáveis: * **A intenção faz commit junto com a mudança de estado**: as duas caem em uma única transação de banco de dados, por um outbox transacional. * **Idempotente**: cada lançamento carrega uma chave determinística, então novas tentativas colapsam em uma única transação do ledger. * **Falha fechada**: se o roteamento não resolver um destino de ledger não vazio, o Lender recusa o lançamento e não o grava no lugar errado. * **Datado pela data contábil**: o Midaz recebe a data em que o Lender lança o movimento. É a data do dinheiro para um pagamento, uma saída ou um desembolso, e o último dia do mês fechado para um lançamento de fechamento de mês ou de correção. Quando o Midaz recusa uma data em um mês arquivado, o Lender lança no mês aberto. [O Lender na plataforma](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md) descreve o caminho inteiro. ## Rodadas de apropriação *** Uma **rodada de apropriação** reconhece juros e os demais valores baseados em tempo. Uma rodada fecha o último mês civil que já tinha terminado por inteiro antes da data de referência dela, para cada empréstimo que seleciona. Ela também produz os lançamentos desse mês. `POST /api/v1/accrual-runs` começa uma rodada. O Lender seleciona as contas de empréstimo candidatas por conta própria, reconhece juros por conta e grava uma intenção de lançamento por reconhecimento. > [!TIP] > > O reconhecimento é idempotente por conta de empréstimo, por mês contábil e por tipo de valor. Uma rodada começada duas vezes para o mesmo mês reconhece juros uma vez. ## Repetir uma rodada *** Um reconhecimento fica durável no instante em que a rodada faz commit. A contabilização no ledger não fica durável. Quando um lançamento nunca chega, repita a rodada em vez de começar uma nova. `POST /api/v1/accrual-runs/{id}/retry` nomeia os itens a reenviar e recebe o mesmo cabeçalho `X-Idempotency` que a própria rodada recebe. É uma segunda tentativa sobre a mesma rodada, então o Lender não registra uma segunda rodada. Para cada item nomeado que o ledger ainda não confirmou, o Lender reenvia o lançamento já enfileirado sob a chave determinística, e só monta um quando não existe nenhum. O relay o entrega, e o ledger trata uma duplicata como duplicata, não como um segundo lançamento. O Lender deixa em paz os itens que o ledger já confirmou. A resposta nomeia, item a item, o que ela não conseguiu reenviar. Ela também nomeia o porquê: o lançamento já tinha sido entregue, ele foi posto em quarentena, o contrato por trás dele sumiu, ou o produto está mal configurado. ## Referências de diário *** Cada rodada de apropriação registra uma **referência de diário**, o identificador contábil da própria rodada. O registro da referência também guarda o id de correlação que o Lender derivou para a rodada. O id da referência de diário identifica exatamente uma rodada. Uma leitura por id de correlação retorna a rodada mais recente que compartilha esse modo, essa data de referência e esse escopo de produtos. Uma rodada emite um lançamento por conta de empréstimo, por mês contábil, por tipo de valor. O Lender registra, portanto, o laço de volta com o ledger por lançamento, não por rodada. Assim que o ledger confirma um lançamento, o Lender guarda um recibo sob a chave daquele lançamento. Uma leitura por essa chave responde com a transação do ledger que o contabilizou. Uma referência no nível da rodada não carrega transação de ledger própria: ela nomeia a rodada, e os recibos nomeiam as contabilizações. | Operação | Finalidade | | - | - | | `GET /api/v1/journal-references` | Consultar uma referência de diário pelo id de correlação. | | `GET /api/v1/journal-references/{id}` | Ler uma única referência de diário. | ## Próximos passos *** > [card] [Jurisdições](https://docs.lerian.studio/pt/products/lender/jurisdictions.md) > > Veja como a jurisdição ativa molda as divulgações e os endpoints. > [card] [Pacote regulatório Brasil](https://docs.lerian.studio/pt/products/lender/brazil-regulatory-pack.md) > > Sobreponha CET, IOF e estágios de PDD ao modelo contábil. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.