Registro de gasto

1. Objetivo

Establecer el procedimiento para que el administrador financiero registre cada gasto de la organización con respaldo documental verificable, asegurando que ningún egreso quede sin trazabilidad antes de recibir aprobación.

2. Alcance

Aplica a todos los gastos operativos de la organización: insumos, servicios, arriendos, honorarios y cualquier otro egreso que requiera comprobante. No aplica a los aportes de socios (ver [[FIN-004]]) ni a la conciliación mensual (ver [[FIN-005]]).

Ámbito geográfico: sede social de la organización. El registro se realiza en el sistema DispensAI.

3. Definiciones

• Gasto: egreso de fondos de la organización respaldado por un comprobante tributario o recibo.
• Comprobante: boleta, factura electrónica, recibo o cualquier documento que acredite la transacción con el proveedor.
• Admin financiero: persona con rol admin en el sistema habilitada para registrar y aprobar gastos.
• OCR de comprobante: análisis automático por modelo de lenguaje (GPT-4o) que extrae datos del comprobante digital (proveedor, RUT, monto, IVA, fecha).

4. Roles y responsables

Rol	Responsabilidad
Admin financiero	Registra el gasto y adjunta el comprobante
Jefatura / dirección	Revisa y aprueba o rechaza el gasto (paso solo-humano)
Sistema DispensAI	Valida el formulario, almacena el comprobante, emite evento ISO cuando hay OCR

5. Disparador de inicio

Recepción de un comprobante de gasto (físico o digital) por parte del administrador financiero, o detección de un egreso que requiere registro.

6. Requisitos previos

• El admin financiero tiene sesión activa en DispensAI con rol admin.
• Las categorías de gasto están configuradas en el sistema (tabla expense_categories).

7. Entradas

• Comprobante del gasto (físico o archivo digital: imagen, PDF).
• Datos del proveedor (nombre, RUT, dirección) si no se obtienen por OCR.
• Monto, fecha y categoría del gasto.

8. Procedimiento paso a paso

Paso 1 — Acceso al módulo de gastos El admin financiero accede a /admin/expenses. El sistema muestra el listado de gastos existentes con filtros por fecha, categoría y estado.

Paso 2 — Inicio del registro El admin selecciona la opción de registrar un nuevo gasto.

Paso 3 — Carga del comprobante (opcional pero recomendada) Si existe comprobante digital, el admin lo adjunta al formulario. El sistema envía el archivo a /api/analyze-expense-receipt, que:

• Verifica que el usuario tiene rol admin.
• Aplica rate-limit (30 análisis/hora por admin).
• Sube el archivo a R2 y obtiene la URL.
• Invoca GPT-4o para extraer: nombre del proveedor, RUT del proveedor, dirección, monto total, IVA, monto neto, número de documento, fecha de emisión, método de pago.
• Popula los campos del formulario con los datos extraídos.

Si el análisis falla, el sistema notifica al admin y permite completar los campos manualmente.

Paso 4 — Completar datos del formulario El admin verifica o completa: descripción (mínimo 3 caracteres), monto (mayor o igual a 0), fecha (formato YYYY-MM-DD), categoría, sucursal y datos del proveedor.

Paso 5 — Registro en el sistema createExpense() valida el formulario (Zod), verifica la sesión del usuario y ejecuta INSERT en la tabla expenses con:

• status = 'pending'
• created_by_user_id = user.id
• receipt_url (si hubo carga de comprobante)

Si el registro ocurrió vía OCR, el sistema emite el evento ISO expense_created.

Paso 6 — Revisión por la jefatura (paso solo-humano) La jefatura o dirección revisa el gasto registrado en /admin/expenses. El juicio sobre la validez del comprobante y la procedencia del gasto se ejerce fuera del sistema.

Paso 7 — Aprobación o rechazo Un admin (que puede ser el mismo registrador — ver §17) actualiza el campo status a 'approved' o 'rejected' mediante updateExpense().

9. Puntos de control

Punto	Qué verifica	Cómo
Validación de formulario	Formato y completitud de los campos	Zod en createExpense()
Autenticación	Usuario con sesión activa	createClient() + guard if (!user)
Guard de OCR	Solo admins pueden usar el análisis IA	Check profile.role !== 'admin' en la API route
Status de gasto	Flujo pending → approved / rejected	Campo status en tabla expenses

10. Criterios de decisión

Situación	Acción
Comprobante legible y monto concordante	Aprobación del gasto
Comprobante ilegible o ausente	Rechazo con solicitud de comprobante válido
Monto no coincide con comprobante	Corrección o rechazo
Proveedor no habitual	Revisión adicional antes de aprobación

11. Excepciones y escalamiento

• Comprobante extraviado: el administrador financiero documenta la situación y escala a dirección para resolución.
• Gasto urgente sin comprobante inmediato: dirección puede autorizar excepcionalmente con registro posterior del respaldo.
• Monto superior al umbral habitual: requiere aprobación de dirección independientemente de quien registró.

12. Registros generados

Registro	Dónde	Quién lo genera
Fila en expenses	Base de datos del tenant	createExpense()
Comprobante binario	R2 (object storage) + expenses.receipt_url	API route
Evento ISO expense_created	iso_system_events	Solo si hay OCR (/api/analyze-expense-receipt)
Evento ISO expense_receipt_analysis_failed	iso_system_events	Solo si el análisis falla

13. Indicadores

• % de gastos con comprobante adjunto (receipt_url IS NOT NULL).
• % de gastos en estado pending con más de 48 horas sin aprobación.
• % de análisis OCR exitosos vs. fallidos.
• Monto total de gastos por categoría y por período.

14. Riesgos y controles

Riesgo	Probabilidad	Impacto	Control
Gasto registrado sin comprobante	Media	Alto	Campo receipt_url visible; política de rechazo sin respaldo
Auto-aprobación (quien registra = quien aprueba)	Alta	Alto	Control solo-humano (ver brecha §17)
Análisis OCR incorrecto (monto o RUT equivocado)	Media	Medio	El admin verifica los campos antes de guardar
Pérdida del comprobante digital en R2	Baja	Alto	R2 con redundancia; backup periódico

15. Normativa y referencias

Norma	Cláusula	Paso que cubre	Evidencia
ISO 9001:2015	§7.5 Información documentada	Paso 5 — registro con respaldo	FIN-001-E02, FIN-001-E07
ISO 9001:2015	§7.1.1 Recursos	Paso 2 — gestión de costos	FIN-001-E11
Ley 21.595	Modelo de prevención de delitos	Paso 6, Paso 7 — doble verificación	FIN-001-E06 (brecha)
ISO 26000	6.6.3 Lucha contra la corrupción	Paso 7 — aprobación	FIN-001-E06 (brecha)

16. Anexos y formularios vinculados

• [[wiki/entities/dispensai/protocolos/FIN-002]] — Respaldo de comprobantes
• [[wiki/entities/dispensai/protocolos/FIN-003]] — Revisión y aprobación de gasto
• [[wiki/entities/dispensai/protocolos/FIN-005]] — Conciliación administrativa mensual

17. Implementación en el sistema

Lo que ejecuta el sistema:

createExpense() (dispensai/app/actions/expenses.ts) valida el formulario con Zod y persiste el gasto en la tabla expenses con status='pending'. Cuando el registro se realiza con comprobante digital, la API route /api/analyze-expense-receipt invoca GPT-4o, sube el archivo a R2 y emite el evento ISO expense_created.

getExpenses() recupera los gastos con JOIN a expense_categories, branches y profiles (nombre del registrador). /admin/finanzas agrega los gastos con los aportes en un resumen financiero.

Brecha 1 — Sin trazabilidad de auditoría en registro manual (FIN-001-B1) createExpense() y updateExpense() no llaman logISOSystemEvent ni logAudit. Un gasto registrado manualmente (sin OCR) no genera evento ISO ni entrada en audit_logs. Solo los gastos registrados vía la API de OCR tienen evento. Consecuencia: ante una revisión de ISO 9001 §7.5, el sistema no puede probar cuándo ni quién registró los gastos manuales a través de un log sellado; solo existe la fila en la base de datos. Pending: agregar logISOSystemEvent('expense_created', ...) y logAudit(...) en createExpense() y en la aprobación.

Brecha 2 — Sin segregación de funciones para aprobación (FIN-001-B2) updateExpense() no verifica que el aprobador sea distinto del registrador. Cualquier admin puede registrar un gasto y aprobarlo en la misma sesión sin que el sistema lo impida. Consecuencia: el control sobre el manejo de fondos que exige Ley 21.595 (modelo de prevención) no tiene enforcement en código. El procedimiento de doble verificación es solo-humano y no deja traza. Pending: implementar un campo approved_by_user_id y una server action de aprobación con guard que rechace si approved_by === created_by.

Lo que ejecuta la organización fuera del sistema: La revisión física del comprobante (autenticidad, legibilidad), el juicio sobre la procedencia del gasto, la comunicación del rechazo al proveedor o al solicitante, y la doble firma entre registrador y aprobador cuando la organización lo exige internamente.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial. Redactada desde la corrida de evidencia 2026-08-28-FIN del harness de protocolos. Dos brechas declaradas.	Admin financiero
1.1	2026-08-29	Verificación de brechas: confirmado que createExpense y updateExpense no llaman logISOSystemEvent ni logAudit (grep sobre expenses.ts). Brechas ya documentadas correctamente en v1.0. Estado ascendido a Vigente.	Harness dispensai-protocolos