The accounting office's own system: four things it has to do before any automation lands

The Bottleneck Yesterday's Post Named and Left Standing

An accounting office almost never integrates with a client's ERP. It integrates with the channels documents already have to pass through, and since the KSeF mandate most of them pass through one. That was yesterday's argument and I still think it holds. But it leaves something dangling. Those channels have to deliver somewhere. A KSeF pull, a bank feed, an email intake — they all end in the same place, the office's own system. And that is where I have watched more automation projects die than anywhere on the client side.

The pattern repeats so reliably I can describe it before the kickoff call. The office buys or builds something that fetches documents, matches bank lines, drafts postings. The connector works on day one; everybody is pleased. Then the agent asks the office's system a question the system cannot answer, or tries to put a result somewhere that has no place for it, and within a few weeks the project has quietly turned back into a person with a spreadsheet. Nobody calls it a failure, because nothing broke. The system was simply never set up to be a counterpart for automated work. It was set up for people who carry the missing context in their heads.

So this post is about what the office's own system has to be able to do before anything else in this series applies. It is not a software comparison. Every product on the Polish market can do all of it. Almost no office has set its product up to.

Forty Clients, Forty Databases

Start with a fact that surprises everyone who has never worked inside an office: the mainstream Polish systems keep one database per company. Comarch ERP Optima does. enova365 does. The InsERT line does. For a company with one set of books that design is perfectly sensible. For an office with forty clients, it means forty databases — each with its own contractor cards, its own chart of accounts, its own settings, its own version state.

The office modules paper over that, for humans. Optima's Biuro Rachunkowe module gives you a list of companies, switching, batch operations, checklists across the lot. enova365 has its multi-company tooling and a client portal on top. A person sits in one interface and never feels the seams.

An agent feels every single one. Each database is a separate connection with its own credentials, so the service account question does not get answered once, it gets answered forty times — and on Optima each of those sessions takes an operator licence. Each database may have been upgraded on a different day, so the custom-field drift I described as one administrator's five-minute action becomes forty administrators, several of whom are the office's own junior staff. And each database has been absorbing data entry for years from whoever happened to be handling that client, with no cross-check against the other thirty-nine.

You cannot change the architecture. What you can change is the pretence that the office is one system. For estimating, for access, for monitoring, an office is a portfolio of small installations that happen to share a login screen. Everything below follows from that.

Four Questions Your System Has to Answer About Any Document

Here is the test I now run before I quote anything. Pick a document, any document, that arrived last week. Using only what the system shows — no asking a colleague — answer four questions.

Whose is it? Which client, which database. Obvious for a KSeF invoice, because the NIP sits in the structure. Much less obvious for the photograph a client's wife forwarded from her private email, or the scan with the header cut off, or the invoice from a supplier who serves three of your clients at once.

Where is it? The physical or digital location right now. In the intake platform, in a mailbox, in the buffer, in the ledger, in a folder on somebody's desktop called "do wyjaśnienia". In most offices at least two of those places sit entirely outside the accounting system, which means the system's answer is "not here" — and that is not the same as "does not exist".

What state is it in? Received, identified, queried, posted, rejected, waiting for the client. If the only states your system knows are absent and booked, everything in between lives in somebody's memory.

Who touched it last? Not for blame. For handover. The person who set a document aside on Tuesday because the VAT rate looked wrong is off on Thursday, and the document now belongs to nobody.

Run this on twenty random documents in an office that has never thought about it and the count of unanswerable questions lands between fifteen and thirty out of eighty. That is not a criticism of the staff. It is a description of where the process actually lives: in people, not in the system. An agent can only work with what the system holds. So the office's weak point is not the client's ERP — it is the twenty-five percent of the process with no representation anywhere a machine can read.

The State Between "Not Here" and "Booked"

Of the four questions, the third is where automation actually plugs in. It earns its own section.

Both Optima and enova365 have a state for a document that exists but has not yet been posted. Optima calls it the buffer, and I have written before about why an agent should stop there; enova365 has its own document states with the same effect. Most offices I visit use it one of two ways. Not at all, because posting straight to the ledger is faster and the reviewer is the same person as the poster. Or as a parking lot for problems, with no rule about what goes in or when it comes out.

An agent needs the buffer to be a workflow, not a parking lot. Everything the agent produces — a drafted posting, a matched bank line, a document assigned to a client, a flagged duplicate — has to land in a state that is visible, reviewable and not yet final. That is the second of the four permission levels, propose rather than write, translated into a concrete place in a concrete system. Skip it and you get one of two failure modes: the agent writes to the ledger and the office has to trust it completely from day one, or the agent writes to a side table and nobody ever looks.

Which gives you a question to answer before the first line of integration is written. What share of last month's documents went through the buffer at all? If the answer is under ten percent, the first month of the project is not a connector. It is changing how the office posts, so that a reviewed state exists for the agent to fill.

There is a bonus. Once the buffer is a real state, the share of documents in the system by the 10th stops being a number you estimate and becomes a number the system reports.

One Supplier, Forty Spellings

Now the contractor cards — where the forty-database problem does the most damage, and where almost nobody looks.

Take the three suppliers who appear on the most invoices across your portfolio. A fuel card operator, a telecom, an office supplies chain. Each exists once in the real world and once in KSeF. In your office it exists once per client database that has ever received an invoice from it, entered by whichever person handled that client that month. Export the contractor list from your five largest client databases and count. In the offices where I have done this, the same telecom shows up with between three and seven distinct spellings across five databases — and that is before you reach the cards with a missing NIP, a NIP with a typo, or the one entered under the name of the sales rep.

For a human it is a minor irritation. For matching it is fatal, because bank statement matching and invoice assignment both use the contractor as the join key. The agent looks up the supplier by NIP, finds three cards, and either guesses or stops. Every stop puts a document back in somebody's queue.

The fix is unglamorous, and it belongs to the office rather than the vendor: one canonical card per NIP per database, duplicates merged, the bank account number filled in from the last invoice. A week of junior work for a forty-client office. It moves the straight-through rate more than any model choice will, and it repeats the finding from the description-field audit in the bank statement post — the ceiling is set by the data the office already holds, not by the software anyone is about to buy.

The Way Back to the Client

The fourth thing the system has to do is the one nobody lists, because it points outward. Every automation that spots a missing document, a wrong VAT rate, an invoice with no order behind it produces a question for the client. Where does that question go?

In most offices: an email, typed by hand, by whoever noticed. Sometimes a phone call. Sometimes it waits for the monthly call. The client answers, or does not, and the answer lands in a mailbox the system cannot see.

If the agent generates the questions, the office needs a channel it can use without a person typing, and the client's answer has to come back to the document it concerns. The client portals attached to Optima, enova365 and the intake platforms exist for exactly this. Most are switched off, or were switched on for three clients as a test two years ago and never touched again. This is also where the KSeF authorisations live in practice: each client has to grant the office the right to pull their invoices, and an office with forty clients has forty grants to obtain, record and keep current. A channel that already reaches every client turns that into a mailing. Without one it is forty phone calls.

Do not automate the question until there is somewhere for the answer to land.

The Two-Hour Readiness Check

None of this needs a consultant to measure. Three exercises, two hours, done by the office itself.

1. Twenty documents, four questions. Random documents from last week, answered using only the system. Count the unanswerable ones. Above a quarter means the process lives in people.
2. Three suppliers, five databases. Export the contractor lists, count how many times each of your three most common suppliers appears. Divide by five. Anything above one is the duplicate rate you will be fighting.
3. Last month's buffer share. What proportion of documents passed through a reviewable state before posting? Under ten percent means there is nowhere for an agent's proposals to go.

Three exercises, three numbers. Each one tells you where the first weeks of a project have to go before a connector earns anything, and each predicts whether automation sticks better than the client's ERP, the vendor's demo or the office's headcount. In the implementation timeline post I called the access lag the best predictor of go-live. On the office side, this check is its counterpart.

What This Changes About the Order of Work

Yesterday's inventory tells you which channels to build and which two or three clients justify a connector. Today's check tells you whether the office can receive what those channels deliver. Run today's first. The channels are the cheaper part, and they are the part vendors want to sell you, because a working KSeF pull looks like progress. It is progress only if the documents it pulls land somewhere with a client, a state and an owner.

The order that has actually worked, in every office where the project stuck: contractor cleanup and buffer discipline in month one, with no automation at all; the KSeF and bank channels in month two, feeding the buffer; the first agent proposals in month three, reviewed by the same people who used to do the work by hand. Every office that skipped month one came back to it eventually. Later, and with a connector already running against dirty data.

Running an office and not sure whether your system would pass the four questions? Get in touch. The readiness check takes two hours, and I have yet to see one come back with all three numbers where they need to be. I have seen several come back with a very clear first month of work.