VAT white list check in n8n: verify Polish contractors from a sheet before paying

VAT white list check in n8n: verify Polish contractors from a sheet before paying#

In Poland, anyone paying an invoice above 15,000 PLN should check that the supplier's bank account is in the VAT taxpayer register, known as the white list. In small companies the routine looks the same everywhere: a spreadsheet of contractors and someone pasting tax numbers one by one into the Ministry of Finance search page.

This n8n workflow takes that job over. It reads the sheet, drops invalid tax numbers, queries the official API and returns one of four verdicts per row.

Checksum first, API second#

A Polish NIP has a check digit. A typo in the sheet can be caught without asking anyone, so the first step normalises the number (dashes and spaces removed) and checks the weights.

function checksumOk(nip) {
  if (!/^\d{10}$/.test(nip)) return false;
  const w = [6, 5, 7, 2, 3, 4, 5, 6, 7];
  const sum = w.reduce((acc, weight, i) => acc + weight * Number(nip[i]), 0);
  return sum % 11 === Number(nip[9]);
}

A NIP that fails this check gets INVALID_NIP, whatever the API says.

Four verdicts instead of a raw response#

The API returns result.subject with a statusVat field. An active taxpayer has the value "Czynny" there. The workflow reduces this to four states anyone can read without knowing the API:

If the sheet has a bank account column, the workflow compares it with the accountNumbers list from the register (spaces removed). account_on_white_list is then true or false. Without the column it stays empty, because missing data is not the same as a negative result.

The output starts with a summary such as "3 of 40 contractors need attention before payment". That is the one number someone looks at every morning.

The API limit#

For longer lists you need batched requests (up to 30 NIPs at once) or to split the sheet across days.

Configuration#

The schedule is weekdays at 7, before anyone starts making transfers.

Limitations#

The result stays in the n8n execution. The template does not write verdicts to the sheet or send an alert, so when it runs on the schedule you need to add one of those steps. Otherwise the morning run tells nobody anything.

A NIP rejected by the checksum still reaches the HTTP node, which fails and is skipped. With 100 requests a day it is better to filter those rows out before the request.

The API response contains a request ID that can serve as proof the account was checked. The template does not store it.

The check is for the day of the run, not the day of the transfer. If payment goes out a few days later, check again.

When it does not make sense#

With a handful of regular suppliers a manual check takes a minute, and some banks check the register when you order a transfer. The workflow makes sense when there are dozens of contractors and the payment list is prepared in a spreadsheet before it goes to the bank. If the same should happen inside your accounting system or a team panel, that becomes a process automation project for your company, and for company records you can also enrich companies from a NIP with KRS data.