KSeF and accounting automation: what is left for AI when the invoice arrives as XML

Published:

What KSeF actually delivers, whether OCR is still needed once it is live, and the four jobs left for AI in a Polish accounting workflow.

Most writing about KSeF — Poland’s national e-invoicing system, which structured invoices must now pass through — and artificial intelligence promises that once e-invoicing arrives, “bookkeeping will do itself”. The opposite happened: KSeF automated one stage, reading the invoice, and that is exactly why an accounting automation project after KSeF is, in September 2026, smaller than it would have been a year ago. Smaller does not mean zero. The question of KSeF versus accounting automation now comes down to what is left once reading is subtracted: coding, matching to orders and contracts, payment reconciliation, exceptions, and the long tail of documents that never go through KSeF. The structured invoice did not touch any of that — and structurally could not.

This is for companies and accountancy firms already issuing and receiving invoices in KSeF, and especially for anyone sold automation in 2025 with OCR in the leading role. The facts about KSeF are given as at 6 September 2026, with sources at the end. The principle we build on — the system prepares, a person with professional responsibility approves — is set out on our page about accounting automation; here we describe what KSeF changed in that picture and what it did not.

What actually arrives from KSeF — and what is not in it

Since 1 February 2026 the binding format for a structured invoice has been the FA(3) logical structure. The invoice is an XML file, and the Ministry of Finance’s March 2026 guidance splits its fields into three kinds. Mandatory fields are always filled: NIP numbers (the Polish tax identification number), invoice number, dates, amounts, rates. Optional fields are filled “as mandatory, where the statutory condition is met” — that is how P_7, the name of the goods or service, is marked. Discretionary fields are required by no provision at all; the issuer fills them if it wants to.

For automation the third group matters most, because it holds everything that lets an invoice be matched to something: WarunkiTransakcji (transaction terms) with Umowy (contract date and number) and Zamowienia (orders), a hundred instances of each — but stating them, as the guidance puts it, “is voluntary”; DodatkowyOpis, key–value pairs of up to 256 characters whose names are “indicated by the taxpayer”; the bank account in Platnosc; Zalacznik, an attachment allowed from 1 February 2026 for invoices with complex quantity and price data, subject to prior notification. Whether an invoice arrives carrying your order number therefore depends on the supplier, not on the Ministry. The system itself assigns only the KSeF number (NrKSeF); a credit note points to the original invoice in NrKSeFFaKorygowanej.

And then what the XML does not have. The structure provides no field for the buyer’s nominal account, MPK (the Polish cost-centre code), project, budget line or approver; the FA(3) guidance contains no “konto księgowe” (nominal account), no “MPK” and no “dekret” (posting entry). That follows from what an invoice is: the issuer’s document. How you post it is known only inside your company. KSeF therefore delivers an invoice that is perfectly legible, not one that is posted.

In the XML Not in the XML
NIP numbers, invoice number, dates, amounts, VAT rates The buyer’s nominal account
Line descriptions (P_7) Cost centre, project, budget line
KSeF number, number of the corrected invoice Approver and approval status
Contract and order numbers — if the issuer chooses to The link to your order, when it did not
Additional description, bank account, attachment — at the issuer’s discretion Any judgement on whether the invoice is justified

Where KSeF stands in September 2026 — facts with dates

Dates per the Act of 5 August 2025 (Journal of Laws 2025, item 1203) and Ministry of Finance announcements, as at 6 September 2026; the full source list is at the end.

Date What applies Basis
1 February 2026 KSeF mandatory for taxpayers whose 2024 sales including tax exceeded 200 million zł Article 145l of the VAT Act
1 April 2026 KSeF mandatory for all other taxpayers, apart from the smallest (row below) Article 145l
until 31 December 2026 Taxpayers with monthly invoiced sales up to 10,000 zł including tax may issue paper and electronic invoices — up to the invoice that crosses the threshold Article 145m
until 31 December 2026 Invoices from cash registers, and receipts up to 450 zł treated as invoices, are allowed Article 145n
1 January 2027 Financial penalties under Article 106ni; the Ministry calls 2026 a transitional period Article 106ni; Ministry announcement of 30 March 2026
1 January 2027 A transfer paying a structured invoice between VAT taxpayers is to carry the KSeF number Articles 108a and 108g

On penalties the Ministry is explicit: “For 2026 no sanctions will be imposed for errors made while using KSeF”. Scale, from the same announcement: more than 87 million invoices from more than 345,000 entities in the first two months; per Ministry figures given to the Polish Press Agency (PAP) — 289.6 million invoices and 2.06 million issuers by 26 May 2026. We found no newer official data. The system is still changing: the Ministry counted 25 further changes, and in the June 2026 consultation it proposed among other things keeping tokens as a permanent login method — no decision yet, so any integration has to assume changes to the API and the schema.

Deadlines and obligations are settled by your accountant or tax adviser — this describes the technical and organisational side, not tax advice.

Is OCR still needed after KSeF

For domestic invoices between VAT taxpayers — no. For the tail of documents — yes, and it is the tail that decides whether a per-document OCR package still makes sense. Outside KSeF by operation of law are invoices from suppliers with no registered office or fixed establishment in Poland, transactions under the OSS and IOSS procedures, and invoices to consumers. Until the end of 2026, add invoices from cash registers and receipts up to 450 zł treated as invoices. And everything that was never an invoice but that accounts must read anyway: contracts, acceptance protocols, bank statements, debit and credit notes, travel expense claims.

How much of it is there? Our working assumption for a domestic SME is 10–25% of documents — an assumption, not a statistic, because no described sample stands behind it. In a company with a foreign owner and intra-group invoices from abroad the tail is sometimes the majority. So before you buy or renew an OCR package priced per document, spend a month counting how many documents actually arrive alongside KSeF. The mail → PDF → read → approve workflow we mapped node by node in the n8n guide is now a workflow for the tail, not for the main stream.

What is left for AI: four tasks

The rule for all four: where KSeF gives you an identifier, use a rule; the model comes in where the rules run out. Duplicates by NrKSeF and linking credit notes by NrKSeFFaKorygowanej are rules. The account for a new supplier with three lines of different character is not.

Coding, for approval

On KSeF and document coding the answer is short: KSeF does not touch coding, because there is no field for it. The model gets the supplier, the line texts from P_7, amounts and rates, and the history of that supplier’s previous codings, and proposes an account, cost centre, project and VAT treatment. A proposal above the confidence threshold goes for one-click approval; below it, onto the exceptions list. Approval takes seconds, but the person sees the proposal and the reasoning, not just a button. These are examples 2 and 3 from our piece on examples of AI automation, with a cleaner input.

Matching to orders and contracts

If the supplier filled in Zamowienia or Umowy, matching is a lookup by number — a rule. In most companies those fields arrive empty; then the model matches line texts and amounts to open orders and contracts and flags the deviations: a different quantity, a price above the contract, a supplier with no contract at all. The cheapest improvement is not technological: ask your ten largest suppliers to put your order number in Zamowienia — one message costs less than any model.

Payment reconciliation

Today this means matching the bank statement to invoices by amount, NIP and the number in the transfer description. From 1 January 2027 a transfer paying a structured invoice between VAT taxpayers is to carry the KSeF number, which will turn much of that matching into a comparison of identifiers — so this part of the scope for AI shrinks further again in 2027. The model is left with bulk payments with no identifier, amount differences, prepayments and transfers from entities outside KSeF.

Exceptions and completeness — this is where an AI agent belongs

A new supplier, an unusual VAT rate, an amount outside the contract, a service with no acceptance protocol, an invoice with no order. This is work for an AI agent with read-only permissions: it gathers the contract, the order and that supplier’s previous invoices, drafts a question to the process owner and puts it aside for approval. It does not post, does not approve, does not reply to the supplier. Here too we start in a mode that requires approval of every step and loosen it only on data from the pilot — without that mode nobody would have collected the list of cases the agent got wrong.

A worked example: 600 purchase invoices a month

The figures are illustrative, not from a client rollout; substitute your own. We do not quote other people’s per-invoice numbers — numbers without a described method come from sales material. A trading company receives 600 purchase invoices a month: 480 through KSeF and 120 alongside it — 60 foreign PDFs, 40 cash register invoices and receipts, 20 other documents.

Starting point after KSeF, without AI. Nobody retypes data any more, but somebody still codes it: 2 minutes per KSeF invoice (480 × 2 = 960 min) and 4 minutes per tail document that still has to be read (120 × 4 = 480 min). Together 1,440 minutes, or 24 hours a month.

With proposals from the model. We assume — these are assumptions to be replaced by pilot data, not results — that in the KSeF stream 85% of proposals are confident and are approved in about 20 seconds (408 × 0.33 min ≈ 136 min), and 15% are exceptions at 2.5 minutes (72 × 2.5 = 180 min). In the tail 70% are confident at about 40 seconds (84 × 0.67 min ≈ 56 min), and 30% are exceptions at 4 minutes (36 × 4 = 144 min). Together about 516 minutes, or 8.6 hours. Saving: about 15 hours a month, or about 1,390 zł at an illustrative fully loaded hourly cost of 90 zł.

Running cost, also illustrative. n8n Cloud Starter is €20 a month on annual billing for 2,500 executions — ample for 600 invoices (n8n.io pricing, 6 September 2026). The model: at Claude pricing from the same day (Sonnet 5: 2 USD per million input tokens, 10 USD per million output), 600 short invoices come to a few tens of zloty. Add about 2 hours a month for reviewing exceptions and handling model version changes. Together roughly 300–400 zł a month; subtract that and about 1,000 zł of saving remains.

Payback. Months to payback = build cost ÷ net monthly saving. Put in the build cost from the quote on your desk: at 12,000 zł that is a year, at 25,000 zł two years. What it depends on is set out in our piece on how much an AI rollout costs. The same arithmetic at 60 invoices a month gives about 1.5 hours, or about 140 zł — less than the running cost. Don’t build.

An accountancy firm counts differently: 40 clients at 60 invoices each is 2,400 documents a month, and the same integration pays back four times faster — provided the clients sit in one or two accounting systems, not ten.

Invoice data and the language model: send less

KSeF XML contains your company’s financial data, personal data of counterparties (the NIP plus the first and last name of every sole trader) and their addresses, and at the issuer’s discretion bank account numbers too. The simplest safeguard is applied before sending: send less. Coding needs the supplier, the line texts, amounts and rates; the bank account number and the address do not improve the account proposal, so strip them before anything reaches the model. Data that was not sent needs no guarantees.

If you run an accountancy firm you process these documents on behalf of your clients, so involving a model provider has to be settled in two relationships at once: firm–client (consent to sub-processing) and firm–model provider. Check the processing region and the exclusion of training on your content in the terms of the specific service rather than assuming. Who is the controller, who is the processor and what role the model provider plays in a given operation is set out in our piece on GDPR and an LLM rollout — RODO, in Polish usage, is the same regulation — and we do not abbreviate it here, because shortcuts on this subject tend to be wrong. The legal assessment belongs to your lawyer or data protection officer.

When this is a bad idea

  • Your accounting system already does it. If it imports KSeF XML and codes repeat suppliers by rule — check that before you talk to a contractor — do not build what you can buy on subscription. We say this even when it means no engagement.
  • Too few documents. If coding takes two hours a month, it is almost certainly not worth it.
  • Nobody owns the chart of accounts and the cost centres. If two people code the same supplier to two different accounts and both think they are right, the model will learn that inconsistency and propose it with confidence.
  • The process is not stable. A system migration, a change of accountancy firm, a rebuild of the chart of accounts — wait until the coding history is coherent again.
  • You expect posting without a human. A model gives a probable answer; the books require a certain one. That division of roles is not a transitional stage for us.
  • You treat a year without penalties as a year without scrutiny. The transitional period covers penalties under Article 106ni, not the correctness of your books. Automation that entrenches errors faster is not an improvement.

How to work it out for yourself

  1. Export the invoices you received through KSeF in one month and count them; count separately the documents that arrived alongside — by email, as PDFs, on paper.
  2. Measure how many minutes per invoice coding takes today — not retyping, because that is gone.
  3. Check what your accounting system already does with KSeF XML: import, rule-based coding, duplicates by KSeF number.
  4. List the fields you actually decide: account, cost centre, project, VAT treatment. That is the whole scope for the model.
  5. Count how many suppliers fill in Zamowienia or Umowy, and decide which ones you will ask to.
  6. Name the person who approves codings and the owner of the exceptions list. Without that there is no process, only a tool.
  7. Put your numbers into the payback formula from the previous section. Above two years — come back to it when the volume grows.

What next

KSeF made reading invoices the Ministry of Finance’s problem. What is left — coding, matching, reconciliation, exceptions and the tail of documents from outside the system — has exactly the shape of the process we describe on our page about AI automation in a business: repeatable, with a person at the end, and with a measurable number before it starts. Accounting automation after KSeF is a smaller project than a year ago — as long as you count it on your own numbers. Write and tell us how many invoices a month go through KSeF and how many alongside it. We will say which stage we would start from — including when the answer is “not yet worth it”.

Sources and position as at 6 September 2026

Frequently asked questions

Does accounting automation still make sense once KSeF is in place?

Yes, but the scope is different from a year ago. KSeF — Poland's national e-invoicing system, mandatory for the largest taxpayers from 1 February 2026 and for the rest from 1 April 2026, apart from the smallest, who with invoiced sales of up to 10,000 zł a month may invoice outside KSeF until 31 December 2026 — removes the stage of reading domestic invoices, because the data arrives as XML. It does not remove coding, matching to orders and contracts, payment reconciliation or exception handling, and documents outside KSeF — foreign invoices, receipts, contracts — still have to be read. The project is smaller and cheaper, but it does not disappear; at low volume it may not be worth it, and that is worth calculating before you start.

Is invoice OCR still needed after KSeF?

For domestic business-to-business invoices — no, because the FA(3) structure, in force since 1 February 2026, carries the data in machine-readable form. For the long tail — yes: invoices from suppliers with no registered office or fixed establishment in Poland do not go through KSeF, invoices from cash registers and receipts up to 450 zł treated as invoices are allowed outside KSeF until 31 December 2026, and contracts, acceptance protocols and bank statements were never invoices in the first place. Before you buy an OCR package priced per document, spend a month counting how many documents actually arrive alongside KSeF.

Can AI code invoices from KSeF automatically?

It can prepare the coding, but it should not approve it. A structured invoice has no field for the buyer's nominal account, cost centre or project — that information exists only inside your company, so the model proposes it from the supplier, the line descriptions and the history of earlier codings, and a person with professional responsibility approves, corrects or rejects it. Confident proposals are approved in seconds; uncertain ones go onto the exceptions list. This division of roles is not temporary: a model gives a probable answer, and the books require a certain one.

What does KSeF change about reconciling payments to invoices?

Two things. Already today every structured invoice received through KSeF carries a KSeF number — documents arriving outside KSeF, including foreign invoices and receipts, do not. For invoices received through KSeF, duplicate detection and linking credit notes to the original invoice is a rule, not a job for a model. From 1 January 2027 transfers paying structured invoices between VAT taxpayers are to carry the KSeF number, which will turn much of the work of matching bank statements to invoices into a simple comparison. The language model is left with the rest: bulk payments with no identifier, amount differences, prepayments and payments from entities outside KSeF. Position as at 6 September 2026.

Can an accountancy firm send clients' KSeF invoices to an AI model?

It can, provided it settles this in two relationships at once: firm–client and firm–model provider. The firm processes documents on behalf of its clients, so involving a model provider means putting sub-processing on a proper footing, while the processing region and the exclusion of training on your data have to be checked in the terms of the specific service. The most effective safeguard, though, comes earlier: coding does not require you to send bank account numbers or addresses, only the supplier, the line items and the amounts. This describes the technical side; it is not legal advice.