MT940 statements in Rewizor, Subiekt and Rachmistrz nexo: two matches, and the one nobody checks

Two Matches, Not One

This is my third post in a row on getting bank statements into Polish ERPs. enova365 came first, then Comarch Optima, where a single dropdown option can quietly settle the wrong invoice. InsERT's nexo line gets a post of its own, because in nexo the interesting part is somewhere else entirely.

When nexo imports an MT940 file, it matches twice. First it works out who the line came from, meaning which contractor card the payer belongs to. Then it works out what was paid: which open item (rozrachunek) the money settles. When people complain about auto-settlement, they're almost always talking about the second match. In the offices I've looked at, the first one has more say over the result. And almost nobody measures it.

If the first match fails, the second never runs. The line lands as a bank operation with no counterparty, and someone associates it by hand.

If the first match succeeds but picks the wrong contractor? The second runs perfectly. On the wrong customer.

Where the Import Lives

Rewizor nexo, Subiekt nexo and Rachmistrz nexo share one Bank module, so the steps are identical whichever program your client runs. According to InsERT's own help pages:

1. Open Bank, tab Operacje bankowe.
2. From Bankowość elektroniczna, choose Pobierz z pliku → MT940.
3. Pick the parser from the list.
4. Point to the file in Plik z wyciągiem and set the Strona kodowa.
5. Importuj, confirm.

From there the program settles automatically on three things: the operation title, the amount and the date. Anything it can't pair arrives as an unsettled bank operation, and someone settles it by association (skojarzenie).

Files aren't the only route. The Pro editions integrate with online banking for a list of banks, and third-party tools such as emSzmal pull statements from bank websites into the same module. For bookkeeping, the file is usually enough. As with Optima, the import itself isn't where the hours go.

Step Three Is the Real Setting

There's one sentence in the help page worth printing out and pinning up: the program will link customer data only from dedicated parsers.

The parser list mixes bank-specific parsers with more generic ones. Either kind will read a valid MT940 file. The difference is what happens to the payer details: the name, address and account number that counterparty recognition depends on. A dedicated parser knows where that particular bank puts them in field 86. A generic one may not. When it doesn't, those details never reach the line in a form nexo can use.

And nothing warns you. The file imports without an error, every operation is there, and the auto-settlement rate is just lower than it should be. Most people blame their customers' payment titles. Sometimes they're wrong.

This bites harder in an accounting office than in a single company. The parser is chosen per client, usually once, often years ago, by whoever happened to set up that client's bank account in nexo. The client moves to a different bank, someone picks whatever on the list reads the file, and the match rate drops by a third. Nobody connects the two events.

Check: for each client, write down the bank and the parser in use. Anyone on a generic parser whose bank has a dedicated one gets switched first. For forty clients that's about an hour's work, and it costs nothing.

Counterparty Recognition and the One-Click Guess

With the right parser, nexo tries to recognise the contractor from the statement data. When the data doesn't match a card exactly (the name on the bank line is "JAN KOWALSKI FHU", the card says "Firma Handlowo-Usługowa Jan Kowalski"), it shows candidates with a match coefficient, and a button: Najwyższy współczynnik dopasowania kontrahenta. One click assigns the top candidate.

As a way to save time, that button works. It's also exactly where a wrong counterparty gets confirmed. Two contractors with similar names, a sole trader and his limited company, a parent and its subsidiary: the top score is usually right. When it isn't, the settlement step runs cleanly on the wrong card. The payment settles an invoice for someone who never paid it, and the real payer's invoice stays open. You find out later, just as you do in Optima, when a reminder goes to a customer who's already paid.

The cheapest fix is the one I keep coming back to: the payer's bank account number on the contractor card. It's the only field on the bank line that the bank generates itself, so nobody mistypes it. A card with the account number filled in doesn't need a guess based on similar names. In the nexo databases I've seen, a large share of cards leave it empty, because the card was created from an invoice and an invoice doesn't need it.

Check: import one month for one client and count two things. First, operations that came in without a counterparty. Second, operations where the counterparty was assigned by the coefficient rather than an exact match. Nobody tracks that second number, and that's where the invisible errors live.

What the Settlement Step Can and Can't Do

Get the counterparty right and title-amount-date settlement handles the lines it was built for well: one transfer, one invoice, the number in the title. nexo adds a couple of useful extras. In Subiekt nexo you can link a bank transfer order (dyspozycja bankowa) to a supplier order, and the statement settles it automatically. Split payment (MPP) has its own operation type, so the VAT portion isn't squeezed into a single-amount match.

What's left after a clean import falls into the same piles I described for Optima and enova365:

• Looks like an invoice number, isn't quite. "FV 412" without the year, the customer's own order number, a different separator.
• One transfer for several invoices. A subset problem. Counterparty and date narrow it down, but it's still tedious work for a person.
• Shortfalls. A few złoty short: rounding, a bank fee or a dispute? Your office needs a policy on that before it's a matching question at all.
• Empty or useless titles. Pick up the phone. No model recovers what nobody wrote.

I've covered bank reconciliation more generally (the queue, the confidence threshold, MPP) in the post on automating bank statement booking.

Where an Agent Fits in nexo

An agent working alongside nexo reads the unsettled operations and the open items. For Rewizor and Subiekt it does that through Sfera, the programmable layer I covered in the Rewizor nexo integration post and the Subiekt nexo Sfera guide. For clients without a Sfera licence, it works from a periodic export. For each leftover line it ranks the candidates (near-miss invoice numbers, amount combinations, how that contractor usually pays) and drops a proposal, with its reasoning, into a queue. An accountant approves or rejects it.

One job matters far more in nexo than in the other two systems, and it's the most valuable thing the agent does here: auditing the first match. For every operation assigned by coefficient rather than by account number, it checks three things. Does the settled invoice's number appear in the title? Does the amount fit that contractor's payment history? Does another contractor with a similar name have an open item for exactly that amount? Anything suspicious goes into the queue before the month closes, not after the reminders have gone out.

It settles nothing itself, and it leaves the parser and card settings alone. It reports "client 17 is on a generic parser, 38% of lines came in without a counterparty", and a person decides.

Two Numbers Before Any Automation

If you keep your clients' books in nexo, pull two numbers for one client and one month:

1. Operations imported without a counterparty, plus the parser that client uses.
2. Operations assigned by the match coefficient, and how many of those, checked by hand, went to the wrong contractor.

The first shows how much you lose before settlement even starts. The second shows how many settlements in closed months are quietly wrong. In my experience the first number falls sharply after a parser switch and an afternoon spent filling in account numbers. No automation required. The second is where an agent pays for itself.

Want a second opinion on those numbers? Send me one anonymised month and I'll tell you which of the two is your real problem.