API DE COMPLEMENTO DE PAGO

¿Qué es el complemento de pago?

Es el CFDI que emites para avisarle al SAT que ya te pagaron una factura que habías emitido a crédito. Se le llama REP —Recepción de Pagos— y no sustituye a la factura original: la acompaña. Si facturaste con método de pago PPD, ese comprobante queda abierto hasta que emitas el complemento correspondiente.

La parte que duele no es emitirlo. Es acordarse. Si cobras a 30, 60 y 90 días, cada factura te genera tres complementos en meses distintos, y el plazo vence el quinto día natural del mes siguiente a que recibiste el pago. Multiplica eso por doscientos clientes y entenderás por qué este es el complemento que más se automatiza.

El endpoint

El complemento de pago no tiene ruta propia: se emite por el endpoint general de CFDI, cambiando el tipo de comprobante.

Lo que lo convierte en un REP son dos campos: CfdiType en "P" y el nodo Complemento.Payments. Autenticación HTTP Basic, igual que el resto de la API.

El body

Un pago de $1,200 que liquida por completo una factura anterior:

{
  "Receiver": {
    "Name": "SinDelantal Mexico",
    "CfdiUse": "P01",
    "Rfc": "JAR1106038RA"
  },
  "CfdiType": "P",
  "NameId": "14",
  "ExpeditionPlace": "78216",
  "Complemento": {
    "Payments": [
      {
        "Date": "2018-04-05T05:00:00.000Z",
        "PaymentForm": "01",
        "Currency": "MXN",
        "Amount": "1200",
        "RelatedDocuments": [
          {
            "Uuid": "F884C787-EEA6-4720-874D-B5048DB8F960",
            "Folio": "100032007",
            "Currency": "MXN",
            "PaymentMethod": "PUE",
            "PartialityNumber": "1",
            "PreviousBalanceAmount": "1200",
            "AmountPaid": "1200"
          }
        ]
      }
    ]
  }
}

Fíjate en el Uuid dentro de RelatedDocuments: ese es el folio fiscal de la factura que estás saldando. Es el campo que enlaza ambos comprobantes, y el motivo por el que tienes que guardar el UUID de cada factura que emites. Si lo perdiste, tendrás que consultarlo antes de poder emitir el REP.

Parcialidades: donde se equivoca todo el mundo

Tres campos gobiernan las parcialidades y hay que llevarlos con cuidado porque el SAT valida la aritmética:

• PartialityNumber — el número de pago. Empieza en 1 y va subiendo.
• PreviousBalanceAmount — lo que quedaba por pagar antes de este pago.
• AmountPaid — lo que se abonó ahora.

Sobre una factura de $9,000 pagada en tres partes iguales, la secuencia queda así:

// Pago 1
"PartialityNumber": "1",  "PreviousBalanceAmount": "9000",  "AmountPaid": "3000"

// Pago 2
"PartialityNumber": "2",  "PreviousBalanceAmount": "6000",  "AmountPaid": "3000"

// Pago 3  → aquí el saldo queda en cero
"PartialityNumber": "3",  "PreviousBalanceAmount": "3000",  "AmountPaid": "3000"

El saldo anterior de cada pago es el del anterior menos lo abonado. Suena obvio escrito así, pero es el error que más aparece cuando alguien calcula ese campo desde el importe total de la factura en vez de arrastrar el saldo. La API no te lo va a corregir.

Cuándo NO necesitas emitirlo

Si la factura salió con método de pago PUE —pago en una sola exhibición, ya cobrada al emitirla— no lleva complemento. El REP es exclusivo de las PPD.

Vale la pena revisar esto antes de programar nada, porque hay sistemas que marcan todo como PPD "por si acaso" y acaban generando cientos de complementos que nadie necesitaba. Sale más barato arreglar el criterio en el origen que automatizar el error.

Lo demás del ciclo de vida

La respuesta del timbrado trae el Id y el UUID del complemento. Con el Id puedes consultarlo, descargar su XML o PDF, mandarlo por correo al cliente y cancelarlo si hizo falta.

Un aviso sobre cancelaciones: cancelar un REP no reabre la factura original por arte de magia en la contabilidad de tu cliente. Si te equivocaste de importe, lo ordenado es cancelar y volver a emitir el complemento correcto en el mismo periodo — no dejarlo para el cierre.

SDKs

Hay librerías oficiales para PHP, Python, JavaScript, Java, Ruby y .NET (4.5+), con repositorio en GitHub. Y como el REP usa el mismo endpoint que una factura normal, si ya tienes montada la emisión de CFDI, añadir el complemento es cuestión de construir otro payload — no de integrar nada nuevo.

Cómo probarlo

1. Emite primero una factura de prueba con PaymentMethod: "PPD" en el sandbox y guarda su UUID.
2. Manda el JSON de arriba sustituyendo el Uuid por el que acabas de obtener.
3. Verifica que el saldo quede en cero, o emite la siguiente parcialidad si estás probando pagos parciales.

¿Y si prefieres no programar?

El complemento de pago se puede emitir desde la plataforma web seleccionando la factura original y capturando el cobro. Si manejas pocas facturas a crédito, esa ruta te ahorra el desarrollo entero.

Preguntas frecuentes

¿Cuándo se debe emitir el complemento de pago?

A más tardar el quinto día natural del mes siguiente a aquel en que recibiste el pago. Aplica solo a facturas emitidas con método PPD.

¿Puedo incluir varios pagos en un mismo complemento?

Sí. Payments es un arreglo, y cada pago puede a su vez saldar varios documentos en RelatedDocuments. Es útil cuando un cliente te liquida varias facturas con una sola transferencia.

¿Qué pasa si no emito el REP?

La factura original queda como no pagada para el SAT. Eso complica la deducción de tu cliente y deja tu contabilidad descuadrada frente a lo que el SAT tiene registrado.

¿El complemento de pago lleva importe en el concepto?

No. El detalle del cobro va en el nodo Payments; el comprobante en sí se timbra en ceros. Por eso CfdiUse es P01 y no un uso deducible.