KSeF and accounting automation: what is left for AI when invoices arrive as data (XML) rather than scans

Author: Published: Updated:

KSeF invoices need no scan reading. What still takes work — assigning invoices to accounts, matching payments to invoices, exceptions — and when AI pays off.

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 autumn 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 — foreign invoices, receipts and other documents outside KSeF that never go through the system. 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.

In short: your order or contract number appears on the invoice only if the supplier chooses to fill it in — those fields are not mandatory. 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 autumn 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, with the receiving duty and the dates in the table re-checked on 9 October 2026; the full source list is at the end.

Date What applies Basis
1 February 2026 Duty to receive structured invoices through KSeF — as a general rule for all VAT taxpayers, subject to statutory exceptions, including those who may still issue invoices outside KSeF themselves Ministry of Finance pages on the scope of mandatory KSeF
1 February 2026 KSeF mandatory for issuing for taxpayers whose 2024 sales including tax exceeded 200 million zł Article 145l of the VAT Act
1 April 2026 KSeF mandatory for issuing 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” (access keys for software) as a permanent way to log in to KSeF. According to the Ministry’s questions-and-answers page, amended on 8 October 2026, the Ministry has decided to keep tokens indefinitely. Even so, any connection to KSeF has to be built to survive changes to the Ministry’s API and data structure.

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

After KSeF, is automatic reading of invoice scans (OCR) still needed

For domestic invoices between VAT taxpayers — no. For documents outside KSeF — yes, and it is those documents that decide 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, documents outside KSeF are 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 ‘email → PDF → read → approve’ automation we walked through step by step in the n8n guide now serves documents outside KSeF, not the main flow of invoices.

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 to accounts — as a proposal 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 whose confidence score exceeds the set threshold goes for one-click approval; the rest go 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 document from outside KSeF 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). Among documents from outside KSeF, 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 PLN 1,390 at an illustrative fully loaded hourly cost of PLN 90.

Running cost, also illustrative. n8n Cloud Starter is €20 a month on annual billing for 2,500 executions (an execution is one run of the automation) — 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 dozen PLN. A token is the unit the provider counts text and charges in — roughly part of a word. Add about 2 hours a month for reviewing exceptions and handling model version changes. Together roughly PLN 300–400 a month; subtract that and about PLN 1,000 of saving remains.

Payback. Months to payback = build cost ÷ net monthly saving. Put in the build cost from the quote on your desk: at PLN 12,000 that is a year, at PLN 25,000 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 PLN 140 — 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 where — in which countries or regions — the provider processes the data and whether training on your data is switched off 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’ invoices by rule — check that before you talk to a contractor — then using that feature is enough. What to check in your system’s workflow module is set out in the text on supplier invoice workflow.
  • Too few documents. If coding takes two hours a month, it will almost certainly not pay back.
  • Nobody owns the chart of accounts and the cost centres. If two people code the same supplier’s invoices 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 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.

Sources: position as at 6 September 2026, updated 12 October 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. As a general rule, since 1 February 2026 VAT taxpayers have had to receive structured invoices through KSeF, Poland's national e-invoicing system, subject to statutory exceptions. Issuing through KSeF became mandatory for the largest taxpayers on 1 February 2026 and for the rest on 1 April 2026, apart from the smallest, who with invoiced sales of up to PLN 10,000 a month may invoice outside KSeF until 31 December 2026. KSeF removes the stage of reading domestic invoices, because the data arrives as XML. It does not remove invoice coding (assigning each invoice to accounts and cost centres), 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 pay back, so calculate it before you start.

After KSeF, is automatic reading of invoice scans (OCR) still needed?

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 of documents that still arrive outside KSeF — 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 PLN 450 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 assign KSeF invoices to accounts 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 terms of the specific service have to be checked for where — in which countries or regions — the provider processes the data and whether its use for training models is switched off. 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.