# Overview

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

## At a glance

| | |
|---|---|
| **What it does** | Lets any n8n workflow create, issue, send and track invoices in BeeL. |
| **How it connects** | A verified n8n node, authenticated with a BeeL. API key |
| **What you need** | n8n 1.60+ (Cloud or self-hosted) and a BeeL. API key |
| **What you should know** | Built 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 invoicing step — an invoice issued through BeeL., with its correlative
number, chained hash and QR code, and its record submitted to AEAT when VeriFactu is enabled.

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.

<Callout type="info">
  **Charging through Stripe?** Use the [native Stripe integration](/stripe) instead. It invoices
  every charge automatically with nothing to build. n8n is for everything that is not that.
</Callout>

---

## 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](https://n8n.io/integrations/beel/) and
[beel-trigger](https://n8n.io/integrations/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.

The invoice is issued by BeeL., not by n8n. The workflow decides *when* an invoice is issued and
*with what data*; BeeL. numbers, records and submits it exactly 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.

---

Full OpenAPI spec: https://docs.beel.es/api/openapi