Preparing n8n Workflow for Publishing the FA(3) Logical Structure in KSeF in June 2025
Preparing a workflow in n8n for publishing the logical structure FA(3) is not a task for one evening. The change planned for June 2025 introduces new requirements regarding the format and validation. It is better to test everything earlier than to wait for problems in production.
The KSeF (Poland mandatory national e-invoicing system) documentation is available, but its interpretation can vary. In n8n we focus on HTTP nodes and JSON processing. I avoid promises of simplification here, because government integrations are rarely simple.
Current context of changes in KSeF
KSeF is switching to the FA(3) structure from June 2025. This means new fields in the invoice schema and other validation rules. Companies must adapt their integrations before the deadline becomes mandatory.
In practice such a change affects the way of generating and sending invoices. If you do not update the workflow, requests may be rejected. KSeF step by step for SMEs explains the basics of the obligation.
There is no room for guesses here. Check the official guidelines of the ministry and test in the test environment. This is the only way to avoid surprises.
Differences between FA(2) and FA(3) in practice
The FA(3) structure adds new elements related to corrective invoices and attachments. Old mappings from n8n will stop working without changes. The logic of data processing needs to be rebuilt.
In the n8n Function node you add code to handle new attributes. This is not just copy-paste. Each field must be validated before sending.
How to determine the KSeF obligation deadline for your company based on turnover and prepare automation in n8n for it helps determine when this applies to your company. Without this it is easy to miss the deadline.
Critically looking, many companies downplay these differences at the beginning. Then they lose time on fixes at the last minute.
Configuration of nodes in n8n for publishing the structure
Start with the HTTP Request node. Set the method to POST and the endpoint for publishing the logical structure. Add authorization headers with the token from KSeF.
In the Body field you paste the prepared payload in the format compliant with FA(3). Use the Set node before this to map the data from your source system.
If the workflow is to work cyclically, add the Schedule Trigger node. Set the interval to once a day in the test environment. This allows monitoring stability.
After the HTTP node add the IF node to check the response code. Success is 200 or 201. Direct everything else to error handling. Such a structure prevents silent failures.
Testing the workflow and error handling
Testing in n8n starts with executing single nodes. Do not run the entire chain at once. Validation errors of the FA(3) structure are common and poorly described.
Add the Error Trigger node which will send a notification to Slack or email. In the Function node parse the JSON response from KSeF to extract the specific error code.
In the KSeF test environment responses differ from the production one. Prepare at least 10 different test cases. This is the minimum that allows catching most problems.
KSeF in practice: the most common integration errors and how to avoid them describes typical pitfalls. It is worth looking there before building your own workflow.
Self-hosted n8n gives more control over such integrations. A comparison of options can be found in n8n Cloud or self-hosted? Cost calculator for the company.
What next after publishing the logical structure
After successful publication monitor the logs for at least 14 days. Changes in KSeF may appear without notice. The workflow must be ready for iterations.
Document every node and the expressions used. This helps with updates. Do not rely only on memory.
In summary, preparation for FA(3) is an iterative process. There are no shortcuts here. Test regularly and adjust based on real responses from the API.
