> ## 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.

# Projetando seu plano de ledger

> Como modelar seu próprio negócio como um conjunto de contas: um método simples, em formato de planilha, para projetar um plano de contas antes de construir qualquer coisa.

A essa altura você já conhece as peças: contas, saldos, movimentos, as regras que os governam. Agora você as coloca para trabalhar no *seu* negócio. O objetivo é passar de "eu entendo os termos" para "eu consigo modelar o que minha empresa faz".

Um **plano de ledger** (às vezes chamado de **plano de contas**) é uma *classificação deliberada* das contas de que seu negócio precisa, e de como elas se relacionam. Não é uma lista de contas que você cria às pressas. Projetá-lo bem, desde o início, evita uma reestruturação dolorosa depois.

## Pense em cômodos antes de construir

***

Imagine projetar uma casa. Antes de derramar qualquer concreto, você decide para que serve cada cômodo (cozinha, quarto, escritório) e quem tem permissão para entrar. Você não começa a assentar tijolos e descobre a planta depois.

Um plano de ledger funciona da mesma forma. Você decide para que serve cada conta, quais regras ela segue e como o dinheiro flui entre os cômodos, **antes** de criar qualquer coisa. As quatro etapas abaixo são esse método.

## Etapa 1: Liste os atores do mundo real

***

Comece longe do software por completo. No papel, liste toda parte do mundo real que lida com dinheiro no seu negócio. Não se preocupe com a estrutura ainda. Apenas nomeie-as.

Uma lista típica se parece com isto:

* **Clientes**: as pessoas ou empresas que mantêm valor com você
* **Tesouraria**: seus próprios fundos operacionais
* **Receita**: o dinheiro que você ganha
* **Tarifas**: as cobranças que você coleta sobre os movimentos
* **Liquidação**: dinheiro em trânsito de ou para o mundo externo
* **Despesas**: o dinheiro que você paga

Essa é sua matéria-prima. Todo negócio tem sua própria versão dessa lista.

## Etapa 2: Decida o que precisa da própria verdade

***

Nem todo ator precisa de sua própria conta. O teste é simples: **essa coisa precisa de um saldo próprio, separado e confiável, de sua própria verdade?**

Se você precisa saber, a qualquer momento, exatamente quanto valor está com esse ator, ele precisa de sua própria conta. Se é apenas um rótulo ou um detalhe de outra coisa, não precisa.

<Tip>
  Como regra geral, se algum dia você quiser perguntar "quanto tem *aqui* agora?", então isso é uma conta. Se duas coisas nunca devem compartilhar um saldo, elas nunca devem compartilhar uma conta.
</Tip>

## Etapa 3: Classifique e agrupe com três perguntas

***

Para cada conta que você manteve, faça **três perguntas universais**. Juntas, elas dizem como estruturar e agrupar suas contas.

| Pergunte a si mesmo                                                                    | Do que se trata                                                                                                          |
| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Essas contas precisam de uma **regra que valide** o que elas são ou como se comportam? | Classificação — impor que uma conta seja de determinado *tipo*, com suas próprias restrições.                            |
| Eu preciso **fatiá-las para relatórios**?                                              | Rotulagem — marcar contas para que depois você possa filtrar e gerar relatórios por grupo (região, nível, departamento). |
| Eu preciso **agrupá-las operacionalmente** em torno de um cliente ou de uma carteira?  | Agrupamento operacional — reunir várias contas que pertencem juntas a um único titular.                                  |

Essas três perguntas são independentes. Uma conta pode precisar das três, ou de apenas uma. Mantenha-as separadas em sua mente:

```mermaid mermaid theme={null}
flowchart TD
  A["Uma conta no seu plano"] --> Q1{"Precisa de uma regra que<br/>valide seu tipo?"}
  Q1 -->|sim| C["Dê a ela uma classificação"]
  A --> Q2{"Precisa ser fatiada<br/>para relatórios?"}
  Q2 -->|sim| L["Dê a ela um rótulo de relatório"]
  A --> Q3{"Pertence a um grupo de<br/>cliente ou carteira?"}
  Q3 -->|sim| G["Coloque-a em um grupo operacional"]
  classDef q fill:#fff8e1,stroke:#f4b400,color:#333;
  class Q1,Q2,Q3 q;
```

O grande erro aqui é reduzir essas três a uma só. Uma *classificação* controla que tipo uma conta pode ser. Uma *fatia de relatório* é como você agrupa uma conta em um relatório. Um *grupo operacional* é quais contas pertencem a um cliente. Cada uma é diferente, e tratá-las como uma coisa emaranhada é o que torna os planos de ledger inviáveis de gerenciar.

## Etapa 4: Esboce os movimentos

***

Por fim, desenhe as setas. Para cada tipo de movimento que seu negócio faz, esboce qual conta é a origem e qual é o destino. Esse esboço é o insumo de que você vai precisar quando depois definir regras reutilizáveis para esses movimentos.

## Um exemplo prático: um negócio simples de carteira

***

Digamos que você opera um app de carteira. Clientes carregam dinheiro, enviam uns aos outros, e você cobra uma pequena tarifa sobre as transferências. Percorra o método:

**Atores:** clientes, sua conta de tarifa/receita e uma conta de liquidação para o dinheiro que entra do mundo externo.

**Verdade própria?** Cada carteira de cliente precisa de seu próprio saldo. O mesmo vale para as tarifas que você coleta. E para a liquidação, que espelha o mundo externo.

**Três perguntas:**

* *Validação?* As carteiras de cliente se comportam de forma diferente da sua conta de tarifa, então são de um **tipo** diferente. Classifique-as.
* *Fatia de relatório?* Você quer gerar relatórios de clientes por país, então adicione um **rótulo** para região.
* *Grupo operacional?* Um cliente premium pode ter várias carteiras, então **agrupe-as**.

**Movimentos:** uma transferência move valor de uma carteira de cliente para outra, mais uma pequena parte para a conta de tarifa. O dinheiro que entra no app se move da liquidação para uma carteira de cliente.

```mermaid mermaid theme={null}
flowchart LR
  S["Liquidação<br/>(mundo externo)"] -->|carga| C1["Carteira de cliente A"]
  C1 -->|transferência| C2["Carteira de cliente B"]
  C1 -->|parte da tarifa| F["Tarifa / receita"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class C1,C2,F,S bal;
```

Esse é um plano de ledger completo para um negócio pequeno, esboçado antes de tocar em qualquer ferramenta.

## Erros comuns de quem está começando

***

* **Classificar demais.** Criar uma dezena de tipos de conta quando dois bastariam. Comece de forma ampla. Refine apenas quando uma regra real exigir.
* **Misturar relatório com estrutura.** Não embuta uma fatia de relatório (como "região") no *tipo* de uma conta. Mantenha como você classifica separado de como você gera relatórios.
* **Tratar o plano como uma lista.** Criar contas às pressas antes de esboçar os movimentos deixa você reorganizando tudo depois.
* **Pular o teste da "verdade própria".** Dar a tudo sua própria conta, ou espremer coisas não relacionadas em uma só, ambos causam dor.

## Próximos passos

***

<Note>
  **Veja isso na Lerian**

  Essas três perguntas se mapeiam em como a Lerian modela contas:

  * *Regra de validação?* → **Tipos de Conta**
  * *Fatia de relatório?* → **Segmentos**
  * *Agrupamento operacional?* → **Portfólios**

  Veja tudo junto em [Contabilidade no Midaz](/pt/products/midaz/accounting-in-midaz), depois coloque seu plano para trabalhar com o [Caminho de configuração](/pt/products/midaz/console/midaz-console-setup-path) do console e o [Mapa de conceitos](/pt/products/midaz/console/midaz-console-concepts-map).
</Note>