Accounting policy for 2027: KSeF, automatic entries and AI agents — what's missing from the IT system description

The document nobody opens until someone asks for it

Most accounting policies I've read in Polish companies were written once, at registration or at the switch to full books, and then filed. The IT system section names a program and a version from years ago. It describes paper invoices arriving by post, a person who checks them, and a stamp with the account numbers.

None of that describes how a full-books client was actually booked in 2026. Purchase invoices arrive from KSeF as XML. Bank statements come in as MT940 and half the lines settle themselves. In some offices an agent proposes the postings and a person accepts them in batches.

The law barely moved. The Accounting Act already had the provisions, some of them for twenty years. What changed is that in 2027 every client issues invoices in KSeF, including the small ones that used the 10 000 zł exemption. The gap between the written policy and the real process becomes impossible to ignore. November is a good month to close it. The client signs these documents, not the office, and that takes a few weeks.

Four provisions that decide it

I read the current consolidated text for this post. Four provisions do almost all the work.

Art. 10(1)(3)(c) requires a description of the IT system when books are kept on a computer: a list of programs, procedures or functions, a description of the algorithms and parameters, the data protection rules, and the software version with the date it went into use. Note the word "algorithms". If something decides which account an invoice goes to, that's an algorithm, whether it's a posting schema in the ERP or a model.

Art. 14(4) says every computer entry must have an automatically assigned journal position number and data that identifies the person responsible for the content of the entry.

Art. 20(5) treats entries made automatically, through data links or created by an algorithm, as equivalent to source documents if four conditions are met. The entries get a permanently legible form that matches the documents. Their source and the person responsible for entering them can be established. The procedure checks that processing was correct and that the entries are complete and identical. And the source data is protected against change for as long as that type of document must be kept.

Art. 21(1)(6) and (1a)(2) cover the posting instruction (dekretacja): the document should show the month, the way it's booked and the signature of the person responsible, but you can skip putting that on the document when it follows from the technique used to document entries.

Then there's the part offices forget. Art. 10(2) says the head of the entity sets this documentation in writing and keeps it up to date. That's the client's management board or the owner, not the office. And art. 77(1) puts keeping books contrary to the Act under a fine or up to two years' imprisonment. Nobody gets prosecuted for an outdated IT description on its own. But in a tax audit, an outdated description makes it easier to call the books unreliable, and the client then asks the office why.

Where the posting decision lives when the invoice is XML

On paper the dekretacja was physical: a stamp, account numbers in pen, initials. A KSeF invoice is a structured file with a KSeF number. You can't write on it, and printing it to stamp the printout defeats the point.

Art. 21(1a)(2) is the route. You don't put the posting data on the document, because the technique of documenting entries makes it unnecessary. But the exemption only works if the policy actually describes that technique. It takes one sentence, and that sentence is usually missing:

"For invoices received through KSeF, the posting instruction is not placed on the document. The month and method of booking result from the entry in the journal, which contains the KSeF number of the invoice, the journal position number and the identifier of the user who approved the entry."

That sentence connects the document (by KSeF number) to the decision (the entry) and to the person (the user ID). If the ERP stores the KSeF number on the entry, which matters anyway for the JPK_CIT file and its account markers, the link is already there in the data. The policy only has to say so.

Automatic entries: four conditions and one name

This is where automation stops being abstract. Typical streams in an office in 2026:

• purchase invoices imported from KSeF with a posting schema,
• bank statements imported and settled against open items,
• foreign exchange differences calculated by the program,
• month-end entries created from rules (accruals, depreciation),
• in some offices, postings proposed by an agent and accepted by a person.

Each one is an "entry created by an algorithm" under art. 20(5). Condition 2 is the one that bites: the person responsible for entering them must be identifiable. A program isn't a person. An agent isn't either. So the policy needs a short table that assigns each automated stream to a role or a named person, and the system needs to log who accepted what. That's the same line I drew in the post on who signs when an agent posts: liability doesn't move to software, so what you build is evidence.

Condition 3, the procedure that checks processing, is one most offices already meet. They just never write it down. If someone compares the number of KSeF invoices received in the month against the number booked, that's the check. Write the procedure into the policy: what's compared, how often, by whom.

Condition 4 is about the source data. KSeF invoices sit in KSeF, but the office should not rely on access it may lose. The KSeF permissions are granted by the client and can be revoked. Keep your own copy of the XML for the retention period, which under art. 74(2)(8) is five years for most accounting documents. The previous version of the policy itself must also be kept for five years after it expires (art. 74(2)(5)), so version the annex instead of overwriting it.

What a 2027 annex should contain

Policy element	What it usually says	What it should say for 2027
IT system description, art. 10(1)(3)(c)	Program name, a version from years ago	Current version and start date of each program, including the KSeF connector, the bank import and any agent or automation layer
Algorithms and parameters	Nothing	List of posting schemas and rules, where they are kept, who can change them
Dekretacja, art. 21(1a)(2)	A stamp on the document	Posting decision recorded in the journal entry with KSeF number and user ID
Automatic entries, art. 20(5)	Nothing	Table: stream → source → responsible person → control check → frequency
Responsible person, art. 14(4)	"Główny księgowy"	Named user per stream; agent proposals marked as proposals until accepted
Data protection	Passwords, backups	Who holds KSeF permissions, where XML copies are stored, for how long
Version history	None	Annex number, date, signature of the head of the entity

For an office with, say, 40 clients, of which 14 keep full books, that's 14 policies. Writing each one from scratch takes several hours. With a common annex template where only the stream table and the program versions differ, I'd budget 60 to 90 minutes per client, most of it on collecting versions and finding out who actually approves what.

Timing and who signs

Two clocks run here, and they're easy to confuse.

The IT system description is documentation. Art. 10(2) says it's kept up to date, so it should change when the system changes. If a client moved to automatic KSeF import in April 2026, the description was already out of date in May.

Accounting methods are different. Art. 8(2) lets an entity change the solutions it uses for other ones allowed by the Act, with effect from the first day of the financial year, whatever the decision date. If the client also wants to change, for example, a valuation method or the threshold for expensing low-value assets, that goes into the same annex but follows the year-start rule and needs disclosure in the financial statements.

So one dated annex, prepared by the office, signed by the head of the entity before or around 1 January 2027, covers both. Send drafts in November. Signatures from 14 boards in December take longer than anyone plans for.

What an agent can do here, and what it can't

An agent is useful for the boring half. It can pull program versions from each client database, list the posting schemas that actually fired in 2026, count how many entries per stream were automatic versus manual, and draft the stream table. That's where the 60-to-90-minute estimate comes from: the inventory is the slow part, and it's mechanical.

What it can't do is decide who is responsible, or sign. Those are decisions for the office and the client. Writing them down is the part the law actually asks for.

If you want to see what the automated streams in your clients' books look like before you write the annex, book a short call.