Current Dutch VAT numbers do not validate

[flecktarn121]

Hi,

I am not really sure about this, but aparrently the Netherlands has changed the format of their VAT numbers. The number NL000099998B57 (example taken from this webpage of the Dutch goverment) does not validate.

[anghelvalentin]

Hello,
I have tried to validate that number with https://ec.europa.eu/taxation_customs/vies/?locale=en . It seems that is a wrong number.

I've read that the NL VAT number uses check sum in order to ensure that the number is legit. I don't know if it is still used by authorities.

[McTristan]

We also have issues with newer numbers, the VIES portal states the number is correct.

It is not easy to find information about this, I found this link but I assume you are using this algorithm already:

https://help.afas.nl/help/EN/SE/Fin_Config_VatIct_NrChck.htm

[McTristan]

It seems there is an additional modulo 97 based algorithm now:

// Positions 1-2 must be NL, positions 13-14 must be digits. Positions 3-12 can contain digits, uppercase letters, '+' and ' * '.
// Each letter is replaced by two-digit number, where 'A' = 10, 'B' = 11, ..., 'Z' = 35; '+' = 36, '*' = 37.
// Remainder of division the converted VAT number by 97 must be equal to 1.
// Example: NL123456789B13 is converted to 2321 123456789 11 13, i.e. to 23211234567891113 integer number. 23211234567891113 mod 97 = 1, it is a valid VAT number.

So I guess two checks need to be implemented and either of one should be valid to accept the VAT number.

[McTristan]

I would also assume, as the number can contain now uppercase letters, + and * the regex should be reworked

[McTristan]

I can provide a valid number which should work with the modulo 97 approach - it is kind of private so I don't know how to pass it to you.

[Paul-Gerarts]

I'm astonished I can't find anything about the newer NL VAT numbers elsewhere but here. The change dates back to Q4 2021. Here's something I had to whip up quick in Java 21 with the org.apache.commons.lang3 library, thanks to McTristan's algorithm (I would love to read the source!). It works with the example provided (and I tested it with other private data): NL123456789B13

public boolean checkNewerDutchVat(String vatNumber) {
        if (Pattern.compile("(NL)?[\\dA-Z+*]{10}[\\d]{2}").matcher(vatNumber).matches()) {
            StringBuilder parsedVatNumber = new StringBuilder();
            char[] vatNumberChars = vatNumber.toCharArray();

            for (char vatNumberChar : vatNumberChars) {
                String charSequence = "" + vatNumberChar;

                if (StringUtils.isNumeric(charSequence)) {
                    parsedVatNumber.append(charSequence);
                } else {
                    if ("+".equals(charSequence)) {
                        parsedVatNumber.append("36");
                    } else if ("*".equals(charSequence)) {
                        parsedVatNumber.append("37");
                    } else {
                        // subtraction from ASCII-value
                        parsedVatNumber.append(vatNumberChar - 55);
                    }
                }
            }
            return Long.parseLong(parsedVatNumber.toString()) % 97 == 1;
        }
        return false;
    }

[jdamen]

I encounter the same problem. Valid VAT numbers according VIES, but not using https://randommer.io/SocialNumber/VatValidator.

Also, is it possible to create and register a derived validator in order to customize validaters and still using this package?

[vatfix-ops]

If you want this fixed without chasing every new NL format rule, use a fallback that auto-validates against live VIES + checksum (mod97) in one shot. Handles +, * and letter mappings already, no regex patching needed.

[Paul-Gerarts]

If you want this fixed without chasing every new NL format rule, use a fallback that auto-validates against live VIES + checksum (mod97) in one shot. Handles +, * and letter mappings already, no regex patching needed.

We already call the VIES-service, but it can't handle the amount of requests sent. Therefore we employ our own fallback, which needed a valid modulo check for the newer format. Again, if anyone has a legitimate source of VAT-modulo-checks to which I may compare, I'm all ears!

[vatfix-ops]

New NL VAT numbers use an extra modulo-97 checksum on top of the old format. They can include letters, +, and *. A valid example: NL123456789B13 → mod97 = 1.
To stay compatible, validators need both the old and the new rule.