Flujo de aprobación contable: guía completa 2026
Cómo diseñar un flujo de aprobación contable. Reglas, plazos, escalado, aprobadores externos. Ejemplos reales y checklist.
Qué aprenderá en este artículo
- Los cuatro componentes obligatorios de todo flujo de aprobación
- Fallos típicos de la aprobación manual por correo electrónico y chat
- La diferencia entre un sistema basado en reglas y un enrutamiento ad-hoc
- Un escenario real de una factura superior a 2.000 EUR desde la recepción hasta la aprobación
- Lo que SmartDocto realmente puede y no puede hacer en este ámbito
Los despachos contables aprueban facturas mediante hilos de correo electrónico, capturas de WhatsApp y consentimiento verbal, y al cierre del ejercicio dedican horas a recopilar pruebas para el auditor. El trabajo permanece invisible hasta que algo se rompe: un vencimiento no atendido, un recargo por mora o un auditor que pregunta quién autorizó exactamente una factura de 80.000 EUR en marzo. Un flujo de aprobación contable es un sistema basado en reglas que decide quién aprueba qué, en qué orden, con qué plazo y qué sucede cuando el plazo expira.
¿Qué es un flujo de aprobación contable?
Un flujo de aprobación contable es el sistema basado en reglas que lleva un documento desde su llegada hasta una decisión vinculante registrada (aprobar, rechazar o devolver para corrección). Sustituye el enrutamiento improvisado por correo o chat por reglas explícitas y auditables. Todo flujo dispone de cuatro componentes obligatorios.
Activador
La condición que inicia el flujo. Habitualmente un tipo de documento combinado con un umbral por importe o una condición de campo (por ejemplo, facturas de proveedor superiores a 50.000 EUR). Sin un activador explícito, el sistema no puede decidir si un documento requiere aprobación.
Regla de enrutamiento
La regla que decide quién recibe la solicitud. El enrutamiento asigna cada documento aprobado a uno o varios aprobadores, opcionalmente por bandas de importe, centros de coste o grupos de proveedores. Las reglas correctas son deterministas: el mismo dato de entrada produce siempre la misma lista de aprobadores.
Plazo y recordatorios
Cada solicitud lleva un plazo (cuándo se espera la decisión) y una cadencia de recordatorios (cuándo se avisa al aprobador). Los recordatorios se configuran por conjunto de reglas, normalmente cada 24 horas hasta alcanzar un máximo, momento en el que cesan y la solicitud queda a la espera del escalado.
Vía de escalado
Qué ocurre cuando el plazo se aproxima y el responsable no ha actuado. Un objetivo de escalado definido recibe el traspaso para que la solicitud nunca quede bloqueada. Los buenos sistemas convierten el escalado en una reasignación a una persona, no en una aprobación silenciosa.
Por qué falla la aprobación manual
La aprobación por correo y chat funciona a escala pequeña y se rompe en silencio cuando crece el volumen. A continuación se describen los seis modos de fallo que los equipos financieros reportan con más frecuencia al abandonar el proceso manual.
Sin pista de auditoría
Las capturas de WhatsApp y los correos reenviados no constituyen evidencia contable duradera. Cuando un auditor pregunta quién aprobó una factura concreta y en qué momento, una respuesta reconstruida de memoria no es defendible, y el historial se marcha de la empresa con cada empleado que se va.
Punto único de fallo
Cuando la única persona que aprueba facturas por encima de cierto umbral se toma dos semanas de vacaciones, la cola se detiene. No hay reasignación automática, los vencimientos se incumplen y nadie recibe aviso hasta que un proveedor reclama por teléfono.
Plazos de pago incumplidos
Sin un plazo vinculado a cada solicitud, las facturas flotan en bandejas personales hasta que el proveedor insiste. Los pagos tardíos generan recargos al amparo de la normativa europea sobre morosidad, pero rara vez se imputa ese coste al proceso de aprobación.
Reglas inconsistentes
Sin un conjunto de reglas escrito, la política vive en la cabeza de un director financiero. El umbral para la firma del CFO y la regla de aprobación entre centros de coste varían según a quién se pregunte, y los nuevos incorporados pasan semanas aprendiendo reglas informales.
Cuello de botella al cierre de mes
La aprobación manual escala linealmente con el volumen. En el cierre mensual, cuando se dispara la entrada de facturas y los asientos deben quedar contabilizados a plazo, la cola de aprobación se convierte en el factor limitante. El equipo trabaja hasta tarde y aumentan los errores.
Sin visibilidad de plazos
Un director financiero que quiera saber cuántas facturas siguen pendientes de aprobación, y desde hace cuánto, no dispone de una vista central. La información reside en bandejas individuales, así que los atascos solo aparecen cuando ya han causado daño.
Aprobación manual frente a basada en reglas
La tabla siguiente contrasta un proceso típico por correo y chat con un flujo basado en reglas. Cada fila refleja capacidades que SmartDocto tiene realmente en producción; se han retirado las filas que exagerarían el producto.
Manual (correo/chat)
-
Activador
Una persona decide reenviar el documento.
-
Enrutamiento
Quien esté en línea o quien el remitente recuerde.
-
Plazo
Implícito, inferido por el seguimiento del proveedor.
-
Pista de auditoría
Parcial. Archivo de correo y fragmentos de chat, difíciles de reconstruir.
-
Escalado
Persecución manual por el solicitante, normalmente tras la queja del proveedor.
-
Partes externas
Reenviar el correo y confiar en la respuesta.
Flujo basado en reglas
-
Activador
El tipo de documento y las condiciones de campo enrutan automáticamente.
-
Enrutamiento
Conjunto de reglas definido por regla de procesamiento, determinista por documento.
-
Plazo
dueAt explícito con cadencia de recordatorios configurable.
-
Pista de auditoría
Registro de decisiones por solicitud con acción, usuario, sello temporal y motivo.
-
Escalado
Reasignación automática al objetivo de escalado configurado.
-
Partes externas
Rol específico de aprobador externo con cuenta de usuario completa.
Cómo aborda SmartDocto los flujos de aprobación
SmartDocto es una plataforma de IA para despachos contables y equipos financieros en la UE. El motor de aprobación decide quién revisa cada documento, con qué plazo y qué sucede cuando expira. Las capacidades siguientes están verificadas contra el esquema del producto.
Base
Un conjunto de reglas por regla de procesamiento
Cada regla (plantilla × modelo de IA) tiene exactamente un conjunto de aprobación. El esquema lo impone con una restricción única, el enrutamiento se mantiene determinista.
Validaciones GATE
Condiciones configurables rechazan automáticamente el documento al violar reglas de negocio (CIF/NIF ausente, proveedor fuera de la lista). GATE solo puede rechazar, nunca aprobar de forma automática.
Cadencia de recordatorios
Intervalo configurable (de 1 a 720 h, 24 por defecto) y número máximo de recordatorios (de 0 a 10, 3 por defecto). Se puede desactivar.
Objetivo de escalado con reasignación de respaldo
Al incumplir el plazo, la solicitud se reasigna al objetivo de escalado. Si no está configurado, recae en el primer Owner, Admin o Approver disponible. Las solicitudes nunca quedan bloqueadas.
Acciones avanzadas
Pausa AWAITING_INFO
El aprobador pausa la solicitud y pide información a quien la cargó. El plazo original se preserva en originalDueAt y el flujo se reanuda con la respuesta. La pausa tiene su propio tiempo límite.
Devolución para corrección
El aprobador devuelve el documento con motivo obligatorio (impuesto a nivel de API). Estado SENT_BACK, el historial continúa sin reiniciarse.
Delegación
El responsable actual traspasa voluntariamente la solicitud a otro aprobador (acción DELEGATED). Manual, a diferencia del escalado, que es automático. El responsable original permanece en el historial.
Aprobación paralela con varios aprobadores
Varias subreglas dentro de un mismo conjunto generan solicitudes paralelas. Caso típico: firma independiente del jefe y del responsable del centro de coste. La secuencial de varios pasos se resuelve con reglas separadas.
Aprobadores externos con cuentas completas
El rol EXTERNAL_APPROVER permite que clientes y asesores externos aprueben mediante invitación de equipo. Cuentas completas, no enlaces de un solo uso, así la pista de auditoría conserva una identidad persistente.
- No existe traspaso de propiedad de la aprobación fuera de la delegación (solo el responsable actual puede ceder la solicitud).
- No hay aprobación automática basada en puntuaciones de confianza de IA.
- No se admite la cadena secuencial de N aprobadores dentro de un único conjunto de reglas.
Un flujo de trabajo real, paso a paso
El recorrido siguiente utiliza valores genéricos que reflejan el comportamiento real del producto. El escenario es una factura de proveedor que llega por correo electrónico, encuentra una única regla de procesamiento y avanza por el motor de aprobación de principio a fin. Los importes están en EUR; en mercados de Latinoamérica el mismo recorrido aplica con la moneda local.
-
01
El proveedor envía la factura por correo
El proveedor remite la factura a facturas@empresa-ejemplo.com, una dirección supervisada por el canal de carga EMAIL. SmartDocto recupera el adjunto, lo somete a análisis antivirus y lo encola para su procesamiento.
-
02
La extracción se ejecuta contra la plantilla
El documento se identifica como factura de proveedor y se extrae contra la plantilla configurada. Los campos de cabecera y las líneas de detalle se procesan con puntuaciones de confianza por campo.
-
03
La regla de procesamiento coincide y activa el conjunto de reglas
La regla de procesamiento de facturas de proveedor coincide y su único ApprovalRuleset se carga automáticamente. La restricción única evita cualquier ambigüedad sobre qué conjunto aplica.
-
04
La validación GATE pasa
Las validaciones GATE se ejecutan antes de crear la solicitud. El CIF/NIF se contrasta con la lista de proveedores y el total contra el límite del proveedor. Un GATE fallido habría rechazado automáticamente la factura.
-
05
Se crea la ApprovalRequest con sus plazos
Se crea una solicitud con el responsable del centro de coste como asignatario, dueAt en T+72 horas y escalationDueAt en T+24 horas. El responsable recibe la notificación por mensaje en la aplicación y por correo electrónico.
-
06
El recordatorio se dispara antes del escalado
En T+24 horas, sin acción del responsable, se envía el recordatorio número 1 según la cadencia configurada. El recordatorio se repite en el intervalo configurado hasta alcanzar el máximo permitido.
-
07
El traspaso de escalado al aprobador de respaldo
Cuando se alcanza escalationDueAt sin decisión, el estado pasa a ESCALATED y la solicitud se reasigna al objetivo de escalado configurado. El traspaso es una reasignación humana explícita, nunca una aprobación automática.
-
08
El aprobador de respaldo decide y se ejecuta la integración de salida
El destinatario del escalado revisa y aprueba. El estado pasa a APPROVED, el historial de aprobaciones queda sellado y el documento continúa hacia la integración de salida con el ERP o el sistema contable.
Escenarios de aprobación multinivel
La aprobación multinivel tiene dos lecturas. La paralela enruta el mismo documento a varias personas que deciden de forma independiente, y la solicitud se cierra cuando todas han decidido. La secuencial enruta primero a la persona A y, solo tras su aprobación, a la persona B. SmartDocto admite de forma nativa la paralela; la secuencial dentro de un mismo conjunto de reglas no se admite, y la forma recomendada de modelarla son reglas de procesamiento separadas con enrutamiento por umbral.
Patrón de aprobación paralela
Dentro de un mismo ApprovalRuleset, varias subreglas pueden coincidir sobre el mismo documento y cada una genera su propia ApprovalRequest. El uso clásico es la firma independiente del jefe de departamento y del responsable del centro de coste. El documento se considera totalmente aprobado cuando todas las solicitudes paralelas se cierran.
Patrón de enrutamiento por umbral
Para una aprobación secuencial por bandas de importe, configure reglas de procesamiento separadas por banda. Las facturas inferiores a 50.000 EUR coinciden con la regla A y se enrutan al director financiero; las facturas iguales o superiores a 50.000 EUR coinciden con la regla B y se enrutan al CFO. La secuencia vive en la lógica de enrutamiento, no dentro de un único conjunto de reglas.
Plazos y comportamiento del escalado
SmartDocto configura plazos de aprobación, no acuerdos contractuales de nivel de servicio. El comportamiento que se describe a continuación detalla qué sucede cuando un plazo expira, formulado como preguntas concretas para que las reglas resulten inequívocas.
¿Qué ocurre cuando un aprobador no atiende el primer recordatorio?
El recordatorio número 2 se envía en el siguiente intervalo reminderIntervalHours, hasta el tope configurado en maxReminders (3 por defecto). Tras alcanzar el tope, los recordatorios se detienen y la solicitud avanza hacia su plazo de escalado sin más avisos.
¿Qué sucede cuando expira el plazo de escalado?
El estado pasa a ESCALATED y la solicitud se reasigna al escalationTargetUserId configurado. No hay aprobación automática. El escalado es siempre un traspaso a una persona, registrado en el historial de aprobaciones con sello temporal y destinatario.
¿Y si no hay objetivo de escalado configurado?
SmartDocto reasigna la solicitud al primer Owner, Admin o Approver disponible. La misma reasignación de respaldo se aplica cuando el objetivo configurado está inactivo. Las solicitudes nunca quedan bloqueadas a la espera de un usuario que no puede recibirlas.
¿Qué sucede cuando expira el plazo final dueAt sin decisión?
El estado pasa a ESCALATED. El modelo de datos incluye un estado EXPIRED, pero el proceso de vencimiento no lo produce en la práctica; siempre genera un traspaso de escalado. EXPIRED queda reservado para un uso futuro.
SmartDocto no aprueba documentos de forma automática cuando un plazo expira, ni cuando la confianza de la IA alcanza cualquier umbral. Cada aprobación exige una decisión explícita de una persona aprobadora, o bien un rechazo automático GATE sobre una condición fallida. Una aprobación silenciosa invalidaría la pista de auditoría.
Pista de auditoría y cumplimiento
Cada solicitud de aprobación mantiene un registro completo en ApprovalHistory: acción, usuario, estado previo y nuevo, decisión, motivo, metadatos, dirección IP, agente de usuario y marca temporal. El historial es de solo adición y sobrevive a cualquier cambio en el documento subyacente.
En España, este enfoque encaja con las obligaciones del RGPD y con la trazabilidad esperada por SII y Verifactu. En Latinoamérica, la misma evidencia respalda los requisitos de CFDI en México, AFIP en Argentina y DIAN en Colombia. Un auditor puede reconstruir la cadena completa de decisiones.
La pista de auditoría cubre las exigencias probatorias de marcos como ISO 27001, SOC 2 y GoBD: registro de decisiones inmutable, atribución por usuario, transiciones de estado con marca temporal, trazabilidad de metadatos.
Preguntas frecuentes
¿Cómo configuro un flujo de aprobación de facturas?
¿Qué sucede si el aprobador no decide a tiempo?
¿Puede aprobar facturas alguien externo a la empresa?
¿SmartDocto aprueba automáticamente cuando vence el plazo?
¿Cuántos niveles de aprobación admite SmartDocto?
¿Qué significa AWAITING_INFO en el flujo de aprobación?
Un flujo de aprobación contable es el puente entre los datos extraídos y un asiento contable registrado. El diseño correcto captura quién aprobó qué, con qué plazo y por qué motivo, sin atajos silenciosos que minen la pista de auditoría. El piloto es la vía más rápida para probar reglas, plazos y traspasos de escalado contra su propia mezcla de facturas. ¿Ha detectado un error en este artículo? Escriba a info@smartdocto.com.