CFDI40103: “El campo FormaPago no cumple con el patrón correspondiente” — Error CFDI 4.0 México

Si al timbrar un CFDI 4.0 te has encontrado con este mensaje:

CFDI40103 El campo FormaPago no cumple con el patrón correspondiente

el problema está, casi sin excepción, en cómo tu sistema (o tu ERP) está mandando el atributo FormaPago en el nodo Comprobante del XML. Este error pertenece a la matriz de validaciones del Anexo 20 del SAT y se dispara cuando el valor enviado no coincide exactamente con una clave válida del catálogo c_FormaPago.

Contenidos

Qué exige realmente el patrón
Cómo diagnosticarlo en tu XML
Casos especiales: FormaPago=”99” y pagos combinados
FormaPago no se valida sola: su relación con MetodoPago
Revisión en el código si generas el XML por software
Verificación antes de timbrar

Qué exige realmente el patrón

El SAT valida FormaPago contra una expresión regular que solo acepta dos dígitos numéricos correspondientes a una clave del catálogo oficial. Los valores más comunes son:

Clave	Descripción
`01`	Efectivo
`02`	Cheque nominativo
`03`	Transferencia electrónica de fondos
`04`	Tarjeta de crédito
`28`	Tarjeta de débito
`99`	Por definir

El error CFDI40103 casi siempre viene de uno de estos tres motivos:

Se manda la clave sin el cero inicial (1 en vez de 01) — el error número uno con diferencia. Muchos ERPs guardan el método de pago como entero en base de datos, y al concatenarlo al XML se pierde el cero a la izquierda.
Se manda un espacio, salto de línea o carácter invisible al final del valor (típico al copiar/pegar configuraciones desde Excel).
Se usa una clave que no existe en el catálogo c_FormaPago vigente — si tu ERP o tu PAC tienen un catálogo local desactualizado, es posible que valides contra claves que ya no forman parte del catálogo oficial actual, aunque el formato de dos dígitos sea correcto.

Este error es primo directo de otros errores de “patrón no cumplido” del Anexo 20, como el ya conocido CFDI33139 (campo NumRegIdTrib) — en ambos casos, el SAT está validando el formato exacto de un atributo contra una expresión regular, así que la primera sospecha siempre debe ser un problema de formato, no de contenido.

Cómo diagnosticarlo en tu XML

Abre el XML que estás intentando timbrar y busca el atributo directamente en el nodo raíz Comprobante:

<cfdi:Comprobante ... FormaPago="1" MetodoPago="PUE" ... >

Si ves FormaPago="1" en vez de FormaPago="01", ya tienes la causa. Corrígelo a dos dígitos:

<cfdi:Comprobante ... FormaPago="01" MetodoPago="PUE" ... >

Si el valor ya tiene dos dígitos y sigue fallando, revisa con un editor hexadecimal o un cat -A archivo.xml si hay caracteres invisibles:

grep -o 'FormaPago="[^"]*"' factura.xml | cat -A

Cualquier $ que no esté justo después de las comillas de cierre, o un ^I (tabulador) dentro del valor, es la señal de que hay basura invisible metida en el atributo.

Casos especiales: FormaPago=”99” y pagos combinados

Si el pago se realiza con más de una forma de pago (por ejemplo, parte en efectivo y parte con tarjeta), no debes concatenar ambas claves en FormaPago. El campo solo admite una clave. Para pagos mixtos en una sola exhibición (MetodoPago="PUE"), la práctica más extendida es usar FormaPago="99" (Por definir).

Importante para no confundir dos mecanismos distintos: el Complemento para Recepción de Pagos (REP) no es el lugar para detallar un pago mixto de una factura PUE — el REP es un CFDI de tipo “P” específico para el método de pago PPD (pago en parcialidades o diferido), donde se van registrando los abonos sucesivos contra un comprobante emitido previamente con saldo pendiente. Si tu operación es PUE con pago combinado en el momento, la clave 99 en FormaPago es la solución del error de validación; el desglose de cómo se compuso el pago, si tu negocio necesita conservarlo, es información interna de control, no un campo obligatorio del CFDI para ese escenario.

FormaPago no se valida sola: su relación con MetodoPago

Un matiz que conviene tener claro porque afecta directamente a cuándo puedes o no rellenar FormaPago con una clave “cerrada”: el atributo MetodoPago (que indica si el pago es PUE, Pago en Una sola Exhibición, o PPD, Pago en Parcialidades o Diferido) condiciona qué se espera en FormaPago.

Con MetodoPago="PUE", FormaPago debe reflejar la forma de pago real en el momento de la operación (o 99 si es mixta o no se conoce en el momento de timbrar).
Con MetodoPago="PPD", es práctica común usar FormaPago="99" en el comprobante original, ya que la forma de pago real se registrará en cada Complemento de Recepción de Pagos (REP) conforme se vayan liquidando los abonos — ahí es donde el REP sí entra en juego correctamente.

Confundir estos dos flujos (PUE vs PPD) es otra fuente frecuente de errores de validación relacionados con FormaPago, aunque el mensaje de error que veas sea exactamente el mismo CFDI40103.

Revisión en el código si generas el XML por software

Si generas los CFDI mediante tu propio ERP o una librería (facturación programática), el fix suele ser tan simple como forzar el padding del valor antes de insertarlo en el XML:

forma_pago = str(codigo_forma_pago).zfill(2)

$formaPago = str_pad($codigoFormaPago, 2, '0', STR_PAD_LEFT);

Esto asegura que un 1 guardado como entero en tu base de datos siempre llegue como "01" al comprobante, sin depender de que quien captura el dato recuerde escribir el cero.

Verificación antes de timbrar

Antes de reenviar al PAC, valida el XML localmente contra el catálogo oficial vigente. El SAT publica el catálogo c_FormaPago actualizado en su portal — si tu ERP tiene una versión de catálogos desactualizada, puedes estar validando contra claves que ya no existen en la versión vigente de CFDI 4.0, lo cual produce el mismo error CFDI40103 aunque el formato del valor sea correcto.

Un checklist rápido antes de reintentar:

El valor de FormaPago tiene exactamente 2 caracteres numéricos
No hay espacios ni saltos de línea alrededor del valor
La clave existe en el catálogo c_FormaPago vigente de CFDI 4.0
Si el pago es mixto, se usó 99 y no una concatenación de claves
El catálogo local de tu ERP/PAC está actualizado a la versión más reciente publicada por el SAT

Con estos cinco puntos cubiertos, el CFDI40103 desaparece en prácticamente todos los casos. Si después de esto el error persiste, vale la pena timbrar el mismo XML con un segundo PAC de prueba — en contadas ocasiones el problema no está en tu XML sino en una validación local desactualizada del propio proveedor de certificación.

Si además de este error te aparecen otros relacionados con validaciones de patrón o de catálogo en CFDI 4.0, hemos cubierto los más frecuentes en CFDI33131 (RegimenFiscalReceptor) y en el uso correcto del RFC genérico XAXX010101000. Para una vista más completa de errores de comprobante en general, consulta también la matriz de errores del comprobante CFDI que mantenemos actualizada en el blog.

Categorías: SAT México

Etiquetas: cfdi cfdi40103 sat mexico facturacion electronica