MT940 import in Comarch Optima: automatic settlement and the option that hides mistakes

One Dropdown, Two Kinds of Error

A month ago I wrote about MT940 bank statements in enova365 and argued that your auto-match rate is set by what your customers type into the payment title, not by your software. That holds for Comarch Optima too. But Optima has a detail enova365 doesn't, and it gets its own post because it changes what kind of mistake you end up with, not just how many.

When you import a statement in Optima with Rozliczaj przy imporcie switched on, you pick how it should settle each line. There are five options. Four of them do the careful thing when they aren't sure: they leave the line unsettled and tell you, Brak pary do rozliczenia. The fifth never has to say that. It settles the counterparty's open items from the oldest, whatever the customer meant to pay.

An unsettled line is a visible problem. Someone spots it on Monday. A line settled against the wrong invoice is invisible. The balance is right, the ledger closes, and the problem surfaces six weeks later as a dunning letter to a customer who paid on time.

Getting the Statement In

The mechanics are simple and well documented, so I'll keep this short. In Kasa/Bank → Zapisy kasowe/bankowe you pick the bank register and the report, then import. Optima has five built-in MT940 formats: the standard one plus bank variants (BGŻ, BRE, PBS, and Citi Handlowy for MT940/MT942). You can't edit them. You choose the one that matches your bank's file and set the code page (Windows-1250, ISO-8859-2, UTF-8 and a couple of older ones).

Two parameters deserve a second look:

• Dodawaj zapisy dotyczące innych rachunków. Some banks put several accounts in one MT940 file. Tick this in the wrong register and lines from the other accounts land in it. For an office with clients who keep a VAT account, a PLN account and a EUR account at the same bank, check this once per client and write the answer down.
• Format wymiany dla MPP. Split payment has its own format field, and it has to be the same kind as the main one: both file-based or both web service. If it's left empty, the VAT-account side of an MPP payment doesn't come in the same way.

Besides files there's the web service route (banks that support Comarch Data Connect) and dedicated quick imports for the big banks. For bookkeeping, the file is usually enough. Import is not where the hours go.

The Five Options, Read Carefully

Here is what each option does according to Comarch's own documentation, and what that means in practice.

1. wg identyfikatora. Optima looks for an Identyfikator operacji on the imported line and an open payment with the same identifier. This works well for outgoing transfers that Optima exported to the bank itself, because it wrote the identifier. For incoming customer payments it rarely finds anything, since your customer's bank has never heard of your identifier.

2. …then wg podmiotu i kwoty. If there's no identifier, it looks for an open item for the same counterparty with the same amount. Clean when a customer has one open invoice. When a customer has two invoices for the same amount (a monthly subscription, a fixed service fee), it takes the first suitable one. Usually that's the right one. Not always.

3. …then wg kwoty i opisu. Same amount, and the line's Opis has to contain the text from the payment's Numer obcy/Opis do banku field. This is the strictest option and the one that uses the payment title. It's only as good as what sits in that field on your side. Check what your installation actually puts there for sales invoices before you rely on it.

4. …then wg podmiotu i opisu. Same counterparty, and the description contains that text. Amount doesn't have to match, so it can settle a partial payment against the right invoice. Handy, provided your reference field is actually filled in.

5. …then chronologicznie wg podmiotu. Same counterparty, and it settles open items starting from the oldest. This is the one that never leaves a line unmatched if the counterparty is known. It's a policy, not a match. "The customer's money pays their oldest debt" is a reasonable collections rule. Polish civil law uses it too, in art. 451 of the Civil Code, but only when the debtor didn't say which debt they were paying. When your customer wrote FV/0412/09 in the title, they did say. The chronological option ignores it.

For most offices I'd pick option 3 or 4, depending on how reliably the reference field is populated. Option 5 only for clients where you've agreed in writing that payments settle oldest first, and even then, check every month how many settlements it made.

The Step Before Matching: Who Paid

None of the options helps if Optima doesn't know who paid. It identifies the counterparty first by acronym, then by bank account number. Customers don't type your acronyms into their transfers, so for incoming payments the account number does all the work. Every contractor record without one sends the line to !Nieokreślony!, and from there nothing settles automatically.

I reached the same conclusion in the enova365 post. It's also the cheapest fix you have: the payer's account number is generated by the bank and never mistyped. In the Optima databases I've looked at, a big share of contractor records have that field empty because nobody needed it before. An afternoon filling it in for your top fifty payers does more than any setting on this page.

Want a baseline? Import one month and count the lines on !Nieokreślony!. That number is your first target. Getting it takes a few minutes.

What's Left After Optima

Say you've filled in account numbers, picked option 3 or 4, and imported a month. Now look at what's still unsettled. In my experience it sorts into the same few piles in every office:

• Invoice-shaped but wrong. "FV 412" without a year, their own order number, a slash where you use a dash. The description check is a substring match, so near-misses fail.
• One transfer, several invoices. Optima settles a line against one payment. A customer paying eleven invoices at once is a subset problem: bounded by counterparty and date, and tedious for a person.
• Shortfalls. Is 1.20 zł short a rounding difference or a dispute? That's a policy question first. Most offices haven't written the answer down.
• Short payment that equals an open payable. Probably a compensation (kompensata) the customer made on their side. Nothing in the bank line says so.
• Empty title or a person's name. A phone call. No model recovers what nobody wrote.

The first three are where an agent that works next to Optima earns its keep. It reads the unsettled lines, ranks candidates (fuzzy invoice numbers, amount combinations, the counterparty's usual payment pattern) and puts a proposal with its reasoning in a queue. It doesn't settle anything itself. The general mechanics of that queue, the confidence threshold and MPP handling are in the post on bank reconciliation.

For an accounting office running forty Optima databases, the integration details matter: the agent reads through the Optima API per database, and it has to respect the limits I described in the post on Optima API throughput. Reading one month of unsettled lines is light work. Settling in bulk is not something to schedule at 8 a.m. on the 5th anyway.

A Check Worth Running This Week

If any of your clients uses option 5, run one test. Take last month's settlements made on import for that client. For each one, compare the invoice number in the transfer title with the invoice it was settled against. Count the mismatches.

If the number is zero, keep the option. If it isn't, you already have open items that are "paid" in Optima and unpaid in reality, and the reverse. Both will show up at the next reminder run or at the year-end balance confirmation, and fixing them later means unwinding settlements in a closed month.

That count, and the !Nieokreślony! count, are the two numbers I'd ask for before talking about any automation. If you want a second pair of eyes on them, send me one anonymised month and I'll tell you where the ceiling is for that client.