Bank statements in enova365: your auto-match rate is set by your customers, not your software

Every enova365 installation I have opened can already import a bank statement. The Ewidencja Środków Pieniężnych module reads MT940, the raport bankowy appears, the lines land where they should. Nobody needs a consultant for that, and nobody should be charging for it.

What still costs an accountant three hours on a Monday morning is everything after the lines land: working out which open item each one settles.

And here's what you should know before spending money on that problem. Your ceiling — the share of lines that can ever be matched without a person looking at them — isn't a property of enova365, or of your accounting office, or of any agent I could build for you. It's a property of what your customers type into the payment title field.

You can measure that in an afternoon. Almost everybody buys first and measures afterwards.

Getting the statement in: three routes, and the boring one is usually right

The MT940 file. Every Polish business bank exports it. You define the format once per bank, point enova365 at the file, and the raport bankowy fills up. It's a next-day rhythm — exactly right for bookkeeping, useless for deciding whether to pay a supplier this afternoon.

The electronic banking add-on. enova365 sells direct connections to the major Polish banks. It costs another module and it takes the file shuffling away. It starts paying for itself roughly when one person is downloading from more than three banks, or when somebody upstairs wants the cash position during the day.

Pushing lines in from outside through WebAPI. Only necessary when the money arrives somewhere enova365 doesn't speak to — a payment provider, a factoring platform, a foreign account, a PSD2 aggregator covering fifteen accounts at once. The mechanics are the same ones I wrote up in the WebAPI developer guide, including the licence question that stalls more of these projects than any technical problem.

For most offices the first route is the right one and stays the right one. I'm labouring this because import is where automation conversations usually start, and it's not where the money is.

What enova365 already does on its own

The built-in automatic settlement matches a statement line to an open item when it can identify the counterparty and find exactly one candidate that fits the amount. Where your format definition pulls a document number out of the description, it uses that too.

It works. It isn't the bottleneck. The bottleneck is that it has to be certain, and certainty thins out fast as you move down a statement.

One thing about that mechanism deserves more attention than it gets: the payer's account number is the most reliable field on the entire line. A bank generates it. No human types it. If your contractor records hold account numbers, counterparty identification is nearly free.

In every installation I've looked at, a large share of contractor records have that field empty — because until somebody tried to automate reconciliation, nobody needed it. Filling it in is unglamorous data entry, and it moves the match rate further than any model I could put on top. Do that before you buy anything.

The description field is the whole game

Here's the audit. Export one month of incoming statement lines and sort them into four buckets:

1. Contains an invoice number that exists in your books. Parseable, correct, unambiguous.
2. Contains something invoice-shaped but wrong. An old number, their own order reference, "FV 12" with no year, a number with a slash where yours has a dash.
3. Contains a word, not a reference. "faktura", "płatność", "za towar", "przelew".
4. Empty, or a person's name.

The split I see: bucket 1 runs 55-80% in offices whose clients are companies invoicing on payment terms, and drops under 40% for anyone serving retail or a lot of small payers. The gap between two clients inside the same accounting office is routinely wider than the gap between two ERP systems.

Now read the buckets against what you already have. Bucket 1 is enova365's job and it's probably already doing most of it. Bucket 4 is a phone call and will stay a phone call — no model recovers information that was never written down.

Buckets 2 and 3 are the real territory. They aren't unsolvable. They need candidate ranking and a judgement about where the confidence threshold sits, and that's precisely the shape of work a rules engine handles badly and a well-scoped agent handles well.

Which gives you honest arithmetic instead of a promise. If bucket 1 is 78% and enova365 already settles 70% by itself, the room above that is around twenty points, and you'll realistically take twelve to fifteen of them. In a busy office, that's an hour a day. It is not "reconciliation is now automatic," and anyone who tells you otherwise hasn't looked at your statements.

Split payment: the one place the regulator handed you clean data

An MPP transfer carries a message with a mandated structure — the VAT amount, the payer's NIP, the invoice number and free text, each in its own delimited field, sitting inside the same description everyone else fills with prose.

Think about what that means. The compliance mechanism accountants complain about most is the only place in the Polish payment system where the invoice reference is standardised by law. If a meaningful share of your incoming payments run through split payment, part of your matching problem is already solved — and most implementations never touch it. They treat an MPP line as an awkward case, two amounts against one invoice, instead of as the best-structured record on the whole statement.

The general mechanics of net, VAT and gross across the two accounts are in the earlier post on bank reconciliation. What's specific to enova365 is narrower and easier to miss: your bank format definition has to pull those subfields out into something the matcher can see. Out of the box, that whole structured string often arrives as one blob of description text. Technically imported. Practically invisible.

The lines that never match, ranked by whether automation helps

One transfer covering eleven invoices. Solvable — it's a subset problem bounded by counterparty and date window. Worth automating early, because it's also the case humans find most tedious.

Partial payments and shortfalls. Solvable in mechanics, blocked on policy. What size of underpayment is a rounding difference, and what is a dispute? One złoty? Half a percent? Almost no office has this written down until somebody asks, and you can't automate a rule that doesn't exist yet.

Kompensaty. The customer paid short because they deducted their own invoice against yours. Nothing in the bank line says so. An agent can spot that the shortfall equals an open payable to the same entity, which is a genuinely useful flag nobody produces today. It can't post the compensation, because a kompensata is an agreement between two parties, not an observation about arithmetic.

Bank charges, interest, currency differences. Mechanical, high volume, dull, reliably automatable. Often the best first win — and the one that never makes it into a proposal, because it doesn't sound exciting.

The customer paid the wrong invoice. No system fixes this. Somebody picks up the phone.

The duplicate you will not notice

enova365 numbers imported statements and will refuse an obviously repeated raport. What it can't protect you from is the intraday file.

Several banks let you download a same-day statement before close and then issue the final one afterwards. Both files are legitimate. The second contains the first. Import both and you have quietly doubled a day's worth of lines.

Unlike a duplicated invoice, a duplicated bank entry trips nothing. It settles something. It surfaces five weeks later as a customer who appears to have overpaid, and by then nobody remembers which morning somebody grabbed the early file. Import only end-of-day statements into the books; if you want intraday data, keep it in a cash report outside them. This sounds too obvious to write down. I've watched it happen twice.

Where to start

Run the description-field audit before you talk to any vendor, me included. One month, four buckets, an afternoon of somebody's time.

If bucket 1 is above 75% and your contractor account numbers are filled in, your reconciliation is already about as good as the mechanics allow, and your automation budget belongs somewhere else — most likely on the document intake side, or on the KSeF status checks I described yesterday.

If buckets 2 and 3 together account for more than a quarter of your lines, you have a real project with a measurable size. Build it read-only: it proposes settlements into a queue, a person approves them, nothing posts by itself. That keeps the whole thing on the safe side of the boundary I described in who signs when the agent gets it wrong, and it turns the first month into a measurement of your true match rate rather than an act of faith.

One last number, once it's running. The metric worth watching isn't the match rate. It's how much of the month's cash is reconciled by the 10th — the same distribution question that decides whether the monthly close is a crunch or a routine.

Want to know which buckets your statements actually fall into? Write to me — send one anonymised month and I'll tell you the ceiling before anybody builds anything. Half an hour, no charge.