n8n has no ready-made KSeF node, and probably will not have one for a long while. You build the integration out of blocks n8n has always had: an HTTP Request node to talk to the Ministry of Finance API, a Schedule Trigger to poll on a cycle, a Code node to sign the request and take the XML apart, and a plain database or spreadsheet to remember what you have already fetched. That is more work than clicking "install" — and in return you get an automation that does exactly what you specified, and that belongs to you.
This piece is for someone who already knows whether they want to automate invoices and is asking how to assemble it. If you are at an earlier stage, start with my guide to KSeF in 2026, covering the 1 February and 1 April 2026 deadlines, then the comparison of three ways to collect invoices — n8n is only one of them, and not always the best.
This reflects the situation in October 2026 and my own implementation practice. KSeF, Poland's national e-invoicing system, is still being developed by the Ministry of Finance, and n8n ships a new release almost weekly, so I always check the current specification and changelog before starting.
Why n8n rather than a script
A fair question, because I would write this faster in Python. There are three arguments for n8n, and all of them concern what happens after go-live.
You can see what happened. Every run has a history: which request went out, what came back, where it stopped. The business owner can look for themselves and see that six invoices arrived at 07:00 today. With a script on a server, they see a log if someone shows it to them.
Further steps get added without a developer. Adding a Teams notification, a spreadsheet row or a PDF dropped on the company drive is a matter of dragging in a node. Those steps, not the downloading itself, are where the time savings live.
You are not tied to one supplier. A workflow exports to a JSON file and can be restored anywhere. My uncommented script is a black box for your company, and it should not be buying one.
There is one argument against: genuinely unusual work (heavy XML processing, custom cryptography) is more comfortable written as code. So in practice I build a hybrid — the logic in n8n, the hard parts in a Code node.
Anatomy of the workflow: eight nodes
Below is the skeleton I rebuild on each project. It is a pattern, not a copy of any client's system.
| # | Node | Job |
|---|---|---|
| 1 | Schedule Trigger | Fires every 2–4 hours during working hours |
| 2 | Code / HTTP Request (auth) | Authenticates to KSeF with a token or certificate and opens a session |
| 3 | HTTP Request (query) | Asks for invoices where the company is the buyer, from the stored checkpoint |
| 4 | Code (deduplication) | Drops KSeF numbers already held in the database |
| 5 | HTTP Request (fetch) | Downloads the XML of each new invoice |
| 6 | Code (parsing) | Extracts seller, tax ID, amounts, due date, bank account |
| 7 | Switch (routing) | Sends the invoice to the right person according to your rules |
| 8 | Database / Sheets + Teams/Slack | Stores state and notifies the approver |
Plus two nodes that are easy to forget: writing the checkpoint at the end of a successful run, and an error branch wired to a separate alerting workflow.
Authentication: the hardest node
This is where most first attempts collapse. KSeF does not accept a plain API key in a header. You have to open a session: fetch a challenge from the system, sign it with the company's token or certificate, receive a session token, and only then use that in subsequent requests. Sessions expire, so the automation must be able to renew one mid-run.
Practical conclusions from my projects:
- Token to start with, certificate for a larger company. You paste a token into n8n credentials and forget about it. A certificate is more convenient when several systems hold access and you want to revoke one without touching the rest.
- Credentials, never inside the node. A token hard-coded into a URL field ends up in every workflow export and every log. I keep it in an n8n credential and reference it as a variable.
- Read-only permission for invoices. An automation that collects costs has no business holding the right to issue invoices on the company's behalf.
- Test environment first. The ministry provides a test environment, and it is worth running the whole workflow through it before touching production. An invoice sent to production KSeF by mistake has to be corrected afterwards.
Scheduling and memory: where duplicates come from
The most common flaw in homemade automations is a trigger set to "fetch invoices from the last 24 hours". It works perfectly until n8n stops over a weekend after a server update. On Monday the automation asks about the last day, and nobody ever collects Saturday's invoices.
I do it differently. After each successful run I store the timestamp I reached. The next run starts from that mark with a buffer of fifteen minutes or so, so nothing falls through the gap. The buffer means some invoices arrive twice — which is exactly why node 4 rejects KSeF numbers already in the database. Deduplicating on the KSeF number is safer than on the seller's own invoice number, because the latter repeats across suppliers.
On frequency: every 2–4 hours during working hours is plenty for purchase invoices. Polling every minute changes nothing, because you are waiting for a human to approve the cost anyway.
Error handling, or the difference between a toy and a tool
An automation that quietly stops is worse than collecting invoices by hand, because nobody knows it stopped. The minimum I always add:
- Error Workflow. In the workflow settings I point to a second workflow that fires on any unhandled error and messages me with the detail.
- Retries on HTTP nodes. Two or three attempts with a delay. A brief API outage is normal, not a failure.
- A silence alarm. A separate, very simple workflow checks once a day whether there was any successful run. If nothing has succeeded for 12 hours, I get a message. That single node has caught more problems for me than all the other safeguards combined.
- A warning before access expires. Tokens and certificates have end dates. A reminder a fortnight ahead saves a Friday evening.
Self-hosted or n8n Cloud
Both are reasonable, and the choice comes down to who is going to look after the server.
| n8n self-hosted | n8n Cloud | |
|---|---|---|
| Tooling cost | Community licence free, you pay for the server | Monthly subscription by plan |
| Where invoice data sits | On your server (you can choose Poland/EU) | With the provider, per the plan's region |
| Updates and backups | Your job, or your supplier's | Handled by the provider |
| Good for | Companies sensitive about where data lives | Companies with no in-house IT |
As a rough figure: a VPS big enough for one invoice automation costs roughly £10–15 a month, and I add the cost of looking after it, because somebody has to apply updates and check backups. On the service page I quote tooling at £0–110 a month for process automation; a KSeF automation sits at the bottom of that range. For one client who already ran a server for other services, adding n8n did not change the hosting bill at all.
One thing holds whichever route you take: the admin account must be yours. If the n8n instance lives on your supplier's account, parting company leaves you with a JSON export and a problem.
What the first month taught me
XML parsing is dull, and that is where the bugs sit. The FA structure allows variants: line items at different VAT rates, corrections, prepayments, attachments. The first version of a parser always handles a typical hosting invoice and falls over on one with eight lines and a discount. So after go-live I collect the raw XML of every invoice for a fortnight, and only then finish the parser.
People do not read email, they read notifications. The same approval request sent by email sits for three days; sent to Teams with a button, it is clicked within the hour. One node changed, a large difference in cycle time. I set out the rest of the approval rules in the piece on document flow and invoice approval.
Half of your cost documents never come through KSeF. Foreign subscriptions, receipts, tickets, bank charges. If the automation only handles KSeF, the company ends up with two parallel processes and drifts back to the ring binder. For one client, closing that second path — reading scans with AI-based OCR and feeding them into the same approval queue — took longer than the entire KSeF integration.
When to skip n8n
Against my own interest: with a dozen or so purchase invoices a month and one person approving them, do not build this. The KSeF module in your accounting software, or authorising your accountant, is enough and costs a fraction. An n8n automation pays for itself when at least two of these hold:
- several dozen purchase invoices or more pass through the company each month,
- more than one person approves them, or the rules depend on amount and category,
- an invoice has to reach two different systems (accounting and your own project database, say),
- you want notifications and a report, which accounting software will not give you.
The full scope of what I assemble on a project is on the page for KSeF and invoice workflow automation.
FAQ
Does n8n have a ready-made KSeF node?
No. The integration is built from HTTP Request and Code nodes against the Ministry of Finance API specification. I treat the templates floating around online as a starting point rather than a solution — they usually lack checkpoint memory and error handling.
Is the free version of n8n enough for invoices?
For collecting purchase invoices and a simple approval flow, yes — the community licence on your own server is sufficient. Paid plans start to matter with many users and team features.
Can n8n also issue invoices into KSeF?
Technically yes, but I rarely advise it. Issuing sits closer to accounting, and it is better handled by software that watches numbering and corrections. I keep n8n on the receiving and approval side.
What happens to my automation when the KSeF API changes?
The request nodes will need updating. Some integrations need rewriting when the API version changes, which is why I agree up front who makes those fixes and how quickly.
How long does building this take?
The bare collection skeleton runs after a few days. A real implementation with approval rules, testing on the test environment and a finished parser is roughly one to three weeks, in line with the ranges in my piece on what a KSeF implementation costs.
Summary
Integrating KSeF with n8n is not one node but a dozen decisions: token or certificate, how to remember the checkpoint, what happens on error, where the data lives and who gets notified. The technical part takes a few days. The days that actually decide whether it works go on approval rules and on the invoices that never touch KSeF.
If you have already counted how many purchase invoices a month go through your business and want to know whether your own automation is worth it, get in touch through the contact form. The first conversation is free, and it sometimes ends with me advising you to stay with your accounting software.