MT940 statements in Symfonia Finanse i Księgowość: the unsettled amount becomes a new transaction

The Amount Doesn't Wait in a Queue

This is the fourth post in my series on getting bank statements into Polish accounting systems. enova365 came first, then Comarch Optima, then InsERT nexo, where the counterparty match matters more than the settlement rule. Symfonia Finanse i Księgowość gets its own post because it treats the leftovers differently from all three.

In most systems, a statement line the program can't settle stays visibly unsettled. Someone spots it in a list and deals with it. Not in Symfonia. In the advanced import, the line is posted anyway. If the payer was recognised, the money goes to that counterparty's account, and the part not matched to a specific invoice becomes a new transaction on that account. Symfonia's help says it plainly: the unsettled amount goes to the reconciled account, and a new transaction is created for it.

The general ledger doesn't mind. The balance on the customer's account is correct to the grosz. The open-items list is another matter: the invoice is still open, and next to it sits a payment of the same amount that settles nothing. Mechanics first, then why this hurts most in November.

Where the Import Lives

In both the ERP line and Symfonia 50, the path is the same: Import danych → Zaawansowany import wyciągów bankowych. You click Pobierz wyciągi, pick the bank account, confirm with Użyj and point to the file. Accepted extensions are .txt and .mt940. The import runs in the background, so you click Odśwież dane after a moment. The statement also lands in Dokumenty → Przeglądanie → Repozytorium dokumentów, together with the source file. Handy later, when someone asks what the bank actually sent.

The same help page lists three limitations. Know them before you plan anything:

• No currency accounts. The advanced import doesn't handle statements from foreign-currency accounts. EUR and USD statements need a different route, and with them the exchange-difference work I described in the post on FX differences on bank statements.
• Chronological posting. Statements must be posted in date order.
• Re-importing means deleting. Want to import the same statement again? First delete the accounting document it created, then the statement in the repository.

Three Steps of Uzgodnienia

The work happens when you click Uzgodnienia. Symfonia fills in the account, the settlement, the due date, the formula that matched and the counterparty, in three passes.

Step one: reference numbers. Symfonia compares the reference numbers of executed e-transfers with the statement lines and settles the matching transactions automatically. No other step settles against a specific invoice without anyone touching it. It covers payments the client sent from Symfonia's own e-transfers. A supplier invoice paid that way closes itself. A supplier paid by hand in the banking app doesn't.

Step two: the payer's bank account. Lines are assigned by matching the bank account number against the counterparty, employee, tax office or person cards. The account symbol and parameters come from the default formulas #Kontrahent, #Pracownik, #Urząd and #Osoba. If the account isn't on any card, Symfonia opens a search window on the counterparty file. You pick the contractor, the account is added to the card, and next month that payer is recognised automatically. You can also skip: Pomiń for this line, Pomiń rachunek for every line from that account, Pomiń wszystkie.

One detail from the help catches people out: employees, tax offices and persons aren't reconciled automatically. Only counterparties are.

Step three: the remaining formulas. Anything still unassigned runs through the other formulas. These set the account symbol, the posting description, and whether a new transaction is created and with what due date. Formulas with a filled-in Rachunek field take priority over card matching.

That last rule closes the tax office gap. Every client pays PIT, CIT and VAT to its own mikrorachunek podatkowy, and all ZUS contributions to one individual contribution account. Those numbers never change. Put each one in a formula with the right ledger account and those lines no longer need a human every month.

The Transaction Table Is Where the Hours Go

Below the list of operations sits a table of open transactions for the selected line: amount to settle, document number, due date, days overdue, account. To settle, tick a row or type an amount in the Rozliczenie column. Right-click for Rozlicz transakcje and Usuń rozliczenie. The settlement can't exceed what's left on the transaction, and the total can't exceed the amount of the operation.

Here's the arithmetic for a typical distribution client. The numbers are illustrative, not measured:

Statement lines in a month	410
Outgoing e-transfers sent from Symfonia, settled in step one	132
Supplier payments made by hand in the bank, no reference	8
Customer payments recognised by bank account (step two)	205
Customer payments from accounts not on any card	25
Fees, ZUS, tax, salaries (step three, if formulas exist)	40

Step one does real work here. The 205 recognised customer payments are a different story: Symfonia knows who paid, but someone still has to tell it what was paid. At 30–40 seconds per line, with the invoice list open in a second window, that's about two hours a month for one client. And two things make it worse.

Clicking Uzgodnienia again wipes it. The help is explicit: clicking Odśwież dane or Uzgodnienia a second time removes all manual changes and settlements. Spend an hour in the table, re-run the reconciliation to pick up a new formula, and you start from zero.

Skipping costs nothing today. Leave the table untouched and Księgowanie still posts the statement to the buffer. The 205 payments go to the right accounts as new transactions. Nothing blocks. Nothing warns. Most offices I talk to only notice when they need the open-items list for something.

Why This Matters in November

In November the office needs that list for three things.

• Balance confirmations. If the client sends confirmations from an open-items list where paid invoices sit next to unapplied credits, the customer replies with a dispute. I covered the process in the post on year-end balance confirmations.
• Bad-debt relief. The relief starts from an overdue list. An invoice that's "90 days overdue" on paper but was paid in March is the worst candidate for a VAT correction. Details in the post on bad-debt relief in VAT.
• Write-downs. Receivables write-downs come from the same ageing, so every paid invoice left in it inflates them.

Checking this takes one export. For each counterparty account, put open invoices and unapplied credits side by side. Flag pairs with the same amount, and credits equal to the sum of two or three invoices. If a client has skipped the table for a year, I'd expect most of the "overdue" total to be pairs like these.

Where an Agent Fits in Symfonia

An agent working alongside Symfonia doesn't touch the import or the formulas. Its input is an export of the open items and unapplied credits, plus the statement lines with their titles. For each unapplied credit it ranks candidate invoices by exact amount, the invoice number in the transfer title (typos included), sum combinations, and how this customer usually pays. Every proposal goes into a queue with its reasoning. An accountant approves it and settles it in Symfonia. I covered the queue and the confidence threshold in general terms in the post on automating bank statement booking.

It also reports what it can't fix: "client 12 has no formula for its tax mikrorachunek, 9 lines went to manual review", or "25 customer payments came from accounts not on any card". A person decides.

Two Numbers Before Year End

Before you automate anything, get two numbers per client on Symfonia:

1. The share of customer payments settled against an invoice in the last full month, not just assigned to a counterparty.
2. The number of unapplied credits on receivables accounts that sit next to an open invoice of the same amount.

First above 90%, second close to zero? The client is in good shape. If not, fix it before the confirmations go out. Not after the replies come back.

Want a second pair of eyes on those numbers? Send me one anonymised export of open items and I'll tell you how much of the overdue list is real.