Accounting automates well because it consists of repeatable processes on documents that leave a trail in systems. There is one non-negotiable principle: the system prepares — reads, codes, reconciles — and a person approves, keeping the responsibility.
Most of the work in accounting is not posting entries but everything before them: fishing invoices out of mailboxes and portals, retyping data, working out what a document concerns and which account or project it belongs to, matching payments, chasing missing documents. That work is repetitive and document- and text-based — exactly the profile that automates best.
The line is equally clear: a language model gives a probable result, and the books require a certain one. That is why, in the projects we run, the system never posts on its own — it prepares a proposal, and it is approved by the person who carries the professional responsibility. This is not caution for show: approving a well-prepared proposal takes seconds, so the value of the automation stays while the risk of a silent error in the books does not.
Structured invoices from KSeF — Poland’s national e-invoicing system — shift the proportions of this scope: the document arrives machine-readable, so the reading stage disappears and the value concentrates in posting logic, reconciliation and the approval flow. The long tail — foreign invoices, receipts, contracts — stays outside KSeF, and that is where document reading keeps working.
Accounting documents are the company’s financial data and its counterparties’ personal data, and payroll can additionally contain special-category data — health or trade-union details, for example. Before any document reaches a model, you have to settle which data leaves the company at all, where it goes and on what basis — from the choice of provider and processing region to limiting the data to the minimum a given step needs. How we approach it, and what to ask any supplier, is set out on our security and GDPR page.
The same way as in any implementation: one process, a number measured before the start — for example, minutes from an invoice arriving to it being posted — the narrowest possible pilot in approval mode, and parallel running before the switch. The full course is set out in our implementation methodology, and the full scope of the service — from process audit through to upkeep — on our AI implementation page. The five conditions a process must meet to qualify for automation are set out on our AI automation page — accounting processes meet them more often than most, because they recur monthly and their data comes as documents.
Cost is driven by the number of channels documents arrive through, the accounting system, and the level of certainty the posting requires — not by the document count in itself. One intake channel and one system is a matter of weeks; five mailboxes, paper and two systems is a different project. All the components, upkeep included, are broken down in our note on what an AI implementation costs.
Prepare the posting — yes; take responsibility for it — no. The system reads the document, proposes the posting based on the history of similar documents, and hands it over for approval. Professional responsibility and sign-off stay with the accountant — and that is not a temporary limitation but the right division of roles: a model gives a probable result, and the books require a certain one. The value is that approving a well-prepared proposal takes seconds, while retyping and coding a document by hand takes minutes.
The audit at the start of the project settles that, but the principle is simple: if the system has a document import interface or an API, integration is a matter of scope, not feasibility. Polish accounting systems vary widely here — from full APIs to file-based import — and that difference affects the cost, not the sense of the project. What often matters more than the system is how documents reach it: mailbox, paper, supplier portals — because that is the stretch we automate first.
It shifts the proportions of the project in automation’s favour. A structured invoice from KSeF — Poland’s national e-invoicing system — needs no reading from a scan: the data arrives machine-readable from the start, so the least reliable stage disappears. The value moves downstream: posting logic, assignment to projects and cost centres, reconciliations and the approval flow. A long tail of documents outside KSeF remains — foreign invoices, receipts, contracts — and that is where document reading is still needed.
Cost is driven by the number of channels documents arrive through, the accounting system, and the level of certainty the posting requires. A company where invoices arrive through one channel into one system is a different project from one with five mailboxes, paper and two systems. Upkeep is a separate line: per-document fees and periodic retesting after model version changes. We break all the components down in our note on what an AI implementation costs.
Yes — and offices are often a better candidate than a single company, because the same process repeats across dozens of clients, so the integration cost spreads over a larger volume. The difference concerns data: an office processes documents on its clients’ behalf, so the model provider’s part in that processing needs to be put in order in the office–client relationship as well. That is a question to settle before the project, not after it.
Tell us how they arrive and what takes the most time. We will say which stage we would start with — including when the answer is that it is not worth it yet.
Book a free consultation