Método de pago SAT: PUE vs PPD en CFDI 4.0
10 de mayo de 2026
Si has cancelado más de un CFDI por elegir mal entre PUE y PPD, no estás solo. El método de pago SAT es el campo del CFDI que más confusión genera en producción, y la consecuencia de equivocarse no es trivial: un CFDI emitido como PUE cuando debió ser PPD obliga a cancelarlo y emitir uno nuevo, además de que el cliente no podrá deducir el gasto correctamente cuando finalmente pague.
La regla práctica cabe en una línea: si el cliente paga al momento de emitir la factura, es PUE; si va a pagar después, es PPD. Lo demás de este post explica por qué esa regla es engañosamente simple y dónde se rompe en la práctica.
Qué es el método de pago SAT
El método de pago SAT es el campo del CFDI 4.0 que indica cuándo se realiza el pago de la transacción: en una sola exhibición (PUE) o en parcialidades o pagos diferidos (PPD). Es uno de los campos obligatorios del nodo Comprobante en CFDIs de tipo Ingreso ("I") y se llena con dos claves del catálogo c_MetodoPago.
A diferencia de la forma de pago (que describe el medio: efectivo, transferencia, tarjeta), el método de pago describe el momento. Las dos claves son independientes y obligatorias, y elegirlas mal genera dos efectos distintos: la forma de pago incorrecta no impide la deducción pero puede generar observaciones; el método de pago incorrecto sí afecta directamente el flujo fiscal porque dispara o no la emisión de complementos de pago.
El catálogo completo c_MetodoPago
El catálogo del método de pago SAT tiene exactamente dos claves:
| Clave | Nombre | Cuándo se usa |
|---|---|---|
PUE | Pago en una sola exhibición | El pago se realiza al momento de emitir la factura, en un solo movimiento. |
PPD | Pago en parcialidades o diferido | El pago se realizará después de emitir la factura, ya sea en una sola fecha posterior o en múltiples parcialidades. |
Eso es todo el catálogo. La complicación no está en la cantidad de opciones, está en interpretar correctamente cuándo aplica cada una.
La regla simple: PUE si pagas hoy, PPD si pagas después
Si el cliente entrega el dinero (efectivo, transferencia, tarjeta, cualquier medio) en el mismo momento que se emite el CFDI, el método es PUE. La forma de pago en este caso es real y conocida: 03 transferencia, 04 tarjeta, 01 efectivo, etc.
Si el cliente todavía no ha pagado al momento de emitir el CFDI, o pagará en parcialidades, el método es PPD. En este caso la forma de pago obligatoriamente debe ser 99 (Por definir), porque al momento de emitir aún no sabes con qué medio el cliente liquidará la operación.
La parte que confunde a muchos integradores: en PPD el ciclo no termina con la emisión del CFDI Ingreso. Cada vez que el cliente paga (sea pago único o parcialidad), el emisor está obligado a emitir un Complemento de Recibo de Pagos (REP) que documente ese pago. Si el cliente paga en tres parcialidades, son tres REP además del CFDI Ingreso original.
Dónde vive el método de pago en el XML del CFDI 4.0
El campo aparece como atributo del nodo Comprobante, junto con FormaPago. Estos son los dos escenarios típicos.
CFDI PUE (pago de contado, transferencia bancaria):
<cfdi:Comprobante
Version="4.0"
Serie="A"
Folio="1234"
Fecha="2026-05-10T14:30:00"
FormaPago="03" <!-- Transferencia electrónica -->
MetodoPago="PUE" <!-- Pago en una sola exhibición -->
Moneda="MXN"
Total="11600.00"
TipoDeComprobante="I"
...>
...
</cfdi:Comprobante>
CFDI PPD (pago a 30 días, forma de pago aún no conocida):
<cfdi:Comprobante
Version="4.0"
Serie="A"
Folio="1235"
Fecha="2026-05-10T14:30:00"
FormaPago="99" <!-- Por definir (obligatorio en PPD) -->
MetodoPago="PPD" <!-- Pago diferido -->
Moneda="MXN"
Total="11600.00"
TipoDeComprobante="I"
...>
...
</cfdi:Comprobante>
El PAC valida la consistencia entre MetodoPago y FormaPago automáticamente. Si pones MetodoPago="PPD" con cualquier FormaPago distinta de 99, el timbrado se rechaza con error de validación. Lo opuesto también aplica: MetodoPago="PUE" con FormaPago="99" se rechaza porque PUE requiere una forma de pago real.
La combinación más comúnmente equivocada en producción: emitir un CFDI con MetodoPago="PUE" y FormaPago="99" porque el cliente "todavía no decide cómo pagará". Esa combinación es inválida. Si el cliente no ha pagado, el método es PPD por definición, no PUE. PUE significa que el pago ya ocurrió o está ocurriendo en este momento.
Reglas prácticas: cuándo es PUE y cuándo es PPD
Si llevas tiempo facturando manualmente esto se siente intuitivo, pero al automatizarlo conviene formalizar las reglas. Aquí están los escenarios que aparecen en la mayoría de las integraciones.
| Escenario | Método correcto | Forma de pago |
|---|---|---|
| Venta de mostrador con tarjeta | PUE | 04 |
| Venta en línea con cobro inmediato (Stripe, OpenPay, etc.) | PUE | 04 o 03 según el medio |
| Venta con transferencia el mismo día | PUE | 03 |
| Venta con depósito en efectivo recibido | PUE | 01 |
| Suscripción mensual cobrada al momento | PUE | 04 (tarjeta recurrente) |
| Factura a crédito (pago a 30, 60, 90 días) | PPD | 99 |
| Factura a parcialidades (50% ahora, 50% después) | PPD | 99 (incluso si una parte ya se pagó) |
| Anticipo recibido sin saber el resto | Caso especial: ver factura de anticipo | - |
| CFDI a cliente B2B con orden de compra | Casi siempre PPD | 99 |
La línea fina más común: una venta a crédito incluso si el cliente paga el primer abono el mismo día sigue siendo PPD, porque el CFDI documenta la operación completa, no solo lo que ya se cobró. Si el monto del CFDI es 100,000 MXN y el cliente entregó 30,000 al firmar, el CFDI es PPD por el total, no PUE por los 30,000.
Por qué el método de pago dispara el complemento de pago
PPD no es solo una etiqueta administrativa. Activa una obligación fiscal concreta: emitir un Complemento de Recibo de Pagos (REP) por cada pago recibido. El emisor tiene hasta el día 5 del mes siguiente al que recibió el pago para emitir el REP correspondiente, según la regla 2.7.1.32 de la Resolución Miscelánea Fiscal vigente.
Si emitiste un CFDI PPD pero nunca emitiste el REP cuando el cliente pagó, el cliente no puede deducir el gasto correctamente porque no tiene evidencia fiscal del pago. El cruce de información del SAT detecta el desfase y genera observaciones para ambas partes.
El detalle técnico de cómo emitir el REP, qué campos lleva y cómo relacionarlo con el CFDI Ingreso original está en el post de complemento de pago. Lo importante para esta discusión: cada CFDI PPD genera trabajo adicional posterior. Cada CFDI PUE no.
Errores comunes con el método de pago SAT
Cómo manejar el método de pago programáticamente
En una integración, el método de pago debe ser una decisión explícita por transacción, no un valor por defecto del sistema. Si tu plataforma cobra al momento (e-commerce con pasarela de pago), el flujo natural es PUE con la forma de pago que devolvió la pasarela. Si tu plataforma factura a crédito o por adelantado, el default seguro es PPD con FormaPago=99.
Fiscalapi expone los campos paymentMethodCode (MetodoPago) y paymentFormCode (FormaPago) en el endpoint de emisión de CFDI, validando la combinación antes de mandar al PAC. Si la combinación es inválida, la API devuelve un error descriptivo antes del timbrado, lo cual evita timbrados rechazados que igual cuentan en consumo. La documentación de Fiscalapi describe los campos y los SDKs en C#, Node.js, Python, Java, PHP y Go incluyen helpers para validar la combinación localmente. Los ejemplos de integración en GitHub muestran flujos completos con emisión de CFDI Ingreso seguido de complementos de pago.
Preguntas frecuentes sobre el método de pago SAT
El método de pago SAT es uno de los campos donde la decisión correcta ahorra trabajo posterior y la incorrecta multiplica el ciclo de cancelaciones y reemisiones. Si tu sistema aún tiene PUE como default automático, ese es el primer cambio que vale la pena revisar antes de la próxima oleada de facturación.