04. Mapping de plan de cuentas con LLMs

Bienvenido al Módulo 2. En las próximas tres lecciones (4, 5 y 6) vas a construir el primer caso de uso end-to-end del curso: clasificar transacciones contra un plan de cuentas LATAM, con confidence scores y human-in-the-loop.

Empezamos con la base conceptual. Si entendés bien esta lección, las siguientes dos van a sentirse "obvias".

Por qué esta es la "killer app" para contadores

De todas las cosas que un LLM puede hacer hoy en contabilidad, la clasificación contra plan de cuentas es la que paga sola la inversión en IA. ¿Por qué?

Es altamente repetitiva. Un contador junior puede pasar 20-40 horas al mes solo clasificando transacciones bancarias contra el plan de cuentas. Es trabajo lineal, no escalable, mal pagado.
Es estructuralmente "lingüística". Los LLMs son excelentes interpretando textos cortos ambiguos: "PAGO FALABELLA 28/04/2026 $145.000", "TEF MERPAGO COMISION", "DEPOSITO CTA CTE NRO 8821". Reconocen el patrón comercial detrás del texto.
El plan de cuentas es un esquema finito. A diferencia de "redactar una opinión legal" (output abierto), clasificar es elegir entre 200-800 opciones predefinidas. Esto es justo el tipo de tarea donde los LLMs son confiables.
El costo marginal es ridículo. Clasificar 10.000 transacciones cuesta entre 3 y 15 USD vía API. El mismo trabajo manual cuesta entre 200 y 600 USD en horas-junior.
Es perfectamente compatible con el patrón ganador que vimos en la Lección 3: el LLM clasifica, las reglas validan, el humano revisa y firma. Cumple NIA 315.

🎯 Idea clave

No hay "magia" en clasificar transacciones con LLMs. Lo que hay es un task perfectamente diseñado para esta tecnología: input corto + output finito + alto volumen + costo marginal cercano a cero.

Anatomía de un prompt de clasificación

Un prompt bien estructurado para clasificación contable tiene 5 bloques claros. Esto no es opcional: cada bloque suma precisión.

Bloque 1: Rol y contexto

Le decís al LLM quién es y para qué cliente trabaja. Esto activa el conocimiento del modelo sobre normativa y vocabulario contable local.

Eres un contador senior especializado en contabilidad chilena
PCGA / IFRS para PYMEs. Trabajas para una empresa retail con
operación en Santiago. Tu tarea: clasificar transacciones del
extracto bancario contra el plan de cuentas estándar chileno.

Bloque 2: Plan de cuentas (resumido)

Le pasás el subset relevante del plan de cuentas. No le pasás las 800 cuentas — eso aumenta costo y confunde. Le pasás las 40-80 cuentas que cubren el 95% del volumen del cliente.

Plan de cuentas a usar (extracto):
- 1101 Caja
- 1102 Banco BCI cta cte
- 1108 Cuentas por cobrar empleados
- 2101 Proveedores nacionales
- 4101 Ventas afectas
- 5101 Costo de ventas
- 5202 Marketing y publicidad
- 5204 Combustibles y lubricantes
- 5210 Compras menores / gastos generales
- 5301 Comisiones bancarias
...

Bloque 3: Reglas específicas del cliente

Acá metés las políticas internas que el LLM no puede saber por sí solo. Esto es lo que distingue a tu firma.

Reglas obligatorias:
- "PAGO GOOGLE ADS" o "PAGO META" → siempre 5202 Marketing
- "TEF MERPAGO COMISION" → siempre 5301 Comisiones bancarias
- Pagos a "ESSO" o "COPEC" → siempre 5204 Combustibles
- Cualquier transacción con "REEMBOLSO" en el texto → 1108

Bloque 4: Few-shot examples

Le mostrás 3-5 ejemplos resueltos. Esto eleva la precisión de ~85% a ~95-98% sin tocar el modelo. Lo cubrimos en detalle más abajo.

Bloque 5: Output esperado (JSON estricto)

Le pedís un formato exacto. Esto es lo que permite procesar la respuesta automáticamente sin parsear texto libre.

{
  "cuenta": "5210",
  "cuenta_nombre": "Compras menores / gastos generales",
  "confidence": 0.78,
  "justificacion": "Pago a retail Falabella sin contexto adicional. Asumo gasto operativo menor.",
  "necesita_revision": true
}

Few-shot learning: el truco que cambia todo

Few-shot learning es darle al LLM 3-5 ejemplos resueltos antes de pedirle que clasifique uno nuevo. Es la técnica de prompting más rentable que existe para tareas contables.

Sin few-shot (zero-shot):

Clasificá: "PAGO FALABELLA RETAIL 145.000 CLP"

El modelo puede dudar entre "Compras menores", "Activo fijo", "Gasto representación", "Adelanto empleados". Precisión esperada: ~80-85%.

Con few-shot:

Ejemplos de clasificación correcta para este cliente:

Transacción: "PAGO FALABELLA 23/03/2026 89.000 CLP"
Resultado: {"cuenta":"5210","confidence":0.85,"justificacion":"Compra menor de retail, sin contexto de activo fijo"}

Transacción: "PAGO ESSO 14/04/2026 65.000 CLP"
Resultado: {"cuenta":"5204","confidence":0.97,"justificacion":"Combustible, regla automática"}

Transacción: "TRANSF MERCADO LIBRE LIQUIDACION VENTAS 1.245.000 CLP"
Resultado: {"cuenta":"4101","confidence":0.93,"justificacion":"Ingreso por ventas marketplace"}

Ahora clasifica:
Transacción: "PAGO FALABELLA RETAIL 145.000 CLP"

Precisión esperada: ~95-98%. Y el modelo aprende el estilo de tu cliente (formato de fechas, monedas, niveles de detalle en la justificación).

💡 Por qué funciona el few-shot

Los LLMs son muy buenos en "imitar el patrón reciente del contexto". Cuando ves 3 ejemplos resueltos de manera consistente, el modelo replica esa consistencia. No es magia: es probabilidad condicional. La conclusión práctica: invertí 30 minutos en preparar 5 buenos ejemplos por cliente. Vas a recuperar ese tiempo en la primera corrida.

Few-shot vs fine-tuning: ¿cuándo cada uno?

Esta es la pregunta que todo mundo hace. La respuesta corta: empezá siempre con few-shot.

Criterio	Few-shot (en prompt)	Fine-tuning (entrenar modelo)
Costo inicial	$0	$500 - $5.000 USD
Tiempo de implementación	30 minutos	2-4 semanas
Precisión típica	95-98%	97-99%
Cambios al plan de cuentas	Editás el prompt	Re-entrenás el modelo
Requiere data histórica	3-5 ejemplos	500-5.000 ejemplos
Cumplimiento de datos (LGPD)	Más simple	Más complejo
Mantenimiento	Bajo	Medio-alto

Few-shot es la opción correcta para el 95% de las firmas LATAM en 2026. Solo considerá fine-tuning si:

Volúmenes muy altos (>500K transacciones/mes) donde el ahorro marginal por mayor precisión justifica el costo.
Plan de cuentas muy idiosincrático que no se aprende con pocos ejemplos.
Cliente con datos imposibles de enviar a APIs externas (banca, salud, defensa).

⚠️ Cuidado con la promesa de fine-tuning

Muchos proveedores venden fine-tuning como solución universal. La realidad: para clasificación contable, la diferencia entre 96% (few-shot bien hecho) y 98% (fine-tuned) rara vez compensa la complejidad operativa. Empezá con few-shot, medí, y solo entonces decidí si necesitás más.

Diferencias por país: planes de cuentas LATAM

Si trabajás en una firma regional o con clientes multi-país, esto importa. Cada país tiene su propio esquema y el LLM necesita saber cuál usar.

Chile

PCGA / IFRS para PYMEs, regulado por el Colegio de Contadores y la CMF para empresas reguladas.
No hay plan de cuentas único legal, pero hay convenciones muy estandarizadas (1xxx Activo, 2xxx Pasivo, 3xxx Patrimonio, 4xxx Ingresos, 5xxx Gastos).
Cuentas tributarias específicas: PPM, IVA débito/crédito fiscal, retenciones honorarios.

México

Código Agrupador del SAT es obligatorio para CFDI 4.0. Las cuentas deben mapearse a códigos del catálogo SAT.
Estructura por niveles: cuenta → subcuenta → sub-subcuenta.
Cuentas tributarias críticas: IVA acreditable, IVA trasladado, ISR retenido.

Argentina

Resoluciones Técnicas FACPCE (RT 17 sobre todo).
Estructura tradicional 1xxx-5xxx similar a Chile pero con cuentas inflacionarias específicas (ajuste por inflación es obligatorio).
Cuentas tributarias: IVA débito/crédito, percepciones, retenciones Ganancias.

Colombia

PUC (Plan Único de Cuentas) definido por la Superintendencia Financiera/Sociedades.
Estructura de 6 dígitos muy estandarizada (clase, grupo, cuenta, subcuenta).
Cuentas tributarias: IVA descontable, retención en la fuente, ICA.

Cómo manejar esto en el prompt

La regla: un prompt por país, no uno universal. Si intentás cubrir Chile + México + Argentina + Colombia en el mismo prompt, el modelo se confunde y baja precisión.

[Prompt versión Chile]
"Plan de cuentas a usar: chileno PCGA estándar...
Cuenta IVA crédito: 1107
Cuenta IVA débito: 2103
..."

[Prompt versión México]
"Plan de cuentas a usar: catálogo SAT mexicano...
Cuenta IVA acreditable: 118.01
Cuenta IVA trasladado: 208.01
..."

Esto se gestiona fácil con n8n o Make: el workflow elige el prompt según el campo "país" del cliente.

Output JSON: por qué es no-negociable

Pedirle al LLM que devuelva JSON estructurado no es un detalle técnico. Es lo que hace que el sistema sea auditable y procesable.

Mal output (texto libre):

"Esta transacción probablemente corresponde a una compra menor,
quizás a la cuenta 5210, aunque también podría ser 5202 si fuera
marketing. Estoy bastante seguro."

Imposible de procesar automáticamente. Imposible de auditar consistentemente.

Buen output (JSON estricto):

{
  "cuenta": "5210",
  "cuenta_nombre": "Compras menores / gastos generales",
  "confidence": 0.78,
  "justificacion": "Pago a retail Falabella sin contexto adicional",
  "alternativa_secundaria": "5202",
  "necesita_revision": true,
  "reglas_aplicadas": []
}

Este formato te permite:

Filtrar automáticamente lo que va a revisión (confidence < 0.85 + necesita_revision: true).
Guardar un audit trail completo (lo vemos en la Lección 6).
Generar reportes de calidad ("¿qué % de las transacciones de este cliente tienen confidence > 0.9?").
Cumplir con NIA 315 sobre trazabilidad.

🔑 Regla práctica

En todo prompt de clasificación que escribas en tu firma, siempre pedí output JSON con al menos: cuenta, confidence (0 a 1), justificacion breve y necesita_revision (booleano). Estos cuatro campos son el mínimo viable para un workflow auditable.

Lo que NO hace el LLM en este flujo

Para cerrar la lección, recordemos los límites:

No conoce las políticas internas de tu cliente salvo que se las pongas en el prompt.
No valida que la transacción sea legítima. Si hay un fraude de fondo, el LLM lo clasifica igual: lo detecta la auditoría (Módulo 4).
No firma nada. El contador sigue siendo el responsable profesional bajo NIA 240/315/530.
No reemplaza al maestro de proveedores. Si una transacción nueva aparece sin contexto, la respuesta correcta a veces es "revisar humano".

El LLM acelera. El contador decide.

Próximos pasos

En la Lección 5 vamos a aplicar todo esto a un caso real: clasificar 10.000 transacciones bancarias de extremo a extremo. Vas a ver el Excel de input, el prompt completo con ejemplos LATAM, el costo real por corrida, y el output con confidence scores listos para revisión.

💡 Ejercicio opcional

Tomá el plan de cuentas que usás (de tu firma o de un cliente actual). Identificá las 20 cuentas que cubren el 80% de las transacciones operativas. Esa lista es la base de tu primer prompt de clasificación. No necesitás más para empezar a probar.

Bonus: anotá 5 ejemplos de transacciones reales (anonimizadas) con su clasificación correcta. Eso son tus 5 few-shot examples para la próxima lección.

Próxima lección: 05. Caso práctico: clasificar 10.000 transacciones bancarias