Poland White List (Biała Lista): VAT Verification Guide

Poland's White List (Biała Lista), officially known as the Wykaz Podatników VAT, is a public register of bank accounts linked to active VAT taxpayers in Poland. Established under Article 96b of the Polish VAT Act and maintained by the Head of the National Revenue Administration (Krajowa Administracja Skarbowa, or KAS), the register has been in force since September 1, 2019. Its purpose is straightforward: every business making a qualifying B2B payment to a Polish supplier must confirm that the recipient's bank account appears on this register before releasing funds.

The consequences of skipping this step are severe. Paying to a bank account that is not listed on Poland's White List means the entire payment loses its tax deductibility, and the payer assumes joint-and-several liability for the supplier's unpaid VAT. Both consequences activate automatically from a single unverified transfer.

Poland White List VAT verification becomes mandatory when all three of the following conditions are met:

The transaction value exceeds PLN 15,000 gross per transaction (approximately EUR 3,500 at current rates, though the statutory threshold is always denominated in PLN).
The transaction is B2B and documented with an invoice — consumer transactions and non-invoiced payments fall outside the obligation.
The payment is made by bank transfer to an active VAT taxpayer registered in Poland.

One critical detail: the PLN 15,000 threshold applies per transaction, not per individual payment. Splitting a single invoice across multiple smaller transfers does not eliminate the verification obligation. If the underlying transaction exceeds the threshold, every payment against it must go to a verified account.

Timing matters equally. The Poland VAT White List data is updated daily, so verification must be performed on the day the payment order is placed. Checking a supplier's account days or weeks before the actual transfer is not sufficient — the account's status could change between verification and payment, and the date of the payment order is what the tax authorities will examine.

The Biała Lista VAT register itself contains a range of data for each listed entity: the company name, NIP (Numer Identyfikacji Podatkowej, Poland's tax identification number), current VAT registration status, REGON and KRS numbers, registered business addresses, names of legal representatives, registration and removal dates, and the bank account numbers reported to the tax authority. For verification purposes, the two fields that matter most are the NIP and the associated bank accounts.

For AP teams, this translates to a concrete workflow requirement: extract the supplier's NIP and bank account from every qualifying invoice, then verify both against the White List on the day the payment order is placed. This is not a one-time vendor onboarding step — it is a mandatory pre-payment verification repeated for every qualifying transaction.

Penalties for Paying to an Unverified Bank Account

Paying a Polish supplier to a bank account not listed on the White List triggers two automatic sanctions — and for AP departments running payment batches, either one can turn a routine payment run into a material financial exposure.

Loss of tax deductibility. The entire payment amount becomes non-deductible for income tax purposes (CIT or PIT). Not just the VAT portion. The full gross value of the invoice is disallowed as a business expense. For a PLN 50,000 invoice paid to an unverified account, the company loses PLN 50,000 in deductible costs, directly increasing its taxable income by that amount.

Joint and several VAT liability. The buyer becomes jointly liable for any VAT the supplier fails to remit on that transaction. If the supplier disappears or defaults on their VAT obligation, the tax authority can pursue the buyer for the full VAT amount. Using the same PLN 50,000 example, the buyer faces potential liability for the 23% VAT (PLN 11,500) on top of the lost deduction.

These consequences are automatic. There is no good-faith exception, no "we didn't know" defense, and no discretionary waiver from the tax office. If the bank account was not on the White List on the day the payment order was placed, the sanctions apply regardless of the buyer's intent or whether the underlying transaction was entirely legitimate. The PLN 15,000 threshold that triggers verification is a gross amount per transaction, meaning most B2B invoices in Poland fall squarely within scope.

Poland designed these penalties to be deliberately punitive. The White List register was one component of a broader, multi-pronged strategy to close the country's VAT gap, alongside the split payment mechanism and centralized electronic invoicing (KSeF). The approach worked: according to the World Bank's analysis of Poland's tax compliance reforms, Poland more than halved its VAT gap from 25% to 9.9% between 2015 and 2018, making it one of the top three performers in the EU for VAT gap reduction. The severity of the penalties is the enforcement mechanism that drives that result. Buyers who absorb the compliance burden of verification effectively police the system on the government's behalf, and the penalties ensure they have no financial incentive to skip the step.

For AP departments processing invoices from Polish suppliers, this means Poland pre-payment compliance is not a best practice recommendation. It is a direct financial liability that compounds with every unverified payment. A single overlooked invoice creates a quantifiable tax loss; a pattern of missed checks across dozens of supplier payments can produce material exposure on the company's balance sheet.

Recovery Options: ZAW-NR Notification and Split Payment

When a payment run sends funds to an unverified bank account, Polish tax law provides two distinct remediation mechanisms. Each one addresses a different consequence, and neither alone provides full protection. AP teams building exception-handling procedures need to understand exactly what each mechanism fixes and what it leaves exposed.

ZAW-NR Notification: Restoring Tax Deductibility

The ZAW-NR form is a formal notification submitted to the seller's tax office. Filing it within 7 days of the transfer order restores the buyer's right to treat the payment as a tax-deductible expense. Without this filing, the entire payment amount is permanently excluded from deductible costs under CIT or PIT.

The 7-day deadline was extended from the original 3-day window that applied when the White List regulations first took effect in 2020. The current 7-day period runs from the date the transfer was ordered, not the date funds settled.

The ZAW-NR form requires:

The seller's name, tax identification number (NIP), and registered address
The bank account number that received the payment
The transaction date and amount
Identification of the tax office responsible for the seller

One critical limitation: filing ZAW-NR does not cancel joint-and-several liability for the supplier's outstanding VAT. Even after a successful filing, the buyer remains potentially liable for the seller's unpaid VAT obligations related to that transaction.

Split Payment Mechanism: Canceling VAT Liability

Using the split payment mechanism (MPP) when paying to an unverified account eliminates joint-and-several liability for the supplier's VAT arrears. The MPP directs the VAT portion of the invoice into the seller's dedicated VAT account, which the tax authority controls, reducing the risk that VAT funds are misappropriated.

However, split payment does not restore tax deductibility. A payment made to an unverified account via MPP remains non-deductible for CIT/PIT purposes. This distinction catches many AP teams off guard. They assume that using MPP resolves all White List penalties, but the deductibility loss persists unless a ZAW-NR is also filed. For details on when split payment is mandatory — including the Annex 15 goods and services categories that require MPP regardless of White List status — see our guide on Poland's split payment mechanism and Annex 15 requirements.

Using Both Mechanisms Together

Mechanism	Restores tax deductibility	Cancels VAT joint liability
ZAW-NR notification	Yes	No
Split payment (MPP)	No	Yes
Both combined	Yes	Yes

When a payment to an unverified account has already been executed, filing ZAW-NR within 7 days and confirming that MPP was applied to the transaction provides the most complete protection available. ZAW-NR recovers the deduction; MPP removes the VAT exposure.

AP departments should formalize this as a standard exception-handling procedure. Any payment flagged post-execution as having gone to an unverified account triggers two parallel actions: immediate preparation of the ZAW-NR form for submission to the seller's tax office, and verification that the split payment mechanism was applied to the original transfer. Documenting both steps with timestamps creates an auditable compliance trail that demonstrates the organization acted within the statutory window.

How to Verify a Supplier on Poland's White List

All verification methods draw from the same underlying data source: the register maintained by the National Revenue Administration (Krajowa Administracja Skarbowa, or KAS). The differences between methods come down to throughput, automation capability, and audit trail quality. Choosing the right approach depends on how many Polish supplier payments your AP team processes.

Manual Lookup via the Ministry of Finance Website

Best for: Occasional use, 1 to 10 invoices per month.

The Ministry of Finance provides a free online portal where you can search the White List by NIP (tax identification number) or bank account number. You enter the supplier's details, and the system confirms whether the entity is registered and whether the bank account appears on their White List entry.

This method works well for businesses with a small number of Polish supplier relationships. It costs nothing and requires no technical setup. The drawbacks are significant for anything beyond occasional use: there is no batch capability, no built-in audit trail, and no way to integrate results into your accounting system. Each verification is a manual, one-at-a-time process. If you need to document your due diligence for tax purposes, you will need to screenshot or otherwise record each result yourself.

Official Government API

Best for: Moderate volume, up to 300 queries per day.

KAS provides a free API that returns verification results programmatically. You can query by NIP, REGON, or bank account number and receive structured responses confirming a supplier's registration status and bank account validity.

The 300-query daily cap is the critical constraint. For a small-to-mid-size operation processing a few dozen Polish invoices per day, this is sufficient. For larger AP departments, the limit makes it impractical as a primary verification channel, though it can serve as a useful fallback when other methods encounter downtime. The API is well-documented and straightforward to integrate with existing ERP or AP automation systems.

Flat File Download

Best for: Bulk and enterprise operations running thousands of verifications.

The Ministry of Finance publishes a daily encrypted flat file containing the full set of NIP-to-bank-account mappings from the White List. Large enterprises download this file and run batch verification locally, matching their supplier payment files against the registry data without making individual API calls.

The advantage is clear: no query limits and no dependency on external service availability during processing. Verification runs entirely on your own infrastructure. The disadvantage is that this approach requires internal tooling to decrypt, parse, and match the flat file against your supplier master data. Organizations without development resources to build and maintain this tooling should consider the alternatives below.

Third-Party Verification APIs

Best for: High-volume AP departments needing up to 15,000 verifications per hour.

Commercial API services wrap the government's White List data with substantially higher rate limits, historical lookup capabilities, and dedicated integration support. These services typically offer pre-built connectors for major ERP platforms, structured audit logs, and SLA-backed availability.

For large AP departments and organizations with ERP-integrated payment workflows, third-party APIs eliminate both the volume ceiling of the government API and the development burden of the flat file approach. The trade-off is cost: these are paid services, and pricing typically scales with query volume.

Regardless of method, remember that verification must happen on the date the payment order is submitted — not earlier. The White List also supports a five-year historical lookback, meaning tax authorities can retroactively check whether a supplier's bank account was registered on the specific date you made a payment. Your verification records should capture both the result and the exact date of the check.

Integrating White List Checks into Your Invoice Payment Workflow

Turning the White List obligation into a repeatable AP process requires mapping it against your existing payment cycle. The verification is not a one-off compliance task — it must run for every qualifying B2B payment above PLN 15,000. Below is a four-step workflow that embeds the check directly into your invoice-to-payment sequence.

Step 1: Invoice Receipt and Data Capture

Every qualifying invoice that arrives — whether as a PDF attachment, scanned document, or e-invoice — needs to be captured and queued for processing. At this stage, the goal is simply to get the document into your system and flag it for verification based on the transaction value and B2B status.

Step 2: Extract the NIP and Bank Account Number

Before any verification can happen, two data points must be pulled from each invoice: the supplier's NIP (Numer Identyfikacji Podatkowej, Poland's tax identification number) and the bank account number specified for payment. These are the inputs to the White List lookup.

For AP teams processing dozens or hundreds of Polish invoices per month, manual extraction is where errors compound. A mistyped digit in a 26-character IBAN or a transposed NIP means a failed verification — or worse, a payment to an unverified account that triggers joint liability. Automated invoice data extraction tools can capture NIP and bank account fields directly from incoming invoice documents, along with all other standard invoice data, eliminating the transcription risk. Rather than having staff read each PDF and key in numbers by hand, platforms that automate invoice data extraction for Polish supplier verification parse these fields at the point of intake, making them available for downstream checks.

Step 3: Verify the Bank Account on the Day of Payment

This is the step with the hardest workflow constraint. The White List check must be performed on the same calendar day the payment order is submitted to your bank. A verification run three days before payment offers no legal protection — the registry is updated daily, and the law ties your safe harbor to the status on the payment date.

This timing requirement means the verification cannot live at the invoice receipt stage. It must be embedded in the payment approval step. In practice, this looks like a gate in your payment run: before the batch is released, each payment is checked against the White List API using the NIP and bank account extracted in step 2. Only payments with a confirmed match proceed.

For teams running weekly or biweekly payment cycles, this means building the verification into the day-of-payment routine. If your ERP or AP system supports API calls, the check can be automated as part of the payment batch workflow. If not, a manual check on the Ministry of Finance portal is required for each payment — which is feasible for low volumes but becomes a bottleneck at scale.

Step 4: Payment Release or Exception Handling

Payments where the bank account is confirmed on the White List proceed normally. The verification response (including the request ID) should be logged for audit purposes.

When a bank account is not found on the White List, the payment must be held. Do not release it under time pressure. The most common causes for a failed match:

The supplier registered a different account. They may have multiple bank accounts but only registered certain ones with the tax office. Contact the supplier and request they either provide a registered account or update their White List entry.
The supplier is not an active VAT taxpayer. If the supplier has been deregistered, struck off, or was never registered for VAT, their accounts will not appear on the White List. If the supplier is genuinely not VAT-registered, the White List verification obligation does not apply to the transaction — but confirm this status independently, as deregistration may indicate the supplier has compliance issues of their own.
The account is held at a foreign bank. Foreign bank accounts are excluded from the Polish White List registry entirely. Payments to foreign accounts require a different compliance approach (covered in the next section).

For each exception, your AP team should have a documented escalation path: hold the payment, notify the supplier with a specific request, set a follow-up deadline, and track resolution. Unresolved exceptions should be escalated to the finance controller before any payment is released to an unverified account — the joint liability and lost deductibility consequences are too significant to bypass on a judgment call.

With accurate NIP and bank account extraction at intake, every downstream step — verification, exception handling, audit logging — flows from reliable inputs rather than manual lookups.

Edge Cases: Foreign Accounts, Timing Gaps, and KSeF

Standard White List verification works well for domestic payments to established Polish suppliers. The complications arise at the edges: foreign accounts, registration delays, timing mismatches, and new supplier onboarding. These are the scenarios where AP teams encounter verification failures and need clear procedures rather than guesswork.

Foreign Bank Accounts

The White List contains only Polish bank accounts. When a Polish VAT-registered supplier invoices you with a foreign bank account — an EUR account held at a German or Dutch bank, for example — that account will not appear in the White List database regardless of the supplier's registration status.

Payments to foreign accounts are excluded from the White List verification obligation entirely. The 15,000 PLN threshold and associated penalties do not apply to these transactions.

The critical step for AP teams is correctly identifying whether an account is actually foreign. Check the IBAN prefix: any country code other than PL indicates a foreign account. A Polish supplier maintaining a EUR account at a Polish bank will still have a PL-prefixed IBAN, and that account is subject to White List verification. Do not assume that foreign currency means foreign account.

Supplier Bank Account Changes

A supplier updates their bank account with the tax office, but your verification query returns no match. This is one of the most common failure scenarios in practice.

The White List is updated once per business day. Between the time a supplier registers a new account and the time that account appears in the database, there is a lag — typically one business day, but occasionally longer if the registration was submitted late in the day or required manual processing.

AP teams need a defined hold procedure for this scenario:

Flag the payment when verification fails against the White List
Contact the supplier to confirm they have registered the new account with the tax authority
Hold the payment until verification succeeds on a subsequent business day
Document the hold reason and verification attempts for audit purposes

Paying to an unverified account because the supplier says registration is pending exposes you to the same penalties as any other unverified payment. The ZAW-NR notification window starts from the payment date, not from when you discovered the mismatch.

Verification Timing Gap

White List verification must correspond to the day the payment order is placed. This creates a specific operational risk: if your AP team verifies a supplier's account on Monday but the actual bank transfer is not initiated until Tuesday, Monday's verification is not valid for Tuesday's payment.

This matters because the White List can change between business days. An account verified as active on Monday could theoretically be removed by Tuesday's update. The verification and the payment order must fall on the same calendar day.

For organizations where payment approval and bank submission happen on different days, this means either restructuring the workflow so verification runs on the day of bank submission, or accepting that verification must be repeated. Batch payment runs are particularly susceptible — if you verify 50 suppliers on Monday for a Wednesday payment run, all 50 verifications need to be redone on Wednesday.

New Suppliers

A supplier that has just registered for VAT may not yet have their bank account reflected on the White List. The registration process involves the supplier submitting their bank account details to the tax authority, which then publishes them in the next database update cycle.

Before making the first payment to any new Polish supplier above 15,000 PLN, verify their bank account against the White List. If verification fails, hold the payment and request the supplier confirm their account registration status. Build this check into your supplier onboarding workflow rather than discovering the issue at payment time.

For new supplier relationships, consider making the first payment via split payment mechanism as a protective measure until you can confirm stable White List presence across multiple verification attempts.

KSeF and the White List: Complementary Obligations

Poland's KSeF (Krajowy System e-Faktur, the National e-Invoicing System) addresses a different verification problem than the White List. KSeF verifies invoice authenticity — confirming that an invoice was actually issued by the claimed supplier through the government platform. The White List verifies the payment destination — confirming that a bank account belongs to a registered VAT taxpayer. One validates the document, the other validates where the money goes.

Starting August 2026, KSeF reference numbers must appear in payment titles, linking each bank transfer to a specific authenticated invoice. This tightens the connection between invoice receipt and payment execution but does not eliminate the need for separate bank account verification.

KSeF does not replace the White List obligation. Both systems will operate in parallel, and AP teams must satisfy both requirements independently. The practical benefit of KSeF for White List compliance is that structured e-invoices deliver the supplier's NIP and bank account as machine-readable fields, making it simpler to extract the data needed for automated White List API queries. The verification step itself remains mandatory — KSeF just makes the input data more reliable and easier to process programmatically.

For AP teams, the practical preparation step is ensuring your payment systems can accommodate KSeF reference numbers in transfer descriptions by August 2026. If your current payment workflow already captures invoice reference numbers from incoming documents, the transition is straightforward — the KSeF reference replaces or supplements the existing invoice number field in the payment title.