Every wire transfer above PLN 15,000 sent to a bank account that isn't on the Polish Ministry of Finance VAT whitelist can cost you more than the transaction itself. And yet most Polish SMEs still check that list by hand — open the browser, paste the tax ID, click "search", eyeball the account number. Every day, dozens of times.
We do these VAT whitelist integrations regularly and the pattern is always the same. The company makes 40–100 wire transfers a day. A dozen of them cross the PLN 15,000 threshold. The accountant — or worse, the owner in the evening — opens the Ministry of Finance page and checks each account one by one. 30–60 seconds per transfer. An hour a day vanishes in clicks. Meanwhile a single integration between the MoF API and the ERP would end the whole problem.
At one of our clients — an 18-person paint and construction chemicals wholesaler from the Wielkopolska region — the head accountant was spending 45 minutes a day manually checking the VAT whitelist for 60–90 daily transfers, of which 12–15 crossed the PLN 15,000 threshold. After integrating Comarch Optima with the Ministry of Finance API, verification happens automatically when the transfer is created — a warning appears immediately if the account isn't registered. The manual check disappeared. ROI in under three months.
Why this isn't optional
The VAT whitelist isn't a recommendation — it's a legal obligation under Article 96b of the Polish VAT Act. If you pay more than PLN 15,000 gross (from 2026 the threshold also applies to transactions settled in instalments) to an account that isn't on the MoF list on the day of the transfer, the consequences are twofold and both sting.
First, you lose the right to book that expense as a deductible cost. The whole amount goes back into the CIT/PIT base. At 19% tax and a PLN 30,000 invoice that's PLN 5,700 you'll never recover. All because of one missing click.
Second, you become jointly liable for the VAT that your counterparty owes. If the supplier doesn't remit the VAT, the tax office can come to you for it. You don't even need to know the supplier defaulted — it's enough that the money went to an unregistered account.
There's an emergency exit — a ZAW-NR notification to the head of the tax office within 7 days of payment. But that's a corrective procedure after the fact. It's much cheaper to simply not pay to a wrong account.
Manual checking: why it fails
Someone will say, "but we do check". Yes, you check. The problem is you check differently than the law requires.
Manual verification in a Polish SME usually goes: the accountant opens the invoice, copies the tax ID, pastes it into the MoF page, sees whether "the account number is in the list", moves on. That's very close, but not quite there. The three most common mistakes that cost money:
- Checking on the wrong day. The law requires the account to be on the list on the day you order the transfer, not the day the invoice was issued. If you check when booking the invoice, then pay three days later — and the supplier disappears from the list in the meantime — you have a problem, even if you documented the first check.
- No verification archive. The MoF keeps a historical list, but if you don't have your own record proving "on 15 July, account X was active", proving it two years later during a tax audit is painful.
- Checking one account when the invoice has several. Proforma and final invoices sometimes carry different accounts. Sometimes the supplier changed banks and sent an update by email that the accountant never saw. Money goes to the old account — which is no longer on the list.
Automation solves all three, because the verification happens exactly at the moment the transfer is created, and its result lands in the ERP database next to the payment. It's always clear what was checked and when.
Three levels of automation
You don't need to jump to the complicated version straight away. In practice we see three levels that make sense to build in order.
Level 1 — flat file. The Ministry of Finance publishes a daily CSV file with every registered account (a few hundred megabytes). You download it once a day and match locally. Simple, cheap, works even in Excel with a macro. Downside: the file is one big dump with no history — if you want to prove "on that day the account was on the list", you need to archive successive files yourself.
Level 2 — JSON API. The MoF exposes a REST API (https://wl-api.mf.gov.pl) that lets you query by tax ID or account number. The response includes a request identifier — that's the "receipt" you can later show during an audit. The API is free, but rate-limited to about 30 requests per second per IP. Plenty for any SME.
Level 3 — verification built into the ERP. The best version. Verification fires automatically when the accountant (or a workflow) creates a payment. If the account isn't registered, the ERP won't let the process continue without an explicit operator decision (and a recorded reason). The result — with date and request identifier — is stored alongside the payment.
Comarch Optima has had this built in since 2020 ("Biała lista VAT" module). enova365 supports it natively too. Subiekt GT/nexo — there's an add-on from Insert, but a custom API integration also works. Microsoft Dynamics 365 BC — for the Polish localisation you usually add a module or write your own connector. In every scenario the cost is measured in days of work, not months.
Worth checking at the same time
Since you're already writing code that hits the MoF API ten times a day for a counterparty tax ID, it's worth looking at what else you can verify in the same round-trip.
- VAT status (active/exempt/deregistered). The same MoF API also returns the taxpayer status. A previously active VAT payer that's been deregistered is a clear red flag — not always a scammer, but always worth a conversation.
- KRS company data via the MoJ API. The Ministry of Justice offers a free API to the National Court Register. You can automatically pull the management board, share capital, company status. If the counterparty is in bankruptcy or liquidation, you want to know before you send money.
- Tax ID validation via GUS/REGON. The free GUS API lets you confirm that the company really exists under a given tax ID, and check the name and address. A good place to catch typos in tax IDs when setting up a counterparty record.
- IBAN checksum validation. A simple checksum test — if it doesn't match, there's a mistake somewhere, before the MoF even weighs in.
All of this together is less "protection against the whitelist rule" and more a proper, verified counterparty database — the kind you want to have regardless of taxes. The AI we've written about elsewhere needs exactly this: clean, verified, consistent counterparty data.
Where to start
The practical order we use with clients:
- Check whether your ERP already supports the whitelist (Comarch Optima and enova365 do — ask your integrator, it might just need to be switched on and configured).
- If it doesn't, size the problem: how many transfers per day, how many cross the PLN 15,000 threshold, how much time the accountant really spends on it.
- Pick a level of automation from the list above. Level 2 (JSON API) with the request ID stored in the database is enough for most SMEs.
- Design the process: what happens when verification returns "no". Who decides, who signs off, when do we file a ZAW-NR.
- Archive the verification results. Two years is the minimum, five years is the comfort zone for a tax audit.
If you're not sure which step your company is on, half an hour of conversation is usually enough to figure it out. No PLN 100,000 project pitch — most of the time this is weeks of work, not quarters.
The VAT whitelist isn't really about taxes. It's about no one in your company ever having to paste tax IDs into a browser form again.