Automatizar la facturación con n8n: del cobro a la factura sin tocar nada

1. Qué se automatiza y qué se ahorra

El proceso que va desde que alguien paga hasta que el cobro está registrado en contabilidad tiene siempre los mismos pasos, y ninguno requiere criterio humano cuando todo va bien.

Lo que más se nota no es el tiempo de emitir una factura, que son unos minutos. Es que desaparecen las tareas de vigilancia, que son las que te obligan a acordarte de mirar.

2. La frontera que no se debe cruzar

El reparto correcto de responsabilidades es sencillo. n8n decide qué hay que hacer y cuándo, y se lo pide por su API al sistema que sí puede hacerlo. La numeración, el encadenamiento de registros y el reporte fiscal se quedan donde deben estar.

Holded, Odoo y prácticamente cualquier programa de facturación serio tienen API para esto. Si el tuyo no la tiene, el problema no es la automatización, es el programa. Lo vemos en la comparativa entre Odoo y Holded.

3. El flujo, paso a paso

Este es el esqueleto de una automatización de facturación. Los nombres cambian según las herramientas, pero el orden no.

1. 01Entra el aviso del pago. La pasarela, la tienda o el CRM llaman a un webhook de n8n en cuanto se confirma el cobro.
2. 02Se comprueba que el aviso es auténtico. Antes de tocar nada, se verifica la firma. Lo explicamos en la sección 5 y no es opcional.
3. 03Se busca al cliente. Por NIF o por correo, según lo que tengas fiable. Si no existe, se crea con los datos de facturación del pedido.
4. 04Se pide la factura al ERP. Con sus líneas, sus bases y sus tipos de impuesto, y con una clave de idempotencia para que un reintento no genere dos.
5. 05Se registra el cobro. Se asocia el pago al documento y se guarda el identificador de la transacción de la pasarela en un campo propio, para poder rastrearlo después.
6. 06Se envía y se deja constancia. La factura sale al cliente y queda anotada en el CRM, para que quien atienda a ese cliente sepa en qué punto está.

Qué hacer con las variantes que sí requieren criterio

No todo se automatiza igual. Las devoluciones necesitan que la factura original exista, los pagos parciales no cierran el documento y los pedidos que cambian después de cobrarse requieren una rectificativa. Conviene decidir de antemano cuáles se automatizan y cuáles paran y avisan a una persona.

4. Recordatorios de cobro y conciliación

La segunda mitad del trabajo no es emitir, es cobrar. Aquí el flujo no lo dispara un pago, lo dispara el calendario.

• Un flujo programado revisa cada día qué facturas han vencido y no están cobradas.
• Primer aviso amable unos días después del vencimiento, dando por hecho que se ha pasado.
• Segundo aviso con el importe, la fecha y el enlace de pago, si lo tienes.
• Aviso interno a partir de cierto retraso o importe, para que una persona llame en lugar de seguir enviando correos.
• Se para solo. Cuando entra el pago, desde la pasarela o desde el banco, el flujo marca la factura como cobrada y deja de reclamar.

5. Asegurar la entrada, que es un puerto abierto

Un webhook es una dirección pública a la que cualquiera puede enviar datos. Si no compruebas quién llama, cualquiera puede inventarse un pago y hacerte emitir una factura falsa. Por eso las pasarelas firman lo que envían.

El error que hace fallar todas las firmas

La firma se calcula sobre los bytes exactos que envió la pasarela. Si dejas que n8n convierta el contenido en un objeto y luego lo vuelves a convertir en texto, el orden de los campos o los espacios cambian, y la firma ya no coincide nunca. Es el motivo por el que mucha gente acaba desactivando la verificación.

La solución es activar la opción Raw Body en el nodo Webhook. Con ella, n8n guarda el contenido original sin tocar, accesible como `$json.rawBody`, y esa es la cadena sobre la que hay que calcular la firma.

const crypto = require('crypto');

const secret = $env.STRIPE_WEBHOOK_SECRET;
const toleranciaSegundos = 300;

const cabecera = $input.first().json.headers['stripe-signature'] || '';
const rawBody = $input.first().json.rawBody;

// La cabecera trae la marca de tiempo (t) y una o varias firmas (v1)
let t = null;
const firmas = [];
for (const parte of cabecera.split(',')) {
  const [clave, valor] = parte.trim().split('=');
  if (clave === 't') t = valor;
  if (clave === 'v1') firmas.push(valor);
}
if (!t || firmas.length === 0) {
  throw new Error('Cabecera de firma incompleta');
}

// Stripe firma la marca de tiempo y el cuerpo, unidos por un punto
const esperada = crypto
  .createHmac('sha256', secret)
  .update(`${t}.${rawBody}`, 'utf8')
  .digest();

// Comparación en tiempo constante, nunca con ===
const valida = firmas.some((firma) => {
  const recibida = Buffer.from(firma, 'hex');
  return recibida.length === esperada.length &&
    crypto.timingSafeEqual(recibida, esperada);
});
if (!valida) throw new Error('Firma no válida');

// Sin esta comprobación, alguien puede reenviar un aviso antiguo
const edad = Math.abs(Math.floor(Date.now() / 1000) - Number(t));
if (edad > toleranciaSegundos) throw new Error('Aviso fuera de plazo');

return [{ json: JSON.parse(rawBody) }];

6. Que no se dupliquen las facturas

Este es el riesgo específico de automatizar facturación y merece su propia sección. Imagina que tu flujo pide la factura al ERP, el ERP la crea, y justo entonces se corta la conexión antes de que llegue la respuesta. n8n cree que ha fallado, reintenta, y acabas con dos facturas idénticas y dos números correlativos gastados.

La solución se llama clave de idempotencia. Se envía un identificador único derivado del pedido junto con la petición, y el sistema de destino reconoce que ya procesó esa operación y devuelve la factura que ya creó en lugar de crear otra.

• Deriva la clave de algo estable, como el número de pedido o el identificador del cobro. Nunca de la hora ni de un número aleatorio.
• Comprueba si tu ERP la admite. No todos lo hacen. Si el tuyo no, hay que consultar antes de crear si ya existe un documento con ese pedido.
• Guarda la relación. Deja anotado en algún sitio qué pedido generó qué factura, para poder comprobarlo sin abrir el ERP.

7. Qué pasa cuando falla

Una automatización de facturación se juzga por cómo se comporta el día malo. Las APIs se caen, los límites de peticiones saltan y llegan datos que nadie previó.

Dónde va a parar lo que falla

Todo lo que no se puede procesar tiene que acabar en un sitio concreto, no desaparecer. n8n permite asignar un flujo de gestión de errores común a todos tus flujos, y ese es el lugar donde centralizarlo.

1. 01Guardar primero, avisar después. El primer paso del gestor de errores es escribir en una tabla el contenido completo que falló, el error y la fecha. Si avisas antes de guardar y el aviso falla, pierdes el caso.
2. 02Avisar a un canal que alguien mire. Un mensaje con el flujo, el nodo que falló y un enlace a la ejecución concreta.
3. 03Poder reintentarlo. Guardar el contenido original sirve para volver a lanzarlo cuando el problema esté resuelto, sin pedirle nada al cliente.

8. Cuándo necesitas más que una instalación sencilla

Una instalación normal de n8n procesa las peticiones de una en una. Para una tienda con pedidos repartidos a lo largo del día sobra. El problema llega con los picos, cuando una campaña concentra cientos de cobros en minutos.

Para eso existe el modo cola, donde la instancia principal recibe las peticiones y las deja en una cola de Redis, y varios trabajadores las van procesando en paralelo. Nada se pierde aunque entren de golpe.

EXECUTIONS_MODE=queue

# Base de datos compartida por la instancia principal y los trabajadores
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres.interno
DB_POSTGRESDB_PORT=5432

# Cola de trabajos en Redis
QUEUE_BULL_REDIS_HOST=redis.interno
QUEUE_BULL_REDIS_PORT=6379

# La misma clave en todas las instancias, o las credenciales no se descifran
N8N_ENCRYPTION_KEY=tu_clave_de_cifrado

WEBHOOK_URL=https://automatizacion.tudominio.com/

Antes de darlo por terminado

• La verificación de firma está activa y probada con un aviso falso, que debe rechazarse.
• Hay clave de idempotencia o comprobación previa de duplicados.
• Los reintentos solo se aplican a los errores pasajeros.
• Existe un flujo de errores asignado que guarda lo que falla antes de avisar.
• Las facturas las emite el sistema que cumple la normativa, no n8n.
• Hay una comprobación que detecta las ejecuciones que acaban bien sin hacer nada.