Automatic invoicing in n8n when an order is paid
A webhook from your shop fires when payment clears, n8n checks the order is genuinely paid and not already invoiced, calls the invoicing API to issue the document, and writes the invoice number back to the order. Five nodes, and it removes the morning re-typing job permanently.
Last reviewed:
What this workflow does
The workflow is trivial. The two guards around it are what stop it costing you money: never issue on anything but a confirmed payment, and never issue twice for the same order. Build those first and the rest is plumbing.
| Step | n8n node | What it does |
|---|---|---|
| Trigger | Webhook | Receives the order-paid event from the shop, over HTTPS, with signature verification on |
| Verify | IF | Continues only when the payment status is confirmed paid, not pending or authorised |
| De-duplicate | HTTP Request | Looks up the order record and stops if an invoice number is already stored against it |
| Build the payload | Edit Fields (Set) | Maps order lines, VAT rate, buyer details and payment date into the invoicing API shape |
| Issue | HTTP Request | POSTs the invoice to the invoicing API and reads back the number and document URL |
| Write back | HTTP Request | Stores the invoice number on the order so the de-duplication step can see it next time |
| Handle failure | Error Trigger | Catches a failed run and notifies a human rather than silently dropping the order |
Sources: n8n docs: Webhook node · n8n docs: HTTP Request node · Fakturownia API documentation · last reviewed: Aug 16, 2026
Setup, step by step
1. Register the webhook
Add a Webhook node, copy its production URL, and register it in your shop as the order-paid notification target. Turn on signature verification and reject anything that fails it. This endpoint is public, so treat it as hostile until proven otherwise.
2. Gate on a confirmed payment
An IF node checking the payment status is the single most important node in the workflow. Authorised is not paid, and pending is definitely not paid. Issuing a document against either creates an accounting correction you will do by hand.
3. Make the run idempotent
Look the order up and stop if it already carries an invoice number. Webhook senders retry, and without this guard a retry issues a second invoice for the same order. This is the failure people discover at month end.
4. Map the payload carefully
The Set node is where VAT rates, line descriptions and buyer identifiers get mapped to whatever the invoicing API expects. For Polish invoicing this is also where the buyer NIP goes, and getting it wrong is a correction rather than an edit.
5. Issue and write back
POST to the invoicing API with an HTTP Request node, read the returned invoice number, and write it back onto the order. The write-back is what makes step 3 work on the next run, so it is not optional.
6. Catch the failures
An Error Trigger workflow that posts to a channel someone reads turns a silent failure into a five-minute fix. Without it, the first sign of trouble is an accountant asking where January went.
Notes from running it
This is the automation we build most often and the one clients are most surprised by, because the work it replaces is invisible until you count it. Someone opens the shop admin every morning, reads the paid orders, and re-types them into the invoicing system. Twenty orders is forty minutes. It happens every working day, it is the least interesting thing anyone on the team does, and the error rate is exactly what you would expect from forty minutes of copying numbers.
Two things decide whether this workflow is an asset or a liability, and neither is the API integration. The first is the payment gate: a document issued against an authorised-but-not-captured payment is a correction, and corrections cost more than the automation saved. The second is idempotency. Webhook senders retry on timeouts, and a workflow that issues an invoice per delivery rather than per order will quietly duplicate documents until somebody reconciles the month. Both guards are one node each. Neither is glamorous, and skipping them is the difference between this being useful and this being a mess. For the platform choice behind it, see Make vs n8n vs Zapier, and for how these fit into a wider build, business automations.