Factuarea APIDevelopers
Mejora

Pagos anticipados y validación de la fecha de pago

Una fecha de pago anterior a la de emisión se acepta ahora como pago anticipado, y una fecha de pago posterior a hoy responde 422. Afecta a ventas y gastos, a marcar como pagada y a registrar un pago.

30 de octubre de 2026 — La fecha de un pago ya no tiene que ser igual o posterior a la fecha de emisión del documento. Un pago hecho antes de emitir el documento es un pago anticipado y se acepta. Una fecha de pago posterior a hoy se rechaza con un error de dominio 422.

Operaciones de esta versión

OperaciónoperationIdHerramienta MCPQué cambia
POST /v1/companies/{company}/invoices/{invoice}/mark-paidpublic-api.v1.invoices.mark_paidmark_invoice_as_paidSe acepta un paid_on anterior a la fecha de emisión. Un paid_on futuro responde 422.
POST /v1/companies/{company}/invoices/{invoice}/paymentspublic-api.v1.invoices.payments_createregister_invoice_paymentSe acepta un paid_on anterior a la fecha de emisión. Un paid_on futuro responde 422.
POST /v1/companies/{company}/purchase-invoices/{purchase_invoice}/mark-paidpublic-api.v1.purchase_invoices.mark_paidmark_purchase_invoice_paidSe acepta un paid_on anterior a la fecha de emisión del documento del proveedor. Un paid_on futuro responde 422.
POST /v1/companies/{company}/purchase-invoices/{purchase_invoice}/paymentspublic-api.v1.purchase_invoices.register_paymentregister_purchase_invoice_paymentSe acepta un paid_on anterior a la fecha de emisión del documento del proveedor. Un paid_on futuro responde 422.

La regla

La fecha de un pago no puede ser posterior a hoy (día de Europe/Madrid). Nada más la limita.

  • Anterior a la emisión: se acepta. Un cliente puede pagar antes de que se emita la factura, y tú puedes pagar a un proveedor antes de que llegue su documento. Registra la fecha real: es la que usan el ciclo de cobro, los informes de antigüedad y la conciliación bancaria. No la cambies para ajustarla a la emisión.
  • Posterior a hoy: 422. Registrar un pago confirma algo que ya ocurrió. Un pago que solo está previsto es el vencimiento del documento.

La respuesta es 422. El error siempre señala la fecha, pero su code, subcode y param dependen de la operación:

  • Ventas, mark-paid y payments: error.code business_rule_violation, sin error.subcode, error.param payment_date.
  • Gastos, mark-paid: error.code invalid_payment_date, sin error.subcode, error.param payment_date.
  • Gastos, payments: error.code business_rule_violation, error.subcode invalid_payment_date, error.param paid_on.

En tres de las cuatro operaciones param lleva el nombre que tiene la fecha en el dominio (payment_date), aunque el campo de la petición sea paid_on. Para distinguir este error de otros 422, comprueba estos valores en la operación que llamaste. No te bases en message.

Qué fallaba antes

  • Un paid_on anterior a la fecha de emisión se rechazaba, así que un pago anticipado no podía registrarse con su fecha real.
  • POST /v1/companies/{company}/invoices/{invoice}/mark-paid con un paid_on futuro respondía 500. Ahora responde el mismo 422 que las demás operaciones.

La misma regla en todas partes

  • Cambio de estado en lote. POST /v1/companies/{company}/invoices/bulk-status y POST /v1/companies/{company}/purchase-invoices/bulk-status reciben la fecha en payment_date y aplican la misma regla. Un payment_date posterior a hoy rechaza la llamada entera con 422 (error.code invalid_param_value, param payment_date) antes de procesar ningún documento. Una fecha anterior a la emisión de un documento se acepta. failures[] solo informa de los documentos que no pueden recibir el pago por otro motivo, como un id desconocido o un estado que no lo admite.
  • MCP. Las cuatro herramientas anteriores siguen la misma regla y responden con el mismo error que su operación REST.
  • Pasarelas de pago. Los cobros de Stripe sobre una factura existente se registran con la fecha real del cargo, nunca posterior a hoy. Ya no se adelantan a la fecha de emisión de la factura.

Qué hacer:

  1. Envía en paid_on la fecha real del pago, aunque sea anterior a la fecha de emisión.
  2. No envíes una fecha futura. Si gestionabas el antiguo 500 de mark-paid, gestiona ahora el 422.
  3. No des por hecho en tus validaciones o informes que paid_on es igual o posterior a issued_on.

La tabla siguiente lista las operaciones de esta versión.

En esta página

¿Te echamos una mano?Contactar con soporte