Revisión y aprobación de gasto

1. Objetivo

Establecer el procedimiento por el cual la jefatura o el área de finanzas revisa un gasto registrado y resuelve su aprobación o su rechazo, de modo que ningún egreso de la organización se consolide en sus estados financieros sin una decisión expresa de quien tiene atribución para tomarla.

2. Alcance

Aplica a todo gasto operativo registrado en el sistema que se encuentre en estado pendiente: insumos, servicios, arriendos, honorarios y cualquier otro egreso respaldado por un comprobante de proveedor.

No cubre el registro inicial del gasto (ver [[wiki/entities/dispensai/protocolos/FIN-001]]), la custodia del comprobante (ver [[wiki/entities/dispensai/protocolos/FIN-002]]), los aportes de los socios (ver [[wiki/entities/dispensai/protocolos/FIN-004]]) ni el cierre y cotejo del período (ver [[wiki/entities/dispensai/protocolos/FIN-005]]).

Ámbito geográfico: sede social de la organización.

3. Definiciones

• Gasto pendiente: egreso registrado cuyo estado es pendiente. Es el estado inicial y lo fija la base de datos, no la interfaz.
• Aprobación: decisión de que el gasto procede, es imputable a la organización y está suficientemente respaldado. Sólo el gasto aprobado se consolida en el desglose por categoría del período.
• Rechazo: decisión de que el gasto no procede o carece de respaldo suficiente.
• Registrador: persona que creó la fila del gasto. Queda identificada en el registro.
• Aprobador: persona que resuelve. Hoy no queda identificada por el sistema: ver brecha 1 de la §17.
• Segregación de funciones: principio por el cual quien registra un egreso no es quien lo autoriza.

Este protocolo habla de gastos con proveedores. El vocabulario de pago, factura y precio es correcto en esa relación y no debe extenderse a los aportes de los socios, que nunca son precio ni contraprestación.

4. Roles y responsables

Rol	Responsabilidad
Jefatura / finanzas	Revisa el gasto, verifica el respaldo y resuelve aprobación o rechazo
Dirección	Resuelve los gastos que superan el umbral que la organización haya fijado y los casos escalados
Admin financiero	Aporta los antecedentes del gasto y ejecuta las correcciones que se le soliciten
Sistema DispensAI	Mantiene el estado del gasto, restringe la operación al rol de administrador y separa el gasto aprobado del pendiente en la analítica del período

5. Disparador de inicio

Existencia de al menos un gasto en estado pendiente, o llegada de la fecha de revisión periódica que la organización haya fijado para resolver los pendientes acumulados.

6. Requisitos previos

• El gasto está registrado y tiene comprobante custodiado. Un gasto sin respaldo no debe llegar a revisión.
• Quien revisa tiene sesión activa con rol de administrador en el sistema. Sin ese rol, la base de datos rechaza la operación.
• La organización tiene definido, fuera del sistema, quién puede aprobar y a partir de qué monto se requiere la dirección.

7. Entradas

• Gasto registrado en estado pendiente, con su monto, fecha, categoría, sucursal y proveedor.
• Comprobante custodiado.
• Presupuesto vigente de la organización, cuando exista.

8. Procedimiento paso a paso

Paso 1 — Identificación de los pendientes El gasto nace en estado pendiente. El conjunto de estados posibles —pendiente, aprobado, rechazado— y el valor inicial son una restricción de la base de datos, de modo que ningún gasto puede aparecer aprobado por omisión ni tomar un estado inventado.

Paso 2 — Consulta del listado Quien revisa accede al módulo de gastos, filtra por estado y localiza los pendientes. El listado permite además buscar por descripción, proveedor o RUT.

Paso 3 — Revisión del respaldo Quien revisa abre el comprobante asociado al gasto y comprueba que el documento corresponde al gasto, que el emisor es el proveedor declarado y que el monto coincide.

Paso 4 — Verificación de procedencia (solo-humano) Quien revisa determina si el gasto es imputable a la organización, si se ajusta a su objeto y si cabe dentro del presupuesto disponible. El sistema no conoce presupuestos, no tiene topes por categoría y no escala por cuantía: esta comprobación es enteramente humana.

Paso 5 — Decisión Quien revisa aprueba o rechaza el gasto. La operación exige sesión activa, y la política de base de datos sobre la tabla de gastos exige además rol de administrador. Ese control es duro: no depende de que la interfaz esconda el botón ni de que la función del servidor recuerde comprobar el rol.

Paso 6 — Constancia de la decisión (solo-humano) La organización deja constancia de quién aprobó, cuándo y con qué fundamento, y —cuando su procedimiento interno lo exige— de la doble firma entre registrador y aprobador. Esta constancia debe producirse fuera del sistema, porque el sistema no la genera. Ver brechas 1 y 2 de la §17.

Paso 7 — Efecto sobre el período Sólo el gasto aprobado entra en el desglose por categoría de la analítica del período. El pendiente y el aprobado se reportan por separado. La analítica del período está restringida al rol de administrador por una comprobación dentro de la propia función de base de datos, que rechaza la llamada de cualquier otro rol.

Paso 8 — Comunicación del resultado (solo-humano) Quien revisa comunica la aprobación o el rechazo al administrador financiero y, cuando corresponde, al proveedor. El sistema no envía ninguna notificación en este flujo.

9. Puntos de control

Punto	Qué verifica	Cómo	Tipo
Estado inicial	Todo gasto nace pendiente	Valor por omisión en la base de datos	Duro
Estados admitidos	Sólo pendiente, aprobado o rechazado	Restricción de la base de datos sobre la columna de estado	Duro
Atribución para resolver	Sólo un administrador puede cambiar el estado	Política de base de datos sobre la tabla de gastos	Duro
Efecto contable	Sólo el gasto aprobado se consolida por categoría	Filtro por estado en la función de analítica del período	Duro
Acceso a la analítica	Sólo un administrador la consulta	Comprobación de rol dentro de la función de base de datos	Duro
Segregación registrador / aprobador	Quien aprueba no es quien registró	Ver brecha 1 de la §17	Humano
Procedencia y presupuesto	El gasto corresponde y cabe	Juicio de quien revisa	Humano
Aprobación por cuantía	Los montos mayores los resuelve la dirección	Procedimiento interno	Humano

10. Criterios de decisión

Situación	Acción
Comprobante válido, monto coincidente, gasto imputable y dentro de presupuesto	Aprobación
Comprobante ausente o ilegible	Rechazo, con solicitud de respaldo válido
Monto del registro distinto del monto del comprobante	Devolución al registrador para corrección; no se aprueba con discrepancia
Gasto ajeno al objeto de la organización	Rechazo
Gasto sobre el umbral definido por la organización	Escalamiento a dirección antes de resolver
Quien revisa es la misma persona que registró	Escalamiento a un segundo revisor; el sistema no lo impide
Proveedor no habitual o sin antecedentes	Verificación adicional del proveedor antes de resolver

11. Excepciones y escalamiento

• Ausencia de un segundo revisor disponible: dirección autoriza excepcionalmente la revisión por la misma persona que registró, dejando constancia expresa fuera del sistema. Al no existir enforcement, esta constancia es el único control efectivo.
• Gasto urgente que debe pagarse antes de la revisión: dirección autoriza el egreso y el gasto se revisa después; la constancia de la autorización previa se archiva junto al comprobante.
• Discrepancia irreconciliable entre el registro y el comprobante: se rechaza el gasto y se registra uno nuevo con los datos correctos, en lugar de corregir el estado del anterior.
• Reversión de una aprobación: requiere autorización de dirección. El sistema permite volver atrás el estado sin registrar nada, de modo que la constancia externa es obligatoria. Ver brecha 3 de la §17.

12. Registros generados

Registro	Dónde	Quién lo genera
Estado del gasto	Fila del gasto en la base de datos	Acción de cambio de estado
Identidad del registrador	Fila del gasto en la base de datos	Registro inicial del gasto
Separación de gasto aprobado y pendiente en el período	Función de analítica del período	Consulta de la analítica
Constancia de la decisión y de la doble firma	Fuera del sistema	Jefatura / finanzas

El sistema no genera evento ni entrada de auditoría al aprobar o rechazar. Ver brecha 2 de la §17.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Pendientes añejos	Gastos pendientes con más de 48 horas / total de pendientes	Bajo 10 %	Tabla de gastos
Tasa de rechazo	Gastos rechazados / gastos resueltos en el período	Informativo	Tabla de gastos
Respaldo del gasto aprobado	Gastos aprobados con comprobante / gastos aprobados	100 %	Tabla de gastos
Tiempo de resolución	Días entre el registro y la resolución	Bajo 5 días	Tabla de gastos
Segregación efectiva	Aprobaciones resueltas por persona distinta del registrador / aprobaciones	100 %	Constancia externa; no medible por el sistema

El último indicador no puede calcularse desde el sistema mientras siga abierta la brecha 1.

14. Riesgos y controles

Riesgo	Control	Tipo
Auto-aprobación: quien registra aprueba	Procedimiento interno de doble firma y constancia externa. Ver brecha 1	Humano
Aprobación por persona sin atribución	Política de base de datos que exige rol de administrador	Duro
Aprobación sin revisar el comprobante	Revisión visual obligatoria del respaldo	Humano
Gasto improcedente aprobado por desconocimiento del presupuesto	Verificación contra presupuesto vigente	Humano
Reversión silenciosa de una aprobación	Autorización de dirección y constancia externa. Ver brecha 3	Humano
Imposibilidad de acreditar quién aprobó ante una revisión externa	Constancia externa firmada. Ver brechas 1 y 2	Humano
Gasto de cuantía relevante aprobado sin dirección	Umbral definido en el procedimiento interno. Ver brecha 4	Humano

15. Normativa y referencias

Norma	Cláusula	Paso que cubre	Cómo se cubre
Ley 21.595	Modelo de prevención de delitos — controles sobre el manejo de fondos	Pasos 5, 6	La atribución para autorizar está restringida por la base de datos. La segregación de funciones no tiene enforcement: ver brecha 1
ISO 9001:2015	§7.5 Información documentada	Pasos 5, 6	El estado queda persistido con restricción de valores. No hay historial de la decisión: ver brecha 3
ISO 9001:2015	§8.4 Control de los procesos, productos y servicios suministrados externamente	Pasos 3, 4	Verificación del comprobante del proveedor antes de autorizar
ISO 26000	6.6.3 Lucha contra la corrupción	Pasos 5, 6	Doble verificación sostenida por procedimiento humano, no por el sistema: ver brechas 1 y 2
Ley 20.500	Ausencia de fin de lucro — destino de los fondos	Pasos 4, 7	Sólo el gasto aprobado se consolida en el desglose del período

ISO 26000 no es certificable. La cobertura declarada en esta tabla describe qué control ejecuta la organización, no que ese control esté certificado por autoridad alguna. Esta página no constituye asesoría legal.

16. Anexos y formularios vinculados

• [[wiki/entities/dispensai/protocolos/FIN-001]] — Registro de gasto
• [[wiki/entities/dispensai/protocolos/FIN-002]] — Respaldo de comprobantes
• [[wiki/entities/dispensai/protocolos/FIN-005]] — Conciliación administrativa mensual

17. Implementación en el sistema

Lo que ejecuta el sistema:

El estado del gasto es una restricción de base de datos: la columna es obligatoria, su valor por omisión es pendiente y sólo admite pendiente, aprobado o rechazado. Ningún camino de la aplicación puede dejar un gasto en un estado inventado ni saltarse el estado inicial.

La atribución para resolver está restringida en la capa correcta. La acción que cambia el estado sólo comprueba que exista sesión, pero opera con la conexión que respeta las políticas de acceso, y la política de modificación sobre la tabla de gastos exige rol de administrador. Verificado sobre el esquema: las cuatro políticas —lectura, inserción, modificación y borrado— exigen ese rol. Es decir, el control de “sólo un administrador aprueba” es efectivo aunque el código de la aplicación no lo repita.

La aprobación tiene efecto contable verificable: la función de analítica del período separa el monto aprobado del pendiente y restringe el desglose por categoría a los gastos aprobados. Esa función además rechaza la llamada de cualquier rol que no sea administrador, con un error explícito.

Brecha 1 — Sin segregación de funciones ni rastro del aprobador (FIN-003-B1) La acción que cambia el estado no compara al aprobador con el registrador, y la tabla de gastos no tiene columna alguna para el aprobador, la fecha de aprobación ni el motivo de rechazo —verificado sobre las veintiuna columnas del esquema—. Consecuencia: quien registra un gasto puede aprobarlo en la misma sesión, y aun cuando la organización cumpla escrupulosamente la doble firma fuera del sistema, no existe forma de acreditarla desde el sistema. Ante una revisión bajo Ley 21.595, la organización puede mostrar quién registró el gasto, nunca quién autorizó su egreso. Pendiente: agregar columnas de aprobador, fecha de aprobación y motivo, y un guard que rechace la operación cuando el aprobador coincide con el registrador.

Brecha 2 — La aprobación no emite evento ni entrada de auditoría (FIN-003-B2) Ni la acción de cambio de estado ni la de edición del gasto emiten evento del sistema ni entrada en la cadena de auditoría. Es una asimetría notoria: la carga del comprobante sí emite evento, pero la decisión económica —autorizar el uso de fondos de la organización— no deja ninguno. Consecuencia: el momento de la aprobación no es reconstruible, y el registro que ISO 9001 §7.5 pide para demostrar conformidad simplemente no existe. Pendiente: emitir el evento correspondiente y la entrada de auditoría en la aprobación y en el rechazo.

Brecha 3 — El estado es reversible y no hay historial (FIN-003-B3) La acción de edición del gasto acepta el estado dentro de su propio esquema de validación, de modo que un gasto ya aprobado puede volver a pendiente o pasar a rechazado por esa vía, sin que quede constancia del cambio ni del estado anterior. El sistema demuestra que sabe hacerlo mejor: para las órdenes mantiene una tabla de historial de estados con estado anterior, estado nuevo, autor y notas. Ese patrón está disponible en la propia base de datos y no se aplicó a finanzas. Consecuencia: la secuencia de decisiones sobre un gasto no es auditable, y una reversión indebida es indistinguible de una legítima. Pendiente: crear el historial de estados del gasto y retirar el estado del esquema de la acción de edición, para que el único camino de cambio sea la acción de resolución.

Brecha 4 — No existe aprobación por cuantía (FIN-003-B4) No hay umbral de monto, tope por categoría ni escalamiento automático a dirección. La regla “sobre cierto monto resuelve la dirección” sólo puede vivir en el procedimiento humano, y el sistema aprueba un gasto de cualquier magnitud con un clic de cualquier administrador. Consecuencia: el control de autorización proporcional al riesgo económico no existe en el sistema. Pendiente: configurar umbrales por categoría y exigir un segundo aprobador cuando se superen.

Lo que ejecuta la organización fuera del sistema:

El juicio sobre la procedencia del gasto y su encaje en el objeto de la organización. La verificación contra el presupuesto vigente, que el sistema desconoce. La validación de la autenticidad del comprobante. La doble firma entre registrador y aprobador y su constancia, que hoy es el único control efectivo de segregación de funciones. La aprobación por cuantía. La comunicación del resultado al administrador financiero y al proveedor. Y la autorización de cualquier reversión de una aprobación ya otorgada.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-29	Versión inicial. Redactada desde la corrida de evidencia 2026-08-29-FIN del harness de protocolos. Cuatro brechas declaradas. Se verificó que la restricción de rol para aprobar es efectiva en la capa de base de datos.	Jefatura / finanzas