Facturar automáticamente los pagos de Stripe en España
Stripe cobra. Stripe no factura.
El recibo que Stripe envía al cliente no es una factura válida en España: no lleva tu numeración correlativa, no cumple los requisitos del Reglamento de Facturación y no sirve para que tu cliente se deduzca el gasto. Así que cada venta que entra por Stripe deja una tarea pendiente en tu escritorio.
Con dos o tres ventas al mes da igual. A partir de veinte se convierte en la razón por la que llegas al trimestre con una carpeta de cobros sin facturar.
El detalle que casi todas las guías se saltan
Casi todo lo que vas a encontrar sobre este tema asume que tu cliente es una empresa y te va a dar su NIF. Y entonces te dicen que actives Tax ID collection en Stripe y lo pongas como obligatorio.
Si vendes a particulares, ese consejo te cuesta ventas. Un consumidor que compra un curso de 40 € no tiene por qué darte su NIF, y obligarle a rellenar un campo fiscal en mitad del pago es una de las formas más eficaces de que abandone el carrito.
La ley española ya contempla esto: es la factura simplificada, lo que antes se llamaba ticket. Se puede emitir sin identificar al comprador para operaciones por debajo de determinados importes, que es exactamente el caso de la mayoría de ventas online a particulares.
Así que un sistema de facturación automática bien hecho no fuerza el NIF. Bifurca:
- Llega NIF → factura completa, con el contacto dado de alta y todos sus datos fiscales
- No llega NIF → factura simplificada, sin contacto
Y cada tipo va a su propia serie de numeración. Esto no es un detalle estético: cada serie tiene que ser correlativa y sin huecos por separado. Mezclarlas rompe las dos a la vez, y eso ya no se arregla borrando una factura.
Qué necesitas
Un programa de facturación con API. Quipu es el que hemos usado para montar y probar este flujo: tiene API pública documentada, endpoints separados para facturas completas y simplificadas, y expone /simplified_invoices como compatible con VeriFactu, que será obligatorio el 1 de enero de 2027 para sociedades y el 1 de julio de 2027 para autónomos.
n8n, para orquestar. Puedes usar la versión en la nube o autoalojarlo en un VPS básico si prefieres no depender de límites de ejecuciones. Para este tipo de flujo el servidor más pequeño sobra.
Stripe Checkout o Payment Links, con recogida de dirección de facturación activada y recogida de NIF opcional, no obligatoria.
Cómo funciona el flujo
Stripe avisa con el evento checkout.session.completed. A partir de ahí:
-
Se vuelve a pedir la sesión a la API de Stripe. Del webhook solo se usa el
id. Esto importa: la URL de un webhook es pública, y si el flujo se fiara del JSON recibido, cualquiera podría enviar un POST falso y meter facturas inventadas en tu contabilidad. Pidiendo el objeto real con tu clave secreta, un id inventado devuelve 404 y ahí se acaba. -
Se comprueba si ya está facturada. El identificador de la factura se guarda en los
metadatadel PaymentIntent al terminar. Stripe reintenta los eventos que fallan, así que sin esta comprobación un solo pago acaba generando varias facturas. -
Se decide el tipo según haya NIF o no, y se busca la serie de numeración correspondiente.
-
Se crea la factura con las líneas, el IVA por línea y los descuentos aplicados.
-
Se marca el pago como facturado en Stripe, cerrando el círculo.
Los dos sitios donde esto se tuerce
Los importes de Stripe vienen en céntimos. amount_total: 12100 son 121,00 €. Si pasas ese número tal cual a tu programa de facturación, emites una factura de 12.100 €. Hay que dividir entre 100 siempre.
Y ojo con la base imponible: amount_subtotal es antes de descuentos. La base real es amount_subtotal - amount_discount.
El IVA depende de si usas Stripe Tax. Con Stripe Tax activado, cada línea trae su amount_tax y el tipo se deduce de los propios importes: es el escenario fiable. Con Stripe Tax desactivado, amount_tax es cero y tienes que decirle al flujo si tus precios llevan el IVA incluido o no. Si te equivocas ahí y tus precios son con IVA incluido, facturas un 21% de más en cada venta.
Ventas fuera de España: lo que no hay que automatizar
Aquí conviene ser claro, porque es donde más daño se puede hacer.
Una venta a otro país de la UE no lleva IVA español por defecto. Puede ser exenta por inversión del sujeto pasivo, si vendes a una empresa con número de IVA intracomunitario válido. O puede llevar el tipo del país del comprador, si es una venta de servicios digitales a un particular y estás en el régimen OSS. Son reglas distintas con resultados distintos, y los tipos cambian.
Meter esa lógica dentro de un flujo de automatización es una mala idea. Los tipos se quedan desactualizados, los umbrales cambian, y el que acaba con las facturas mal emitidas eres tú.
Lo correcto es que el flujo se niegue a adivinar. Si el cliente está fuera de tu país y Stripe no ha calculado el impuesto, el flujo debe pararse y avisar, no aplicar tu tipo por defecto y seguir. Y la solución real es activar Stripe Tax, que calcula el tipo según destino: entonces el flujo lo deduce de los importes y vuelve a funcionar solo.
Un sistema que se para cuando no sabe vale mucho más que uno que siempre responde algo.
Los errores que te vas a encontrar
Ninguno está documentado. Todos salieron montando esto contra las APIs reales.
400 invalid_scope al pedir el token de Quipu
No son tus claves: si estuvieran mal, la respuesta sería invalid_client. Falta el scope. La API de Quipu define uno solo, ecommerce, y es obligatorio en toda petición de token.
El campo filing_number es obligatorio cuando se indica issue_date
No rellenes filing_number. Ese campo y la relación numeration son mutuamente excluyentes: manda la serie y deja que Quipu numere. Si numeras tú, dos pagos simultáneos generan el mismo número.
payment_method no está incluido en la lista
Lista cerrada que no aparece en el OpenAPI de Quipu. card no vale; bank_transfer sí. El campo es opcional: si dudas, no lo mandes. Cada campo opcional que envías «por si acaso» es una superficie más donde fallar.
L identificador del document no coincideix amb el de la sèrie de numeració seleccionada
Llega en catalán, aunque el resto de la API responda en castellano. Significa que estás mandando una serie del tipo equivocado: una simplificada contra la serie de facturas completas, o al revés.
Y aquí hay una trampa doble. La primera: filter[applicable_to] no basta, porque Quipu puede devolverte todas las series igualmente. Hay que comprobar el atributo applicable_to de cada una antes de usarla.
La segunda: las series de facturas simplificadas tienen applicable_to: "tickets", no simplified_invoices, aunque el endpoint sí se llame /simplified_invoices.
line_items llega vacío
No es un error, es peor: no falla. El objeto checkout.session que llega en el webhook no incluye las líneas. Hay que pedirlas aparte o expandirlas al recuperar la sesión. Si no, generas facturas sin conceptos.
Y si usas n8n para expandir, no pongas dos parámetros llamados expand[]: n8n construye un objeto y el segundo pisa al primero. Usa expand[0] y expand[1].
Cuánto trabajo es
Montarlo lleva una tarde si vas con los errores de arriba resueltos de antemano. Después no requiere mantenimiento: es un flujo que se ejecuta solo y que, bien construido, se detiene solo cuando encuentra algo que no sabe interpretar.
Lo que se gana no es tiempo por factura. Es dejar de tener una lista de cosas pendientes que crece sola cada vez que vendes.