NewTell a voided invoice from a totally rectified one, without a second call
BeeL
Get StartedMulti-NIFVeriFactuStripeAPI ReferenceChangelog
n8n

Overview

Issue VeriFactu invoices from your n8n workflows, without writing HTTP requests.


At a Glance

What it doesLets any n8n workflow create, issue, send and track official invoices in BeeL.
How it connectsA verified n8n node, authenticated with a BeeL. API key
What you needn8n 1.60+ (Cloud or self-hosted) and a BeeL. API key
What you should knowBuilt and maintained by BeeL., and verified by n8n

When to use it

n8n is an automation tool: you connect services and decide what happens when something occurs. The BeeL. node adds the piece Spain requires — issuing an invoice that is legally valid, with its correlative number, chained hash and QR code, registered with the AEAT at that moment.

Reach for it when the invoice does not start from a Stripe charge: a form, your CRM, a bank transfer, a POS, a marketplace. Or when invoicing is only part of what has to happen — notify a channel, write to a sheet, file the PDF somewhere.

Charging through Stripe? Use the native Stripe integration instead. It invoices every charge automatically with nothing to build. n8n is for everything that is not that.


Who maintains it

The node is built and maintained by BeeL. and verified by n8n — it is listed in n8n's own integrations directory, at n8n.io/integrations/beel and beel-trigger. Verification means n8n reviewed it against their requirements, so an instance owner enables it once and everyone on the instance can use it. The source is open.

Compliance comes from BeeL., not from n8n. The workflow decides when an invoice is issued and with what data; the fiscal validity is the same as if you issued it from the dashboard.


Two things worth knowing up front

Retries do not duplicate invoices. Every create operation takes an idempotency key. Derive it from your own data — an order ID — and re-running the workflow returns the invoice that already exists instead of issuing a second one. This matters more than it sounds: a duplicate invoice with a fiscal number can only be undone by issuing a corrective one.

Errors surface before the request leaves n8n. Field constraints come from the OpenAPI contract, so an impossible VAT rate or a malformed NIF stops the workflow at the node, naming what is wrong, instead of arriving as an opaque 422 halfway through a run.