Your clients run six different ERPs. That is not the problem you think it is

Six Systems, One Objection

No, you don't need six integrations. Every accounting office I sit down with raises the same objection inside ten minutes, always as a piece of arithmetic — and the arithmetic is the one part that holds up.

It goes like this. Forty clients. Optima here, enova365 there, three on Subiekt, a handful on wFirma, one stubborn manufacturer running something nobody has heard of since 2011. Six systems, maybe eight. So automation means six connectors, six maintenance obligations, six things that break in six different weeks. At that price, obviously, it doesn't pay.

Right sum, wrong premise. In the ordinary case an accounting office doesn't integrate with its clients' ERPs at all. It integrates with the places documents already have to pass through — and there are far fewer of those than there are clients.

The Documents Already Flow the Other Way

The work happens in your system, not theirs. That is the structural fact the six-systems objection walks straight past, and once you put it back the estimate changes shape entirely.

A client's ERP sits upstream of you. Its job is to run that company — stock, orders, production, salespeople. What you need out of it is a stream of documents, and that stream doesn't travel down a database connection. It travels through KSeF, through the bank, through email, through whatever document portal your office already runs. Each of those channels is one integration for the whole portfolio.

So the honest question isn't "how many ERPs are there?" It is "how many channels do our documents actually arrive through, and how good is each one?" In most offices the answer is three or four. Two of them are usually half-automated already, by accident.

A direct connection into a client's Optima or enova365 is a real project, and sometimes the right one. It earns its place only when you need something the document itself cannot carry: cost centre allocation living in the client's own dimensions, a production order reference, stock valuation at month end, a project code nobody ever types onto an invoice. Those are specific, nameable needs. "We should probably integrate" is not one of them.

What KSeF Flattened, and What It Left Alone

KSeF took the client's ERP out of the equation for roughly half your document volume and changed nothing in the other half. That split is now the most useful line you can draw across an office's automation plan.

On the flat side: sales invoices, and purchase invoices from any domestic supplier issuing through the system. They arrive as structured FA(3) XML, through one API, under one authorisation model, with the seller's NIP, amounts, rates and line items already sitting in fields. Whether the client who issued them runs Optima, Subiekt or a spreadsheet with a KSeF plug-in makes no difference at all. Pulling invoices from KSeF is one build, done once, serving the whole portfolio.

On the fragmented side, everything else. Bank statements still arrive per client, per bank, in formats that are standard on paper and something else in practice. Payroll stays in the client's system or yours. Inventory movements, internal documents, foreign supplier invoices, the petrol station receipt — none of it goes near KSeF, and none of it got any simpler in 2026.

Which means the sequencing writes itself. Automate the flat half first, properly, for everyone. Then go after the fragmented half where the volume actually sits — and the volume is not spread evenly. That is the next point, and it is the one that decides budgets.

The Concentration Curve: Which Three Clients, Not Which Six Systems

Sort your clients by monthly document count and the question stops being about software. In the offices I have measured, the top five clients carry somewhere between half and two thirds of all documents in a forty-client portfolio, and the bottom fifteen together carry less than one of the top five.

That curve, not the system inventory, is your build order. A per-client connector has to repay itself in hours saved on that one client, and a client producing thirty documents a month can't repay anything — however irritating those thirty documents are to process. The irritation is real. It just isn't an integration problem. It's a channel problem, and you're solving the channel for everybody anyway.

There's a sharper version of the test, and I use it in every scoping conversation because it ends the argument in one answer: would you still build this integration if the next client refused to have one? If yes, you've found a genuine per-client need. If the case only holds up because you'll roll it out across the portfolio later, you're about to fund a pilot with money that belongs to a rollout that will never happen — because the next client runs something else.

Put that next to the distribution metric from month-end in an accounting office: the share of a month's documents sitting in the system by the 10th. Forty per cent means everything gets processed under deadline pressure. Above eighty per cent means the crunch has stopped being structural. Run the number per client rather than for the office as a whole, and the two or three clients dragging the average down turn out to be the same names at the top of the volume curve. That overlap is your project.

A Connector Is a Subscription to Someone Else's Release Calendar

The build is the cheap part, and almost nobody prices the rest. A connector into a client's ERP is a standing obligation to a system you don't control, maintained against decisions nobody will tell you about in advance.

None of this is hypothetical. An administrator adds a field to a contractor card and your mapping quietly reads it as empty — the custom fields trap, where absent and empty look identical to anything consuming the data. A client migrates from Subiekt GT to nexo over a weekend, which is not an upgrade but a different product, and your integration finds out from a phone call on Monday morning. An Optima database on SQL Server Express meets the 10 GB ceiling nobody has looked at since installation. A version drops out of support.

None of those are your errors. All of them are your incidents, at your cost, usually in the client's worst week of the month. So price the connector as a monthly line with a named owner. And before anyone signs, write down which of those events you'll detect yourself and which you'll hear about from the client. The second list is always longer than people expect, and its length is the real risk in the project. For the technical side of that comparison across the three systems you'll meet most often, see the ERP API comparison for integrators.

What Does Not Get Cheaper

Two things stay exactly as expensive as they were. Pretending otherwise is how automation projects in accounting offices lose their credibility in month three.

The first is your own system. Every document that arrives cleanly still has to be booked according to a scheme specific to one client's chart of accounts and one client's habits. A structured invoice from KSeF takes away the retyping and the reading errors. It does not decide which account a marketing agency's subcontractor invoice belongs on. The rules generalise far less readily than the data does, and your own system is where the remaining bottleneck lives.

The second is bank reconciliation, capped by something nobody controls: what your clients' customers type into the payment title. The description-field audit sorts a month of incoming lines into four buckets, and the parseable-reference bucket runs 55–80% for clients with business customers on payment terms and under 40% for clients with retail or a long tail of small payers. That spread between two clients inside one office is wider than the spread between two banks or two ERPs. You can also measure it before buying anything, which makes it the best hour you'll spend on this whole question.

The Half-Day Portfolio Inventory

Before you quote anything, build one table: a row per client, six columns. It takes an afternoon, and it has changed the plan in every office where I have run it.

1. Monthly document count, split sales / purchase / bank lines. This is the volume curve.
2. Share in the system by the 10th — the distribution metric, per client.
3. Which channel each document type actually arrives through today. Not the official answer. The real one, including the client who still emails photographs.
4. What you need that the document does not carry — cost centres, project codes, stock, or nothing. A blank cell here means no connector is justified, whatever the client runs.
5. The client's system and version, plus who administers it. A client with no administrator is a client whose system will change without warning.
6. Hours per month spent on this client that are pure transcription. The only column that pays for anything.

Sort by column 6, filter by column 4, and the list of clients worth a direct integration usually comes out two or three names long. Everything else gets handled by the channel work you were going to do anyway, for the whole portfolio, once. The cost side of that sits in what an accounting AI agent costs.

Where This Leaves the Six Systems

Where they were, mostly. That's the point. The number of ERPs in a client portfolio describes your clients' businesses; it is not an estimate for your automation. Treating it as one is what has stopped a lot of offices from starting at all.

The work that pays sits in front of those systems, not inside them: one KSeF path, one bank path, one honest inventory of what still turns up as a photograph, and a very short list of clients large enough to justify a connector of their own. That list will be shorter than the system list. In every office I have worked with, shorter by a factor of ten.

Running an office where every client seems to be on something different? Get in touch. The inventory above takes an afternoon, and I have never once finished one without at least one client moving out of the "we need an integration" column and into the "we needed a channel" column.