Automation in an accounting office: why forty clients is a different project from one company

Author: Published:

How to cost automation in an accounting office: onboarding each client, documents from many channels, KSeF access, and what to settle with clients before AI.

Guides to accounting automation usually describe one company: one invoice mailbox, one chart of accounts, one system. An accounting office has one bookkeeping system, but dozens of clients on the other side, each sending documents their own way. That is why automating an accounting office is a different project from automating one company — in four places the guides skip: the cost arithmetic, taking in documents from many channels, access to KSeF (Poland’s national e-invoicing system, through which businesses issue and receive invoices) on behalf of clients, and the office–client relationship once an AI model provider joins the processing.

The forty clients in the title are an example for the arithmetic, not a description of a particular office. Software vendors explain well how to set up KSeF invoice downloads in their products; we do not repeat that. We write about what their instructions leave out: how to cost a project across many clients, and what to settle before it starts.

Where the time actually goes in an office

Guides for a single company focus on posting itself. In an office, much of the work happens earlier: collecting documents from clients, working out which document belongs to which client, chasing missing invoices and bank statements, and catching up on everything at once at month end, when clients send the full set at the last minute.

We give no proportions here, because every office differs, and averaged figures from the internet tell you nothing about yours. Before you automate anything, log your time over a full monthly cycle — including the month-end close — in three categories: collecting and sorting documents, chasing clients, posting. That split will decide where to start — we come back to it below.

The multiplier: one integration, forty clients

In our piece on what an AI implementation costs we described six things that set the price: integrations, the state of the data, the required level of certainty, the cost per operation, oversight, and change in the organisation. In an office the same factors fall into three kinds of cost, which behave quite differently as the number of clients grows:

  • The shared part — built once: the connection to the office’s bookkeeping system, the screen on which the bookkeeper approves proposals, monitoring, error handling.
  • Onboarding a client — repeated for each one: KSeF permissions, the channels the client sends documents through, their chart of accounts and standing rules (which supplier, which account).
  • The cost per document — for every invoice: the AI model fee and the minutes of the person who checks the result.

Let us count only the first two, the one-off costs; the cost per document and maintenance come on top. Assume, in arbitrary units, that the shared part costs 200 and onboarding one client costs 5. For one company the bill is 205. In an office with forty clients the shared part is spread across all of them: 200 divided by 40 is 5 per client, plus 5 for onboarding — 10 per client in total. That is the economy of scale everyone mentions when selling automation to offices.

Now change one assumption: onboarding a client is not configuration but a small project, and costs 50. The shared part still comes to 5 per client, but the total is now 55. That is still less than the 250 a single company would pay with the same onboarding, so scale still helps — but almost all of the cost per client is now onboarding, which no number of clients will spread. The cost per document is not spread either: with similar volume at each client, having forty clients means forty times as many invoices and a model fee forty times as large.

The conclusion for an office: onboarding client number 41 should be configuration, not a project. The more onboarding costs, the greater the gain per client has to be for the project to pay back. Before you buy a tool or commission an implementation, ask how long adding the next client takes, who does it and what it requires from the client. The answer “it depends on the client” means you are closer to the second variant than the first.

Taking in documents: one system at the end, many channels at the start

On the output side the office has one bookkeeping system and one way of posting. On the input side it has as many channels as clients: one sends invoices to the bookkeeper’s personal mailbox, another to the office’s shared address, a third uploads them to a portal, a fourth brings in a ring binder. The multiplier works on the output side and breaks on the input side, because every new channel is a new rule to maintain.

KSeF has standardised much of the input: domestic purchase invoices from businesses arrive as data in one format, downloaded the same way for every client; the office downloads the sales invoices the client has issued in KSeF the same way too. It has not covered everything, though. Invoices from suppliers with no registered office or fixed establishment in Poland may arrive outside KSeF, because those suppliers are not obliged to issue them there. Contracts, bank statements and payroll documents remain outside KSeF, and until 31 December 2026 invoices from cash registers, and receipts with a tax number up to PLN 450, may also stay outside. Until the end of 2026 the smallest clients may also issue sales invoices outside KSeF — the PLN 10,000 gross monthly limit counts only invoices that as a rule must be issued in KSeF, and once it is exceeded the obligation stays. We write more about what KSeF changes in our piece on KSeF and accounting automation.

So the project for an office starts with the question of how documents from many channels reach one queue with the client assigned. When the tax number on a document is legible, a rule is enough, not a model: on a purchase invoice the buyer’s tax number identifies the client, on a sales invoice the seller’s, and the system matches it against the office’s client list. When both parties to an invoice are the office’s clients, the same document is one client’s sales invoice and the other’s purchase invoice — whose document is being processed is decided by the KSeF download context or a channel uniquely assigned to that client. If such a document arrives through a shared channel and it is unclear which client it was sent for, a person approves the assignment. A document with no legible tax number, with one not on the list, or with several conflicting ones goes to a person. An AI model can then propose which client a scan, a contract or an email with several attachments from different companies belongs to, but that proposal must be visibly marked as uncertain — a document dropped into the wrong client’s queue is a mistake that does not even exist in a single company. How such rules are joined up in practice with a tool for automating flows between systems is described in our n8n guide.

KSeF access on behalf of clients: position as at 12 October 2026

The Ministry of Finance and the accounting software vendors cover this topic well, so we give only the mechanism and what an office should record on its side.

  • The client grants the permission to the office as a company — to the office’s tax number, not to each employee separately. Access to invoices (viewing and downloading them) is a separate permission from issuing invoices. The client can tick an option allowing the office to pass the permissions on to its staff; the office then names the people itself.
  • The client cannot see which of the office’s employees have access. They only see that they authorised the office. The record of who in the office can access which client’s invoices therefore has to be kept by the office.
  • Downloads happen separately for each client, in the context of that client’s tax number. For automatic downloads by software, a KSeF token (a secret string of characters the software uses to authenticate with KSeF) or a KSeF certificate (a digital credential with which the software confirms who is connecting) is used. A KSeF certificate is valid for at most two years, and one certificate can work in the contexts of many clients — what it can do depends on the permissions granted in each of them.
  • The rules on tokens changed this year. The KSeF 2.0 handbook of February 2026 announced tokens until the end of 2026; the Ministry’s questions-and-answers page, amended on 8 October 2026, says the Ministry has decided to keep tokens indefinitely. Before the project, check the current instructions on the KSeF website.
  • The office cannot relinquish a permission on its own — it can only be revoked by the client or by the person managing permissions on the client’s behalf. Ending work with a client therefore needs a procedure on both sides.

Software handles this in different ways. According to the Comarch ERP Optima documentation, to download a client’s invoices the office needs a token, a KSeF certificate, or a qualified signature or electronic seal, and the token can be generated by the client and sent to the office, or by the office once the client grants it permissions. You need to check who generated the token: the Ministry of Finance’s KSeF handbook does not allow a token generated by a natural person to be used by anyone else. SaldeoSMART recommends one certificate on the office’s tax number to serve all clients who have granted it permissions, notes that the client does not hand over their certificates, passwords or tokens, and lets you set automatic downloads every hour. According to the same instructions, whether a client has actually granted the permissions only shows when an invoice download is attempted.

For each client the office should therefore have on record: who granted the permission, when and in what scope, which token or certificate the office connects with and until when it is valid, when invoices were last downloaded successfully, and who in the office has access. That record is also a ready checklist for onboarding client number 41.

The office, the client and the model provider: what to settle before you change the contract

The GDPR (General Data Protection Regulation) distinguishes the controller, who decides why data is processed, from the processor, who processes it on the controller’s instructions. Who is who in a project with an AI model is set out in point 4 of our piece on GDPR and implementing a language model. Here, only what changes in an office, in the typical arrangement: the office processes personal data from documents on the client’s instructions and engages an external model provider to process it for the same purpose. The provider then does not create a new relationship but adds a link to an existing one — it is a further processor, that is a company processing data on the office’s behalf. Whether that holds for the chosen service is for the office and its lawyer to confirm.

Article 28(2) of the GDPR requires the prior specific or general written authorisation of the client as controller (an authorisation to sub-process — not the same as consent from the people whose data appears in the documents); under a general authorisation the office informs the client of intended changes, and the client may object. If a tax adviser works in the office, they are also bound by professional secrecy under Article 37 of the Polish Tax Advisory Act.

The wording in the contract with the client, and whether a general authorisation is enough, are for the office and its lawyer to settle. On the technical and organisational side, it is worth deciding before the project:

  1. Which data leaves the office. Check on a sample of documents whether the supplier, the line items and the amounts are enough to propose a posting (assigning an invoice to accounts) — without bank account numbers, addresses or employee data. What the model never receives does not need protecting on its side.
  2. Which model provider, in which region and on what terms — where it processes data, how long it keeps it, and whether using it to train models is switched off. That is checked in the terms of the specific service, not assumed.
  3. What obligations bind the model provider. Article 28(4) of the GDPR requires the same data protection obligations the office has towards the client to be imposed on the further processor. Whether the contract with the provider ensures this is for the office and its lawyer to check.
  4. What authorisation the office has from each client — specific or general, with what date, and how the client was informed of the change.
  5. What happens when a client refuses. The project should let you switch the model off for one client without rebuilding the whole thing.
  6. What the office changes in its documentation. If it keeps a record of categories of processing activities (Article 30(2) of the GDPR), it reflects the changed processing to the extent that provision requires; it is worth linking the provider’s details and the authorisation to sub-process to each client’s file. The scope is for the office and its lawyer to settle.
  7. What you will tell the client in plain words: which documents go through the model, why, and who approves the result.

We write more about how we treat data in projects on our security and GDPR page.

Where an office should start: missing documents before posting

On our accounting automation page we describe the principle that AI prepares and a person approves; in an office, the order matters more than what you automate.

The best candidate for a first process is usually tracking missing documents, for a simple reason: it works by the same rule for every client. The system compares what it expects (regular suppliers from previous months, payments on the bank statement with no document) with what has arrived, and prepares a list of possible gaps and a draft reminder. A person in the office checks the list and the recipient, then approves sending it — a “possible gap” is not yet a gap, because a regular supplier may have sold nothing this month. The process needs neither the client’s chart of accounts nor the history of their postings, so it stands a chance of meeting the condition from the second section: onboarding the next client as configuration. Test that on a few clients who send documents through different channels before you assume it holds for you — mailbox access, statement formats and client exceptions may still take work.

Posting comes second. It needs each client’s chart of accounts, rules and history separately, so its onboarding cost is high. Start with the clients who have the most documents a month, across whose invoices that cost is spread the furthest.

What to measure

  • Client onboarding time — how many minutes adding the next client takes. This is the number that tells you whether the multiplier works.
  • Documents per client per month — the distribution, not the average. Check whether most of the volume comes from a few clients.
  • Channel shares — how many documents arrive from KSeF, by email, through a portal and on paper.
  • Days to a complete set — how many days after month end pass before the office has all of a client’s documents.
  • KSeF invoices downloaded without manual work — what share reaches the queue on its own.
  • Exceptions per client — which clients most often need something corrected by hand.

When it is not worth it

  • Too few documents per client. If most clients have a handful of invoices a month, the cost of onboarding each of them may exceed the saving — work it out on your own numbers.
  • Every client is a different system. If the office has no single bookkeeping system and works in its clients’ systems instead, the shared part stops being shared.
  • Clients will not grant KSeF permissions or accept the model provider. Then a path without the model is needed, and for some clients automation will be limited to taking in documents.
  • Your software already does it. Check whether your accounting software already downloads invoices from KSeF and suggests postings before you commission a build.
  • Most documents are on paper. Start with taking in documents and scanning them in one place; we can talk about the model later.

What next

An accounting office runs a process that suits automation well — repeatable, with a person who approves the result, and with a number you can measure before starting. That is how we describe processes on our page about AI automation. The difference is that in an office the project wins or loses on the cost of onboarding a client and on order in the relationship with clients, not on the model itself. Write to us with how many clients you have, how many documents a month come from the largest of them and through which channels. We will say which process we would start with — including when the answer is “not yet worth it”.

Sources: position as at 12 October 2026

Frequently asked questions

Can an accounting office download its clients' invoices from KSeF without their login and password?

Yes, and that is exactly how it should work. KSeF has no logins: every session requires authentication, and access follows from permissions. The client grants the office, as a company identified by its tax number (NIP), the permission to access invoices (separate from the permission to issue them) and may allow the office to pass it on to its staff. The office's software then authenticates with a KSeF token (a secret string of characters) or a KSeF certificate (a digital credential), separately in the context of each client's NIP. The client does not need to hand over their login details, and should not hand over their personal certificate. Position as at 12 October 2026; check the details in the Ministry of Finance's current instructions.

How many clients does it take for one integration to pay off?

There is no single number. It depends on how much the office gains per client and on the proportions of three costs: the shared part built once, onboarding each client, and the cost of each document, plus maintenance. Scale spreads only the shared part. The less onboarding a client costs, the fewer clients it takes for the project to pay back; the more each client is a small project of its own, the greater the gain per client has to be. Before you ask for a price, ask the provider how long adding the next client takes and what it requires, and put your own numbers into that arithmetic.

Does the client have to know that their documents go through a language model?

If personal data reaches the model, in the typical arrangement yes. The office processes the data on the client's behalf, and a model provider processing it on the office's instructions for the same purpose is a further processor, that is a company processing data on the office's behalf. Article 28(2) of the GDPR (General Data Protection Regulation) requires the prior specific or general written authorisation of the controller, that is the client (an authorisation to sub-process — not the same as consent from the people whose data appears in the documents); under a general authorisation the office informs the client of intended changes, and the client may object. The provider's role in the specific service, the form of the authorisation and the wording in the contract are for the office and its lawyer to settle. Technically, it is worth planning from the start for one client refusing, and being able to switch the model off for that client alone.

Who is responsible when the model misclassifies a client's invoice?

The model only proposes; a person in the office approves the posting, just as they approve a junior bookkeeper's work today. The split of responsibility between the office and the client comes from the contract and the law, not from the tool, and introducing a model does not shift it onto the provider. That is why the project must leave a trail: what the model proposed, who approved it and what they corrected. How to describe this in the contract with the client is for the office and its lawyer to settle.