Una empresa puede emitir cientos de comprobantes fiscales cada mes sin recibir aparentemente ningún error.
Los recibos de nómina se timbran. Los complementos de pago se generan. Las facturas llegan a los clientes. La contabilidad continúa y el sistema parece funcionar correctamente.
Esa aparente normalidad puede generar una falsa seguridad.
Que un comprobante haya sido elaborado por el sistema no significa que la operación administrativa que lo originó esté correctamente identificada, conciliada y documentada. Tampoco significa que la configuración utilizada seguirá superando las validaciones técnicas aplicables.
La Primera Modificación al Anexo 29 de la Resolución Miscelánea Fiscal para 2026, publicada el 17 de julio de 2026, incorporó precisiones específicas para validar los CFDI de tipo nómina y pago. Aunque se trata de una disposición técnica dirigida al proceso de certificación, su efecto práctico interesa directamente a las empresas: los errores de clasificación o configuración pueden impedir que ciertos comprobantes sean certificados correctamente.
El cambio representa una buena oportunidad para revisar algo más importante que el software de facturación: la forma en que la empresa conecta sus ventas, cobros, nómina, bancos y contabilidad.
¿Qué cambió en las validaciones del CFDI?
El Anexo 29 contiene disposiciones complementarias relacionadas con los proveedores de certificación de CFDI y con las validaciones que deben aplicarse durante el proceso de certificación.
La modificación publicada en julio de 2026 precisa dos validaciones adicionales:
-
Cuando el atributo
TipoDeComprobantesea "N", debe existir el Complemento Nómina. -
Cuando el atributo
TipoDeComprobantesea "P", debe existir el Complemento para recepción de pagos.
En términos sencillos, un comprobante identificado como nómina debe incluir la información específica que corresponde a un recibo de nómina. Del mismo modo, un comprobante identificado como pago debe incorporar el complemento que documenta la recepción del pago.
El propio Anexo también señala reglas de consistencia para determinados tipos de comprobante. Por ejemplo, establece que en los comprobantes de tipo traslado, pago o nómina debe omitirse el atributo relativo a las condiciones de pago; y que en ciertos casos tampoco deben incluirse impuestos, forma de pago o método de pago.
Una precisión importante: la modificación no crea por sí sola toda la obligación
Sería incorrecto afirmar que, antes del 17 de julio de 2026, los recibos de nómina podían emitirse válidamente sin el complemento correspondiente o que los CFDI de pago no necesitaban documentar la recepción de pagos.
El SAT ya contaba con estructuras, guías de llenado y complementos específicos para estos comprobantes. La modificación al Anexo 29 precisa y refuerza la validación dentro del proceso de certificación.
La diferencia práctica es relevante: una inconsistencia que quizá antes dependía de otras validaciones del sistema ahora se encuentra expresamente asociada al tipo de comprobante declarado.
"¿La información que genera nuestro sistema refleja correctamente lo que sucedió en la operación?"
— La pregunta útil que toda PyME debería hacerse.
El problema no siempre está en el SAT ni en el proveedor de facturación
Cuando un CFDI es rechazado, muchas empresas atribuyen el problema al portal, al proveedor de certificación o al programa contable.
En algunos casos puede existir una incidencia tecnológica. Sin embargo, con frecuencia el error comenzó antes, dentro de la propia operación. Puede originarse en:
- Una venta registrada como pagada cuando realmente se otorgó crédito.
- Un cobro recibido que no fue identificado oportunamente.
- Un sistema que conserva parámetros de ejercicios anteriores.
- Una nómina calculada con información laboral incompleta.
- Una persona que captura datos sin conocer la naturaleza fiscal de la operación.
- Falta de comunicación entre ventas, cobranza, recursos humanos y contabilidad.
- Diferencias entre el sistema administrativo, el estado de cuenta bancario y la contabilidad.
- Un proveedor tecnológico que actualiza el sistema, pero no revisa la configuración particular de la empresa.
Las nuevas validaciones hacen más visible una realidad: la factura electrónica es el resultado de un proceso administrativo. Cuando el proceso está mal diseñado, el error termina apareciendo en el XML.