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

# Diseño de tu plan de ledger

> Cómo modelar tu propio negocio como un conjunto de cuentas: un método simple, tipo hoja de trabajo, para diseñar un plan de cuentas antes de construir nada.

A estas alturas ya conoces las piezas: cuentas, saldos, movimientos, las reglas que los rigen. Ahora las pones a trabajar en *tu* negocio. La meta es pasar de «entiendo los términos» a «puedo modelar lo que hace mi empresa».

Un **plan de ledger** (a veces llamado **plan de cuentas**) es una *clasificación deliberada* de las cuentas que tu negocio necesita, y de cómo se relacionan. No es una lista de cuentas que creas apresuradamente. Diseñarlo bien, desde el principio, te evita una reestructuración dolorosa más adelante.

## Piensa en habitaciones antes de construir

***

Imagina que diseñas una casa. Antes de verter concreto, decides para qué sirve cada habitación (cocina, dormitorio, oficina) y quién puede entrar. No empiezas a poner ladrillos y averiguas la distribución después.

Un plan de ledger funciona igual. Decides *para qué* sirve cada cuenta, qué reglas sigue y cómo fluye el dinero entre las habitaciones, **antes** de crear nada. Los cuatro pasos de abajo son ese método.

## Paso 1: enumera tus actores del mundo real

***

Empieza completamente lejos del software. En papel, enumera cada parte del mundo real que toca dinero en tu negocio. Todavía no te preocupes por la estructura. Solo nómbralos.

Una lista típica se ve así:

* **Clientes**: las personas o empresas que guardan valor contigo
* **Tesorería**: tus propios fondos operativos
* **Ingresos**: el dinero que ganas
* **Comisiones**: los cargos que cobras sobre los movimientos
* **Liquidación**: el dinero en tránsito hacia o desde el mundo exterior
* **Gastos**: el dinero que pagas

Esta es tu materia prima. Cada negocio tiene su propia versión de esta lista.

## Paso 2: decide qué necesita su propia verdad

***

No todo actor necesita su propia cuenta. La prueba es simple: **¿esta cosa necesita su propio saldo independiente y confiable, su propia verdad?**

Si necesitas saber, en cualquier momento, exactamente cuánto valor tiene este actor, necesita su propia cuenta. Si es solo una etiqueta o un detalle de otra cosa, no la necesita.

<Tip>
  Como regla práctica, si alguna vez querrías preguntar «¿cuánto hay *aquí* ahora mismo?», entonces eso es una cuenta. Si dos cosas nunca deberían compartir un saldo, tampoco deberían compartir una cuenta.
</Tip>

## Paso 3: clasifica y agrupa con tres preguntas

***

Para cada cuenta que conservaste, hazte **tres preguntas universales**. Juntas te dicen cómo estructurar y agrupar tus cuentas.

| Pregúntate                                                                       | De qué se trata                                                                                                   |
| -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| ¿Estas cuentas necesitan una **regla que valide** qué son o cómo se comportan?   | Clasificación: exigir que una cuenta sea de cierto *tipo*, con sus propias restricciones.                         |
| ¿Necesito **dividirlas para hacer informes**?                                    | Etiquetado: marcar cuentas para poder filtrarlas y reportarlas más tarde por grupo (región, nivel, departamento). |
| ¿Necesito **agruparlas operativamente** alrededor de un cliente o una billetera? | Agrupación operativa: reunir varias cuentas que pertenecen juntas a un mismo propietario.                         |

Estas tres preguntas son independientes. Una cuenta podría necesitar las tres, o solo una. Mantenlas separadas en tu mente:

```mermaid mermaid theme={null}
flowchart TD
  A["Una cuenta en tu plan"] --> Q1{"¿Necesita una regla que<br/>valide su tipo?"}
  Q1 -->|sí| C["Dale una clasificación"]
  A --> Q2{"¿Necesita dividirse<br/>para hacer informes?"}
  Q2 -->|sí| L["Dale una etiqueta de informes"]
  A --> Q3{"¿Pertenece a un grupo<br/>de cliente o billetera?"}
  Q3 -->|sí| G["Ponla en un grupo operativo"]
  classDef q fill:#fff8e1,stroke:#f4b400,color:#333;
  class Q1,Q2,Q3 q;
```

El gran error aquí es reducir estas tres cosas a una sola. Una *clasificación* controla qué tipo puede ser una cuenta. Una *división de informes* es cómo agrupas una cuenta en un informe. Un *grupo operativo* es a qué cuentas pertenecen a un mismo cliente. Cada una es distinta, y tratarlas como una sola maraña es lo que vuelve inmanejables los planes de ledger.

## Paso 4: esboza los movimientos

***

Por último, dibuja las flechas. Para cada tipo de movimiento que hace tu negocio, esboza cuál cuenta es el origen y cuál es el destino. Ese esbozo es lo que necesitarás cuando más adelante definas reglas reutilizables para esos movimientos.

## Un ejemplo resuelto: un negocio simple de billetera

***

Supongamos que operas una app de billetera. Los clientes cargan dinero, se lo envían entre sí, y tú cobras una pequeña comisión sobre las transferencias. Recorre el método:

**Actores:** los clientes, tu cuenta de comisiones/ingresos, y una cuenta de liquidación para el dinero que entra desde el mundo exterior.

**¿Verdad propia?** Cada billetera de cliente necesita su propio saldo. También las comisiones que cobras. También la liquidación, que refleja el mundo exterior.

**Tres preguntas:**

* *¿Validación?* Las billeteras de cliente se comportan distinto de tu cuenta de comisiones, así que son de un **tipo** diferente. Clasifícalas.
* *¿División de informes?* Quieres reportar clientes por país, así que agrega una **etiqueta** para la región.
* *¿Grupo operativo?* Un cliente premium podría tener varias billeteras, así que **agrúpalas**.

**Movimientos:** una transferencia mueve valor de una billetera de cliente a otra, más una pequeña parte hacia la cuenta de comisiones. El dinero que entra a la app se mueve desde la liquidación hacia una billetera de cliente.

```mermaid mermaid theme={null}
flowchart LR
  S["Liquidación<br/>(mundo exterior)"] -->|carga| C1["Billetera de cliente A"]
  C1 -->|transferencia| C2["Billetera de cliente B"]
  C1 -->|parte de comisión| F["Comisión / ingresos"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class C1,C2,F,S bal;
```

Ese es un plan de ledger completo para un negocio pequeño, esbozado antes de tocar ninguna herramienta.

## Errores comunes de principiante

***

* **Sobreclasificar.** Crear una docena de tipos de cuenta cuando bastarían dos. Empieza de forma general. Refina solo cuando una regla real lo exija.
* **Mezclar los informes con la estructura.** No incorpores una división de informes (como «región») dentro del *tipo* de una cuenta. Mantén separado cómo clasificas de cómo reportas.
* **Tratar el plan como una lista.** Apresurarte a crear cuentas antes de esbozar los movimientos te deja reorganizando después.
* **Omitir la prueba de la «verdad propia».** Darle a todo su propia cuenta, o meter cosas no relacionadas en una sola, ambas causan problemas.

## Próximos pasos

***

<Note>
  **Míralo en Lerian**

  Esas tres preguntas se corresponden con cómo Lerian modela las cuentas:

  * *¿Regla de validación?* → **Tipos de cuenta**
  * *¿División de informes?* → **Segmentos**
  * *¿Agrupación operativa?* → **Portafolios**

  Míralo todo junto en [Contabilidad en Midaz](/es/products/midaz/accounting-in-midaz), y luego pon tu plan a trabajar con la [ruta de configuración](/es/products/midaz/console/midaz-console-setup-path) de la consola y el [mapa de conceptos](/es/products/midaz/console/midaz-console-concepts-map).
</Note>