Las 4 brechas ERP en el expediente de pago a proveedores que el SAT sí detecta
- Hugo
- 23 jun
- 6 min de lectura
Las brechas ERP en el expediente de pago a proveedores no son fallas del sistema; son límites de diseño. SAP, Oracle y Dynamics fueron construidos para registrar contabilidad, no para estructurar evidencia de materialidad. Cuando el SAT revisa una operación bajo el artículo 69-B del CFF, esas brechas se vuelven el punto más vulnerable del ciclo de pagos.
Este artículo describe las cuatro específicas que más frecuentemente exponen a las empresas en una auditoría.
Las brechas ERP en el expediente de pago: dónde termina el ERP y dónde empieza el riesgo
El ERP tiene un alcance definido: captura el movimiento financiero, actualiza la contabilidad y genera el comprobante de la transacción. Hasta ahí llega.
El expediente de pago que exige el SAT es otra cosa: es el conjunto de documentos que demuestran que la operación ocurrió en la realidad — que hubo un servicio entregado, una autorización trazable, un CFDI válido, y un complemento de pago que cerró el ciclo fiscal. Esa construcción no es función del ERP.
Nunca lo fue, porque esta diseñado para generar registros financieros y contables, no para contar la historia de esos registros.
Las brechas entre lo que el ERP produce y lo que el expediente requiere son predecibles. Y podemos identificar cuatro.
Brecha 1: La evidencia operativa no vive en el ERP
El ERP registra que se pagó. No registra por qué se pagó ni qué se recibió a cambio.
La evidencia operativa — la constancia de que el servicio fue entregado o el bien fue recibido, llega al equipo de finanzas por correo, por fotografías en WhatsApp, por reportes en carpetas compartidas, por actas de entrega físicas escaneadas. Ninguno de esos elementos entra al ERP de forma estructurada.
Cuando el SAT solicita demostrar la materialidad de una operación, lo primero que pide es evidencia de que el servicio ocurrió. Eso no está en SAP. No está en Oracle. No está en Dynamics. Está disperso en los correos del área que recibió el servicio y en las carpetas de quien lo coordinó.
Esa dispersión es la primera brecha.
Brecha 2: Las autorizaciones internas no quedan registradas de forma trazable
El ERP puede tener flujos de aprobación configurados (que nombra como Workflows). El problema es que muchas empresas no los tienen parametrizados para todos los tipos de pago o no son suficientemente amigables o adaptados a la operación de las empresas, adicional al costo que implica esta adaptación, por eso los equipos los evitan con workarounds cuando hay urgencia: una autorización por correo, una instrucción por chat, un "ya lo vio el director" que nadie documentó formalmente.
El resultado: el pago salió del sistema con registro contable impecable, pero la autorización que lo precedió no existe como evidencia estructurada y trazable.
El SAT, en una revisión de materialidad, puede pedir la cadena de autorizaciones internas de una operación. Si esa cadena solo vive en correos sin vincular al expediente, o simplemente no existe, la empresa no puede demostrar que el proceso de control interno funcionó.
Esa es la segunda brecha y es la más frecuente en empresas con procesos de autorización híbridos entre el ERP y el correo.
Brecha 3: El complemento de pago (REP) no se vincula automáticamente al expediente
El complemento de pago (el CFDI de tipo "P" que emite el proveedor para cerrar el ciclo fiscal ) es el documento que acredita que el pago efectivamente se realizó y en qué condiciones. Sin él, el CFDI de la factura queda abierto fiscalmente y la deducción del gasto queda en riesgo.
El problema no es que el ERP no lo registre. El problema es que el REP generalmente llega por separado, el proveedor lo emite después del pago, lo envía por correo, y alguien en el equipo lo descarga y lo sube a una carpeta. Ese proceso manual no vincula el REP al folio del CFDI original ni al expediente del pago específico.
El resultado: la empresa tiene el REP, pero no puede demostrar de forma inmediata a qué pago corresponde ni si está completo para cada operación. En una revisión del SAT, localizar el REP de un pago específico de hace ocho meses puede tomar horas.
Esta es la tercera brecha, y es la que más directamente afecta la deducibilidad fiscal. Puedes ver el impacto completo en el artículo sobre complemento de pago SAT y deducibilidad.
Brecha 4: La validación del proveedor no ocurre en el momento del pago
El ERP tiene un catálogo de proveedores. Ese catálogo se actualiza periódicamente, o no se actualiza, dependiendo del proceso de cada empresa. Lo que no hace el ERP de forma nativa es consultar en tiempo real si el proveedor está en las listas del artículo 69-B del CFF antes de liberar el pago.
Una empresa puede pagar a un proveedor que fue publicado en las listas negras del SAT el mes anterior sin que nadie en el proceso de pago lo haya detectado. El ERP procesó la transacción con normalidad. El CFDI está timbrado. El pago salió. Y la empresa acaba de deducir una operación con un proveedor cuestionado por el SAT.
Eso es exactamente lo que convierte a una empresa en EDOS (empresa que deduce operaciones simuladas) sin saberlo. El art. 69-B CFF no requiere intención: requiere evidencia. Y la ausencia de validación en el momento del pago es una brecha que el ERP no cierra por diseño.
Para entender las implicaciones de operar con proveedores en listas negras, revisa el artículo sobre listas negras SAT EFOS EDOS.
Cómo Zentral Core cierra estas cuatro brechas
Zentral Core es una plataforma B2B de trazabilidad de pagos a proveedores en México que opera en la capa que el ERP no cubre. Las cuatro brechas descritas tienen solución estructural, no parches manuales:
Brecha 1 → Evidencia operativa:
Zentral Core centraliza la captura de evidencia operativa como parte del flujo de pago. El área que recibe el servicio carga la constancia de entrega directamente en el expediente del pago correspondiente; no en un correo, no en una carpeta compartida.
Brecha 2 → Autorizaciones:
El módulo de autorizaciones de Zentral Core registra cada aprobación con fecha, responsable y nivel jerárquico. Las autorizaciones quedan vinculadas al expediente del pago; no a un hilo de correos.
Brecha 3 → Complemento de pago:
Zentral Core asocia el REP al folio del CFDI original en el mismo expediente. Cuando llega el complemento, el sistema lo vincula automáticamente. El expediente solo se considera cerrado cuando el REP está presente y verificado.
Brecha 4 → Validación del proveedor:
Zentral Core valida al proveedor contra las listas del SAT antes de que el pago avance en el flujo. Si el proveedor tiene un hallazgo, el sistema lo alerta. El pago no avanza hasta que el equipo resuelve la alerta.
El resultado es un expediente de pago que existe como producto natural del proceso, no como tarea de reconstrucción posterior. Para ver cómo se estructura ese proceso de control, consulta el artículo sobre cómo auditar pagos a proveedores.
Preguntas frecuentes sobre brechas ERP y expediente de pago
¿Qué es un expediente de pago completo ante el SAT?
Es el conjunto de documentos que acreditan la trazabilidad de una operación con un proveedor: contrato u orden de compra vigente, evidencia operativa de entrega, CFDI validado, autorizaciones internas trazables, comprobante SPEI, ejecución del pago y complemento de pago (REP) vinculado al folio. La ausencia de cualquiera de estos elementos puede ser suficiente para que el SAT cuestione la materialidad de la operación bajo el art. 69-B CFF.
¿Por qué el ERP no resuelve la materialidad de pagos?
Porque el ERP registra el movimiento contable, no construye el expediente operativo. La evidencia de entrega del servicio, las autorizaciones internas, la vinculación del complemento de pago y la validación del proveedor en tiempo real no son funciones nativas de ningún ERP enterprise en México. Son brechas de diseño, no fallas del sistema.
¿Qué diferencia hay entre un registro contable y un expediente de pago?
El registro contable documenta el asiento en el sistema financiero. El expediente de pago vincula ese asiento con la evidencia operativa que lo originó y lo cierra fiscalmente. El SAT evalúa el expediente. El ERP solo tiene el registro.
¿Qué pasa si mi empresa no puede demostrar la materialidad de una operación?
El SAT puede presumir la inexistencia de la operación bajo el art. 69-B CFF. Las consecuencias incluyen rechazo de la deducción fiscal, rechazo del IVA acreditable, créditos fiscales con actualización y recargos, y multas accesorias. El contribuyente tiene plazo para desvirtuar la presunción, plazo que se vuelve crítico si el expediente hay que reconstruirlo desde cero.
¿Qué es Métrica Cero?
Métrica Cero es el criterio de validación desarrollado por Zentral Core que establece que ningún pago a proveedor debe requerir reconstrucción manual para demostrar su trazabilidad. Si tu equipo necesita más de 60 segundos para localizar el expediente completo de cualquier pago, existe una falla de proceso. Es el único criterio con nombre propio en el mercado mexicano para medir la madurez operativa en trazabilidad de pagos a proveedores.
¿Cuántas de estas cuatro brechas están presentes hoy en el ciclo de pagos de tu empresa?
El diagnóstico de Zentral Core identifica en menos de 5 minutos cuáles están activas y cuál representa el mayor riesgo ante el SAT.
¿Ya leíste el artículo anterior de esta serie?
Comentarios