Automatic invoicing in n8n when an order is paid
When payment clears, your shop fires a webhook. n8n checks that the order is really paid and not yet invoiced, calls the invoicing API to issue the document and writes the invoice number back to the order. It takes six nodes and an error workflow, and the morning re-typing job is gone for good.
TL;DR verdict
The workflow itself is trivial. The two guards around it are what keep it from costing you money: issue only on a confirmed payment, and never issue twice for the same order. Build those first; 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 authorized |
| De-duplicate | HTTP Request | Looks up the order record and stops if an invoice number is already stored on it |
| Build the payload | Edit Fields (Set) | Maps order lines, VAT rate, buyer details and payment date to the shape the invoicing API expects |
| Issue | HTTP Request | POSTs the invoice to the invoicing API, which in Poland also submits it to KSeF, 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 person instead of silently dropping the order |
Which we'd pick, scenario by scenario
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. The endpoint is public, so treat every request as hostile until its signature checks out.
2. Continue only on a confirmed payment
The IF node that checks the payment status is the most important node in the workflow. Authorized is not paid, and pending is definitely not paid. A document issued against either means an accounting correction you will make by hand.
3. Make the run idempotent
Look the order up and stop if it already has an invoice number. Webhook senders retry, and without this guard a retry issues a second invoice for the same order. People usually discover this failure at month end.
4. Map the payload carefully
The Set node maps VAT rates, line descriptions and buyer identifiers to whatever the invoicing API expects. For Polish invoices the buyer's NIP goes here too, and a wrong NIP takes a correction, not 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 to the order. Step 3 relies on this write-back 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.
This is the automation we build most often, and the one that surprises clients most, because the work it replaces stays invisible until you count it. Someone opens the shop admin every morning, reads the paid orders and re-types them into the invoicing system. At two minutes an order, twenty orders take forty minutes. It happens every working day, it is the dullest job anyone on the team does, and it produces as many errors as you would expect from forty minutes of copying numbers.
Whether this workflow helps or hurts comes down to two things, and neither is the API integration. The first is the payment gate: a document issued against a payment that is authorized but not yet captured needs a correction, and corrections cost more than the automation saved. The second is idempotency. Webhook senders retry on timeouts, and a workflow that issues one invoice per delivery instead of one per order will quietly duplicate documents until somebody reconciles the month. Each guard is a single node. Neither is exciting to build, and without them the workflow makes a mess. For the platform choice behind it, see Make vs n8n vs Zapier, and for how this fits into a wider build, process automation.
Invoicing in Poland: KSeF
Poland's National e-Invoicing System (KSeF) became mandatory on 1 February 2026 for companies whose 2024 sales exceeded PLN 200 million including VAT, and on 1 April 2026 for everyone else. Firms whose invoiced sales stay within PLN 10,000 a month including VAT may stay outside it until the end of 2026. A foreign company registered for VAT in Poland doesn't have to issue invoices in KSeF if it has no seat or fixed establishment in Poland, or if its fixed establishment takes no part in the sale, though it may use the system voluntarily. Issuing invoices to consumers in KSeF is optional. When a Polish entity does invoice through KSeF, the workflow keeps its shape: the issue step sets Fakturownia's gov_save_and_send flag, Fakturownia submits the invoice, and the KSeF number arrives a moment later through Fakturownia's webhook, which a second small workflow writes back to the order. Once KSeF accepts an invoice it can't be edited, only corrected, so the payment gate and the duplicate check above matter even more.
Sources
Frequently asked
Which invoicing systems does this work with?
Any system with a REST API for issuing invoices, which covers the Polish systems clients ask for most, including Fakturownia. The node chain stays the same; only the payload mapping in the Set node changes per provider.
What stops it issuing two invoices for one order?
The de-duplication step. Before issuing, the workflow reads the order and stops if an invoice number is already stored on it. Webhook senders retry on timeouts, so without that check a retry creates a duplicate document.
Does this work with Baselinker or WooCommerce?
Yes, as the source of the order-paid event. Both expose order data and can call a webhook, so we adapt the trigger and the write-back to whichever one sits in front. The invoicing half of the workflow stays the same.
What happens when the invoicing API is down?
The run fails and the Error Trigger workflow notifies a person. We deliberately don't retry blindly against an invoicing API, because a half-finished issue is worse than a delayed one. A person retries once the API is back.
Can I run this on n8n Cloud instead of self-hosting?
Yes, and the workflow is identical. The choice comes down to how you want to pay and where the data sits: self-hosting means a flat infrastructure cost and your own server, while n8n Cloud means per-execution pricing and less to maintain.
Which process costs you the most?
Thirty minutes, free. You leave with a concrete fix plan and what the process costs you. The plan is yours, even if you build it without us.
Book a free audit