Most Polish SMEs treat the bank statement like a postcard from the 1990s: download the file from online banking, click "import" in the ERP, then accountant manually matches the payments to invoices. Meanwhile, since 2019, every major Polish bank has published an API that does this for you — you just need to wire it up.
We do these integrations regularly, and the pattern is repeatable. A company has three accounts in two banks, two currencies, an ERP (most often Comarch Optima or enova365), and one person in accounting who spends two hours every Monday morning importing and matching statements. Every week, all year. That's hundreds of hours of work no one would do if they had a choice.
At one of our clients — a 25-person automotive parts wholesaler — the accountant was losing 8 hours a week on manual statement imports from three banks (mBank, Santander, ING) into Comarch Optima and matching them to sales invoices. After API integration plus rule-based matching by transfer descriptions and amounts: 30 minutes a week to manually check the exceptions. The rest happens on its own, overnight. ROI — under four months.
What manual statement processing really costs
It's easy to underestimate the scale. "Fifteen minutes a day" sounds like nothing. Count it differently — over a year.
A typical wholesaler with two PLN accounts and one foreign currency account sees 50–80 transactions a day. The accountant opens the bank portal, downloads MT940 or CSV, opens the ERP, clicks "import", picks the file, waits, checks what loaded, matches payments to invoices — usually by amount and a fragment of the customer name. Sometimes it has to be fixed manually because the bank wrote the counterparty in a different format than what's in the customer file. Five to ten hours a week in a good week. In a bad week — twice that, because you have to figure out why a customer paid 4,873 PLN instead of 4,873.15 PLN.
Then there's the cost of delays. Sales people can't see in the ERP whether an invoice has been paid, so they call accounting. Customers get reminders even though they paid Friday afternoon — because the statement "will be posted on Monday". Small things, but together they cost trust and time.
What a Polish bank can do today, and what your ERP can
Polish banking is surprisingly well prepared here. Every bank that serves business clients — mBank, ING, Santander, Pekao, PKO BP, Millennium, Alior, BNP Paribas — exposes a PSD2-compliant API (AIS) that lets you pull balances and statements programmatically. Some banks also offer accounting-dedicated APIs with richer data (mBank CompanyNet API, ING Business API, Santander mojeID Business).
On the other side — your ERP. The situation depends on the system:
- Comarch Optima has a built-in "Comarch ERP Optima Virtual Account" module and Comarch Bank Connect integration for selected banks. Works, but not every bank is supported out of the box.
- enova365 has a "Bank Desktop" module and supports electronic banking in Webservice/Multicash standards.
- Subiekt GT/nexo reads MT940 and CSV but has no native API integration — you need a middleman.
- Microsoft Dynamics 365 BC / NAV — has bank connectors, but for Polish banks often needs a dedicated solution.
In practice: even if your ERP "doesn't have an integration with bank X", you can usually build one with middleware — a small service connecting the bank's API to the ERP's API. Literally a few hundred lines of code in .NET or Python. Not a six-month project.
Payment matching — this is where the work actually is
Pulling statements is 20% of the problem. The rest is matching the payment to the invoice. Sounds simple: there's an amount, there's a description, there's a counterparty. In reality — it varies.
Typical challenges:
- The customer pays for two invoices with one transfer (with a description like "INV 123, 124").
- The customer pays the amount reduced by a complaint that was never filed through the system.
- The description says "payment for invoice 12/06/2025" — is that a number or a date?
- The payment comes from a private account (spouse, external accountant), not from the company account in the customer file.
- The customer pays for an invoice from the previous year, after which their tax ID changed.
In practice, sensible matching uses layered rules: first look for a perfect match (invoice number in description + amount matches), then fuzzy matching (invoice number is there, but the amount differs by less than 1 PLN — probably rounding), then matching by number alone, then manual review of the rest. A well-configured system catches 85–95% of payments automatically. The rest stays with a human — and that's fine, those are precisely the cases where someone needs to think.
A 4-step rollout plan
This is how such a project typically looks at a 20–50-person client. Realistically 6–8 weeks from decision to production.
- Week 1–2: audit and decisions. List the bank accounts, currencies, typical payment scenarios, the ERP and its version. Decision: ERP-native integration or middleware. Pick the bank to start with (ideally the one with the highest traffic — you'll see the benefit fastest).
- Week 3–4: bank API access and sandbox. This is where most of the formalities sit — banks require contracts, eIDAS certificates for PSD2, sometimes a branch visit. Worth starting immediately, in parallel with development work.
- Week 5–6: implementation and testing. Connecting the bank's API with the ERP, configuring matching rules, plugging in the customer file. The most interesting discoveries appear at this stage — e.g. 200 customers in the file have a tax ID with spaces, and 80 have none at all.
- Week 7–8: parallel run and handover. For two weeks the manual import keeps running, with the integration running alongside. Every day you compare results. After two weeks, when everything matches, you switch off the manual import.
Most common mistakes
Three things that usually hurt the most:
- No integration monitoring. If the middleware stops working at 3 a.m., nobody knows until Monday morning. A simple alerting setup (email/Slack) for bank authorisation errors and for missing statements over 24 hours is essential.
- Messy customer file. Back to our favourite theme — without clean data every integration is just louder chaos. Worth cleaning up tax IDs, names and bank account numbers in the customer file first.
- Over-aggressive auto-matching. The temptation to "post everything automatically" is strong. But if the system confuses two customers with similar names, untangling it will eat more time than automation saved. Better to leave the dubious cases for manual review.
What next
Bank-to-ERP integration is one of those projects where ROI is easy to calculate and easy to show. An hour of an accountant's time costs a few dozen zloty, and you typically recover 5–10 hours a week. Over a year that's tens of thousands of zloty less cost and — more importantly — an accountant who has time for the things that genuinely require a human.
If you're wondering whether such a project makes sense in your ERP + banks setup, the fastest way to find out is a 30-minute call. No deck, no slides — the questions you need to answer are predictable.
You don't need a data warehouse to stop copying statements from online banking into the ERP. You need an API and a few dozen hours of work.