Which entity in a group actually has to automate this?
Settle scope before design, because group finance functions get this wrong in both directions — some automate for entities that are not obliged, others assume a Polish VAT number is enough to stay out of it.
The test is establishment in Poland, not Polish VAT registration. Under art. 106ga of the VAT Act, a taxpayer with neither a seat (siedziba) nor a fixed establishment (stałe miejsce prowadzenia działalności gospodarczej) in Poland is outside the obligation to issue faktury ustrukturyzowane (structured invoices). Where a foreign-established company does have a Polish fixed establishment, the operative question is whether that establishment participates in the supply being invoiced. A group company holding a Polish VAT number with no people and no premises in Poland is therefore in a materially different position from the same group's Polish operating entity.
That boundary is inherited from EU law. Poland's mandate rested on Council Implementing Decision (EU) 2022/1003 of 17 June 2022, which authorised a derogation from Articles 218 and 232 of Directive 2006/112/EC limited to invoices issued by taxable persons established in the territory of Poland, and which runs to 31 December 2026. From 1 January 2027 the same limit sits in the Directive itself: Article 218, as amended by Council Directive (EU) 2025/516 of 11 March 2025, permits a Member State to require taxable persons established within their territory to issue electronic invoices for domestic supplies. Align your entity register against that phrase rather than against VAT numbers.
Two scoping facts complete the picture. The obligation to receive structured invoices reached all taxpayers on 1 February 2026; the general obligation to issue them followed on 1 April 2026. An entity can therefore be inside the receiving population and outside the issuing population, so produce the two lists separately. And there is no KSeF deferral for micro-entrepreneurs — the bill that would have excluded them until 31 December 2027 stalled after its first reading and was never enacted, yet it is still quoted as law in advisory material. If a Polish subsidiary tells you its smallest entities are out of scope until 2027, ask which instrument that comes from; see the library's register of corrections.
Why automate receiving before issuing?
The statutory sequence — receipt in February, issuance in April — is also the right implementation sequence, for three reasons that have nothing to do with the calendar.
- The risk is asymmetric. A failure in receipt means an invoice that was not booked on time. A failure in issuance means a document in legal circulation that cannot be withdrawn.
- You learn the system on other people's documents. The FA(3) logical structure, the behaviour of the API, the shape of the error responses — all of it can be learned without any risk of issuing something wrong.
- The return arrives sooner. Automatic retrieval and preliminary coding of purchase invoices usually saves more work than automated issuance does.
There is a group-specific reason as well. Receipt automation touches accounts payable, which in most multinationals is already centralised and already used to exception queues; issuance touches an order-to-cash path in a local ERP instance the group centre often does not operate. Starting with receipt puts the learning where the capability already is.
What are the four levels of KSeF automation maturity?
Naming the level you are on is worth the ten minutes it takes, because each level needs a different control set and skipping a level is the origin of most incidents.
| Level | What the system does | Controls required |
|---|---|---|
| 1. Assisted | Prepares the document; a person approves every one | FA(3) validation, basic logging |
| 2. Conditional automation | Submits documents meeting defined criteria on its own, routes the rest to a person | Approval thresholds, audit trail, idempotency |
| 3. Full automation | Submits everything; people handle exceptions | The above, plus offline-mode handling, reconciliation, anomaly monitoring |
| 4. Agentic processes | The system interprets data and decides what to issue | The above, plus pre-execution control independent of the agent, plus model-version capture |
The most common implementation error is going from level 1 to level 3 in a single step, justified by it works in test
. Level 2 exists so that you collect production evidence before the process stops being watched — how often counterparty master data is stale, what share of documents take an unusual path at month-end, how the queue behaves when KSeF is slow. None of that is visible in a test environment, and all of it is expensive to discover after the reviewer has gone.
What should you automate, and what should you leave alone?
Good candidates
- Recurring invoices to standing counterparties — high repetition, low variance.
- Documents generated directly by a sales system or e-commerce platform.
- Retrieval, download and preliminary coding of purchase invoices.
- Reconciliation and consistency checking, where automation is not optional but necessary — nobody does it by hand at volume.
Poor candidates
- Correcting invoices. Rare, varied, and loaded with context the system does not hold. They are additionally issued in the FA(3) structure even where the original document was created under FA(2) or FA(1) — a mismatch that is itself a recurring source of rejections.
- Unusual documents — unusual structure, new counterparties, new settlement schemes.
- Operations performed rarely. Code that handles a case occurring twice a year is not tested in practice, whatever the coverage report says.
Where does control quietly stop working?
There is a threshold beyond which the existing control mechanisms stop functioning while formally continuing to exist. It has three symptoms, and none of them announces itself.
Nobody looks at an individual document any more. At ten invoices a day someone sees them. At a thousand, nobody does. A control that assumed a human would notice an unusual document stopped working the moment that volume was crossed, and no one recorded the moment.
Errors are found by the counterparty. If you learn about a duplicate from a customer's email, your reconciliation either does not work or does not run often enough. This is covered in detail under duplicates and retries.
Reconstructing one operation requires a developer. This is the surest symptom. If answering why did this invoice go out in this form
means reading application logs, there is no audit trail — there are logs, which rotate, can be edited, and depend on a log level that gets changed in production without a procedure.
What is the minimum control set before unattended issuance?
Seven controls. None is optional at level 3, and the order matters: several only produce useful evidence once the earlier ones are running.
- Idempotency. A retry after a timeout does not create a second document, because the operation identifier is assigned before the first call and is identical across every attempt.
- Approval thresholds. Operations above a value limit, for new counterparties, and all correcting invoices require a human decision before execution — see approval checkpoints.
- An audit trail resistant to retrospective modification, with retention matched to the documentation period rather than to log rotation.
- Offline-mode handling with a register of decisions and deadline control. The modes are not interchangeable: tryb offline24 (the elective offline mode), niedostępność (announced unavailability) and awaria (announced failure) each carry their own transmission deadline, and which one applied must be recorded at the time.
- Recurring reconciliation — document counts on your side against KSeF for the same period, with orphan detection in both directions, on a cycle shorter than a month.
- Rate monitoring. An alert on an unusual number of operations per unit of time typically precedes discovery of the underlying data error by several dozen documents.
- A hard PLN 10,000 limit for any taxpayer relying on the transitional relief — available until 31 December 2026, and lost permanently from the invoice that exceeds it. Rarely relevant to a large group, occasionally decisive for a small acquired entity nobody has looked at.
What does a group finance function have to do differently?
A domestic Polish filer and a group finance function in London, New York or Frankfurt face the same statute and a different operational problem. Four differences are worth planning around.
The obligation attaches to the Polish taxpayer, not to the automation. A shared service centre in Kraków, Lisbon or Bangalore does not become the obliged party, and neither does your software vendor. If three entities in the structure are in scope, there are three populations of evidence, and a group process that treats Poland as one integration will produce records that cannot be attributed to a single taxpayer when the tax office asks.
Maturity level is an entity attribute, not a group standard. A group policy declaring level 3 for Poland, applied to a subsidiary whose integration is at level 1, produces a control that exists only on paper. Assess the level per entity and per ERP instance.
Exception handling has to be readable by people who do not read Polish. At level 3 the exception queue is the control. If reason codes, offline-mode decisions and approval records live as free text in a Polish-language ticketing system, a group reviewer cannot test the control. Store the mode, the basis and the deadline as structured fields with bilingual definitions.
Somebody has to own the credentials. If the ERP is operated centrally and the KSeF token belongs to the Polish entity, decide explicitly who holds it, who rotates it, and who is accountable when it is used. That is an intercompany control question before it is a technical one, and it is answered badly by default. The mechanics are covered under designing a reliable KSeF API integration.
How does this compare with the neighbouring regimes?
Groups running one e-invoicing programme across several markets assume the automation problem is the same everywhere. Structurally it is not, and the difference lands on the automation design.
Poland operates a clearance model: the state receives the invoice, validates it and assigns its identifier before the document is in circulation. The acceptance step therefore sits inside your issuing process, and the state's identifier — the numer KSeF — becomes an attribute you must store and, from 1 January 2027, carry in the payment reference under art. 108g. Germany's E-Rechnung obligation is by contrast a format obligation on invoices exchanged directly between the parties: no central register to submit to, and so no acceptance step to make idempotent. France routes invoices and reporting through certified platforms, putting a commercial intermediary between taxpayer and administration.
The practical consequence: an automation design that works for a format-only mandate — build the file, send it, log the send — is structurally insufficient in Poland, because it has no concept of an outcome that is unknown. That gap is where most cross-border implementations produce their first duplicate. The glossary carries the local vocabulary for each market with English glosses.
What changes when an AI agent is in the loop?
Level 4 differs from the others qualitatively rather than by degree. A deterministic process does what was written; an agent does what it judges appropriate in context. Two consequences matter for the control design.
The control cannot be part of the agent. If the decision about whether an operation requires approval is taken by the same model that initiates the operation, there is no control. The threshold has to be enforced in a layer the agent passes through and cannot bypass — the same principle the library sets out for approving AI actions generally.
Reproducibility requires version capture. A deterministic process can be replayed by running the same code over the same data. An agent cannot: the same input against the same model may produce a different result, and the model may have been swapped since. Without a record of the model and configuration version, you cannot establish even whether the behaviour was correct at the time. The evidence requirements are set out under AI agent audit trails, and the running cost of agent-initiated issuance under AI agent costs. KSeF makes the consequences non-reversible, because an accepted invoice cannot be deleted.
What is the automation worth in money from 2027?
Throughout 2026 there is no penalty for issuing outside the system or for errors, which makes the remaining months the cheapest period in which to build evidence. From 1 January 2027 the penalties in art. 106ni of the VAT Act begin to apply — up to 100% of the tax shown on an invoice issued outside KSeF, and where no tax is shown, up to 18.7% of the total amount due. Those are ceilings, moderated by art. 189d of the Kodeks postępowania administracyjnego, which obliges the authority to consider the gravity and circumstances of the breach, its frequency and the party's previous conduct; the detail sits under KSeF penalties from 1 January 2027.
Automation does not raise that exposure by itself. It raises the scale of a single defective rule's consequences, and at the same time makes the due-diligence argument far easier to evidence — but only where the audit trail is produced from the start rather than assembled after the incident. That is the whole case for putting the controls in front of submission.
In practice
BarzelOps runs governed cross-system workflow automation with durable state, approval checkpoints and tenant isolation, which are the level 2 and level 3 requirements from the list above. The tenant boundary is the part that matters to a group operating several Polish entities from one platform.
Frequently asked questions
Where should we start?
With receiving. It became mandatory for all taxpayers on 1 February 2026, it is technically simpler, and its failure mode is a late booking rather than an irreversible document.
Is a foreign-established group company obliged to issue through KSeF?
Only if it is established in Poland. A taxpayer with neither a seat nor a fixed establishment there is outside the issuing obligation; with a Polish fixed establishment, whether it participates in the supply decides the answer.
Should we automate correcting invoices?
Last, if at all. They are rare, varied, context-dependent, and issued in FA(3) even where the original was FA(2) or FA(1).
Does automation increase penalty risk?
Not by itself. It increases the scale of an error's consequences and makes due diligence easier to prove, provided the audit trail exists from the outset.
Can we skip level 2?
You can, and it is the most common cause of incidents. Level 2 is where production evidence is collected while a person is still watching.
What is the single control we should not go live without?
Idempotency. Without it a network timeout produces a second invoice with its own numer KSeF, and neither can be deleted.
Related reading
- Duplicates and retries in KSeF
- Designing a reliable KSeF API integration
- The KSeF audit trail
- KSeF penalties from 1 January 2027
- Governed workflow automation
- AI governance
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
95 days leftKSeF penalties apply from 1 January 2027
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Ministerstwo Finansów, Zakres obowiązkowego KSeF — ksef.podatki.gov.pl.
- Ministerstwo Finansów, Broszura informacyjna dotycząca struktury logicznej FA(3), 4 March 2026.
- Ustawa z dnia 11 marca 2004 r. o podatku od towarów i usług (Polish VAT Act), art. 106ga, art. 106ni, art. 108g — ISAP.
- Ustawa z dnia 5 sierpnia 2025 r. o zmianie ustawy o podatku od towarów i usług oraz niektórych innych ustaw, Dz.U. 2025 poz. 1203 — ISAP.
- Ministerstwo Finansów, KSeF 2.0 integration guide — github.com/CIRFMF/ksef-api.
- Council Implementing Decision (EU) 2022/1003 of 17 June 2022, OJ L 168, 27.6.2022, p. 81 — derogation limited to taxable persons established in the territory of Poland, applying until 31 December 2026.
- Council Directive (EU) 2025/516 of 11 March 2025 amending Directive 2006/112/EC as regards VAT rules for the digital age — amended Article 218.
This article is for information and does not constitute tax or legal advice. The Polish text of the instruments cited is the binding one.