# Apropriação diária do investimento: fechamento contábil — duas modelagens

> Data: **2026-07-21**. Estado: **modelagem A ESCOLHIDA e IMPLEMENTADA** (decisão do dono no mesmo dia).
> Origem: verificação da rotina diária pedida pelo dono em 21/07.
> Frente anterior (já pushada, `357c9c61`): `SUBIR GIT MON/CODE-REVIEW-iof-conta-contabil-investimento.md`.

## Decisão e implementação

O dono escolheu **A**. O que mudou, tudo coberto por teste:

| Peça | Mudança |
|---|---|
| `InvestmentJournal.journal_accrual/5` | debita `expense_account` (era `provision_account`) |
| `InvestmentJournal.journal_correction/6` | **removida** — não há correção a fazer no resgate |
| `Investments.maybe_insert_correction/7` | mantém o movimento de módulo, sem perna COSIF; `debit_account`/`credit_account` nulos |
| `InvestmentJournal.resolve_accounts/1` | `provision_account` sai dos obrigatórios |
| `InvestmentProduct.require_cosif_for_new/1` | `provision_account` sai dos obrigatórios (campo aposentado) |
| `InvestmentProductsView.vue` | campo "Conta de Previsão" removido da tela |

**Duas decisões que o desenho deixou em aberto dentro de A, e como foram fechadas:**

1. **`provision_account`: reapontar para despesa ou aposentar?** Aposentado. Manter dois campos
   significando "a conta de despesa" é o convite para alguém reapontar a "Conta de Previsão" para um
   passivo e ressuscitar o defeito. A coluna fica pelo acervo e o `openEdit` do formulário a repassa
   intacta ao salvar, mas ela não configura mais nada.
2. **O movimento de módulo "Correção no resgate" continua?** Continua. Levantamento do código provou que
   ele é a **única linha do extrato da aplicação** (tela admin + PDF "Extrato de Aplicação Financeira" +
   CSV) que mostra ao cliente o rendimento bruto — a apropriação diária grava em `investment_provisions`,
   que nenhuma tela lê. Sem ele o extrato exibiria IRRF e IOF retidos sobre um rendimento invisível. Os
   campos `debit_account`/`credit_account` da linha foram para NULL porque descreviam um lançamento que
   não acontece mais; nenhuma tela os renderiza, então a mudança não é visível ao usuário.

**Prova.** `investment_accrual_competencia_test.exs` (novo, `:integration`) dirige `accrue_interest/3`
por 5 dias e só então resgata. Antes da mudança: 3 testes, 3 falhas, **nos números exatos projetados
neste documento** (125 credor no passivo / despesa só no dia do resgate / 101 devedor na corrente).
Depois: 3/3 verdes. Regressão do domínio de investimentos: 180 testes 0 falhas na suíte padrão,
10 integration 0 falhas, `vue-tsc` limpo.

## Resumo

A rotina diária **existe e funciona**: `Investments.AccrualWorker` roda em dia útil (cron 1-5 + feriado
ANBIMA via `Calendario.dia_util?/1`), com catch-up e idempotência, e grava **as duas pernas** — módulo
(`investment_provisions`) e contábil (`journal_accrual`).

O problema não é falta de automação. É que **a perna contábil da apropriação não conversa com a do
resgate**: o rendimento é creditado duas vezes no passivo do investidor, e a apropriação debita uma conta
de PASSIVO em vez de despesa, então o resultado do exercício só é sensibilizado no resgate.

Este documento levanta as duas modelagens possíveis para fechar isso. **A escolha é do contador.**

## Problema, provado

Contrato real `INV-2026-386387` (`mon_core` local): principal R$ 500,00, rendimento R$ 1,25 apropriado em
5 dias úteis (5 × R$ 0,25), IRRF R$ 0,06, IOF R$ 0,95.

Lançamentos que o fluxo gera, **na forma projetada com as correções de 21/07 aplicadas** (o contrato real
foi resgatado com o código anterior, então nele o IOF da linha 9 não existe e o resgate da linha 10 saiu
pelo bruto — os valores medidos hoje estão logo abaixo da tabela):

| # | Lançamento | Valor | Débito | Crédito |
|---|---|---|---|---|
| 1 | Aplicação | 50000 | `...002` conta corrente | `...000` passivo investidor |
| 2-6 | Provisionamento de rendimento (5×) | 125 | **`...002` conta corrente** | `...000` passivo investidor |
| 7 | Juros pagos no resgate | 125 | `8.1.1.10.01.10.001` despesa | **`...000` passivo investidor** |
| 8 | IRRF retido | 6 | `...000` | IRRF a recolher |
| 9 | IOF retido | 95 | `...000` | IOF a recolher |
| 10 | Resgate | 50024 | `...000` | `...002` |

Saldos após o contrato encerrado (deveriam zerar):

| Conta | Medido hoje no `mon_core` | Projetado com as correções de 21/07 |
|---|---|---|
| `4.9.8.10.01.10.000` passivo do investidor | **119 credor** | **125 credor** |
| `4.9.8.10.01.10.002` conta corrente contábil | 0 | **101 devedor** |

A diferença entre medido e projetado é só efeito das correções de 21/07, e ela **isola** o defeito desta
frente: hoje os 119 misturam o rendimento em dobro (+125) com o IRRF (−6) e escondem o IOF que nunca era
lançado; depois das correções sobra o rendimento duplicado limpo, 125 — exatamente o valor apropriado.
O resíduo devedor de 101 na conta corrente aparece porque o resgate passa a sair pelo líquido enquanto a
apropriação segue debitando ali (defeito 2 abaixo).

Dois defeitos distintos, somados:

1. **Rendimento creditado em dobro** (linhas 2-6 e 7). A reversão da provisão
   (`maybe_insert_provision_reversal`) insere **apenas** a linha de módulo `investment_provisions`; não
   existe lançamento COSIF de reversão. Inventário do `investment_journal.ex` confirma: as únicas funções
   de lançamento são aplicação, apropriação, correção, IRRF, IOF e resgate. Zero ocorrência de
   reversão/estorno.
2. **A apropriação debita PASSIVO, não despesa.** `journal_accrual` faz D `provision_account` /
   C `cosif_account`, e o `provision_account` do produto 001 aponta para `4.9.8.10.01.10.002`
   ("Obrigações por prestação de serviços de pagamento", categoria PASSIVO). O resultado é: apropriar
   move obrigação entre duas contas de passivo e **nunca toca o resultado**. A despesa só aparece no
   resgate. Sem competência diária.

O defeito 2 é o que produz o resíduo devedor de 101 na conta corrente contábil, que deveria terminar
**credora em 24** (o cliente saiu com R$ 0,24 a mais do que entrou).

## Escopo

**Dentro:** o par débito/crédito da apropriação diária e do resgate de investimento (`journal_accrual`,
`journal_correction`, `maybe_insert_provision_reversal`), e a configuração de contas do produto.

**Fora:** a rotina em si (existe, roda certo, não muda); renda fixa/mesa (`rf_book`, cupons — livro
separado, não toca COSIF); o `AccountingBridge`, que já pula categoria `investment` de propósito.

## Modelagem A — apropriar direto no passivo do investidor

O rendimento entra na mesma conta que já carrega o principal. O passivo sempre reflete o total devido ao
cliente naquele instante — que é exatamente o que ele resgataria.

| # | Lançamento | Valor | Débito | Crédito |
|---|---|---|---|---|
| 1 | Aplicação | 50000 | `...002` | `...000` |
| 2-6 | Apropriação (5×) | 125 | **despesa de captação** | `...000` |
| — | *(sem correção no resgate)* | | | |
| 7 | IRRF | 6 | `...000` | IRRF |
| 8 | IOF | 95 | `...000` | IOF |
| 9 | Resgate | 50024 | `...000` | `...002` |

Fechamento:

| Conta | Créditos | Débitos | Saldo final |
|---|---|---|---|
| `...000` passivo investidor | 50125 | 50125 | **0** |
| `...002` conta corrente | 50024 | 50000 | 24 credor (o rendimento líquido que o cliente ganhou) |
| despesa de captação | — | 125 | 125, reconhecida **dia a dia** |

**Mudanças:**
- Configuração: `provision_account` do produto passa a apontar para uma conta de **DESPESA**
  (`8.1.1.10.01.10.001` já existe e é DESPESA folha, hoje usada só no resgate) — ou o campo é aposentado e
  a apropriação passa a usar `expense_account`.
- Código: remover a perna COSIF do resgate (`maybe_add_correction_journal`). Decidir se o movimento de
  módulo "Correção no resgate" continua (informativo no extrato) ou sai junto.
- `maybe_insert_provision_reversal` fica como está (é conceito de módulo: o saldo de provisão zera porque
  foi pago).

## Modelagem B — provisão segregada, transferida no resgate

O rendimento apropriado vive numa conta de passivo **própria** e só migra para o passivo do investidor no
resgate. Separa principal de rendimento acumulado no balanço.

| # | Lançamento | Valor | Débito | Crédito |
|---|---|---|---|---|
| 1 | Aplicação | 50000 | `...002` | `...000` |
| 2-6 | Apropriação (5×) | 125 | **despesa de captação** | **provisão de rendimento** (conta nova) |
| 7 | Transferência no resgate | 125 | **provisão de rendimento** | `...000` |
| 8 | IRRF | 6 | `...000` | IRRF |
| 9 | IOF | 95 | `...000` | IOF |
| 10 | Resgate | 50024 | `...000` | `...002` |

Fechamento:

| Conta | Créditos | Débitos | Saldo final |
|---|---|---|---|
| `...000` passivo investidor | 50125 | 50125 | **0** |
| provisão de rendimento | 125 | 125 | **0** |
| `...002` conta corrente | 50024 | 50000 | 24 credor |
| despesa de captação | — | 125 | 125, reconhecida **dia a dia** |

**Mudanças:**
- Plano de contas: **criar folha nova** de passivo para a provisão. O subgrupo `4.9.8.10.01.10.x` tem
  `.000`, `.001` e `.002` ocupados; a `.003` está livre (mesmo caminho da folha criada para bloqueio
  judicial numa frente anterior). DV e elenco a validar com o contador.
- Configuração: `provision_account` passa a ser essa folha nova; a despesa vira campo próprio na
  apropriação.
- Código: `journal_accrual` inverte o par (hoje D provisão / C passivo investidor; passa a D despesa /
  C provisão) e `journal_correction` deixa de reconhecer despesa e vira **transferência**
  (D provisão / C passivo investidor).

## Comparação

| | A — direto no passivo | B — provisão segregada |
|---|---|---|
| Competência diária | sim | sim |
| Conta nova no plano | não | **sim** (1 folha de passivo) |
| Passivo do investidor durante a vida | principal + rendimento (o que o cliente resgataria) | só o principal |
| Rendimento acumulado visível separado no balanço | não | **sim** |
| Volume de lançamentos por contrato | menor (−1 no resgate) | igual ao de hoje |
| Tamanho da mudança | configuração + **remover** uma perna | conta nova + inverter 1 par + trocar 1 par |
| Risco de regressão | menor | maior |

**Recomendação técnica: A.** É a que o código já quase faz (a apropriação já credita o passivo do
investidor; o que está errado é o débito e a duplicidade no resgate), fecha com menos peças e não pede
folha nova. O `current_balance` do módulo já soma o rendimento diariamente, então o passivo contábil passa
a espelhar o módulo — os dois contam a mesma história.

**Quando B seria preferível:** se o contador ou algum relatório regulatório exigir enxergar principal e
rendimento apropriado em contas distintas no balancete. É a única vantagem real de B, e é uma exigência
que só ele pode confirmar.

## Reparo de dados

Qualquer das duas exige reparo do acervo, porque os contratos existentes carregam os dois defeitos.

**Escopo por contrato:** resíduo credor no passivo do investidor = rendimento apropriado; resíduo devedor
na conta corrente contábil = rendimento apropriado − tributos retidos.

**Local (`mon_core`)**: `INV-2026-386387` (resíduo 125 credor / 101 devedor) e os 2 contratos de teste que
criei em 21/07. **HML e PROD não foram auditados** — precisa levantar todo contrato com lançamento
`INVESTMENT_ACCRUAL` antes de fechamento contábil.

Padrão de reparo já usado no projeto: estorno rastreável (lançamento `reversal` com referência ao
original) em vez de UPDATE, preservando a trilha.

## Estratégia de teste

✅ **Lacuna FECHADA em 21/07.** O teste `o passivo do investidor zera apos o resgate`
(`investment_iof_journal_test.exs`) não pegava este defeito: a fixture `aplicacao_com_rendimento/5`
inseria a linha de `investment_provisions` direto no banco e nunca chamava `accrue_interest`, então o
cenário não tinha lançamento de apropriação nenhum — não havia perna para duplicar, e o teste passava
verde com o defeito vivo.

**A fixture daquele arquivo foi reescrita para dirigir a apropriação de verdade**, junto com o teste novo
desta frente. Calibragem que reproduz os números do `INV-2026-386387`: principal 50.000 centavos,
`cdi_daily_bps = 5` a 100% do CDI = exatos 25 centavos/dia, 5 dias, resgate no 7º (janela de IOF).

`investment_accrual_competencia_test.exs` verifica:
1. passivo do investidor zera;
2. despesa reconhecida **por dia**, não só no resgate (a asserção por dia vem antes da do total: o total
   já batia antes da correção, o que faltava era a distribuição no tempo);
3. conta corrente contábil termina credora exatamente no rendimento líquido.

As três asserções são **independentes de modelagem** — descrevem o desfecho do ciclo, não o caminho, e
valeriam igual em B. O item "conta de provisão zera" saiu porque era específico de B.

**Confirmação empírica do inventário local:** dos 3 contratos com lançamento de investimento no
`mon_core`, só o `INV-2026-386387` tinha `INVESTMENT_ACCRUAL`. Os outros dois nasceram da fixture
sintética — inclusive o `INV-2026-990546`, que eu havia registrado como "limpo, resíduo 0". Ele fechava
o passivo em zero **só porque a perna de apropriação nunca existiu**. Não usar como prova de saúde.

## Perguntas para o contador

1. **A ou B?** Existe exigência de ver principal e rendimento apropriado em contas separadas no balancete?
2. **Qual conta de despesa** recebe a apropriação? A `8.1.1.10.01.10.001` ("Despesas de emissão de títulos
   — debêntures/LF") é a que o produto já aponta como `expense_account`, mas o nome sugere emissão de
   títulos, não captação em depósito. O grupo `8.1.1.00.00.00.000` ("Despesas de Captação") é sintético,
   sem folha própria para este caso.
3. **Se for B**, a folha nova `4.9.8.10.01.10.003` serve, e com que nome/elenco?
4. **Reparo do acervo**: estornar e relançar retroativamente, ou tratar como divergência conhecida com
   corte a partir da correção?

## Decisão em aberto, fora do modelo contábil

O dono levantou rodar a apropriação **de madrugada**, como a de empréstimo (`LoanAccrualWorker`, 03:30
BRT). Hoje ela roda **19:30 BRT** (mais salvaguarda 08:15). O motivo do horário atual é real: o CDI do dia
só é publicado à noite, e o `CdiImportWorker` roda 30 min antes. Mudar para a madrugada faria a
apropriação usar a taxa do dia anterior, ou exigiria rodar D+1 com data retroativa. **Não é decisão
contábil e não depende deste desenho** — se o dono quiser padronizar o horário com o crédito, é ajuste
próprio, com a ressalva da defasagem da taxa.

## Riscos

| Risco | Mitigação |
|---|---|
| Reparo do acervo em PROD sem inventário | Levantar todo contrato com `INVESTMENT_ACCRUAL` **antes** de qualquer correção; dry-run obrigatório |
| Mudar o par da apropriação e quebrar balancete em curso | Aplicar com corte de data acordado com o contador, nunca retroativo silencioso |
| Teste continuar cego ao defeito | O RED desta frente **precisa** rodar a apropriação real; sem isso a modelagem nova pode nascer com o mesmo furo |