The Dutch VAT checksum stopped working in 2020 and your billing pipeline may not know

In October 2019 roughly 1.3 million Dutch sole proprietors were issued brand-new btw-ids, effective for the 9-digit block of a sole-trader VAT ID from 1 January 2020 ^[5]. According to a Node.js validation guide published on dev.to and originally on vatnode.dev, that change quietly broke the usual local-checksum trick for a large class of Dutch numbers ^[3][13], which means any billing pipeline still gating Dutch VAT IDs offline is deciding tax treatment with a test that no longer proves what it used to ^[12].

The format itself is rigid and easy to check: NL, nine digits, a literal letter B, then two digits, fourteen characters in all, as in NL001631457B01 ^[1]. The first misreading starts at the end of the string. Those trailing two digits are a sequence number, not a check digit: B01 is the holder's first business, B02 and B03 further businesses of the same person or entity, and there is nothing in them to verify ^[2].

The real damage is upstream. The nine-digit block used to be a BSN or an RSIN, and both satisfy the Dutch elfproef, a mod-11 test using weights 9, 8, 7, 6, 5, 4, 3, 2, -1 in which the weighted sum must be divisible by 11 ^[4]. If your fixtures were all legal entities, that gate looked like a reliable filter ^[4]. The guide's own sentence describing what replaced the block for sole traders breaks off mid-word in the copy supplied to me ^[14], so take only what it states plainly: after the 2020 change a mod-11 pre-flight check cannot be relied on for sole-trader btw-ids ^[12].

That leaves two ways to be wrong before you ever make a network call. A checksum gate can reject a valid post-2020 sole-trader number, and a regex-only gate can wave through a private number that the authoritative register would reject ^[15]. The second failure has a specific shape in the Netherlands: since 2020 every sole trader holds both a public btw-id in the NL...B01 form, which is the one printed on invoices and checked in VIES, and a BSN-based omzetbelastingnummer in the 123456789B01 form, which is for correspondence with the tax office and is not valid in VIES ^[6]. Both end in Bnn, so a regex will not catch the swap, and VIES simply returns invalid for the private one ^[7].

This is why the guide treats the Netherlands as the exception in its series: where the German, French and Polish pipelines can use a cheap local checksum as a pre-flight filter, the Dutch one leans on VIES with the KVK company register as a fallback ^[8]. The regex proves shape only and never proves registration ^[9].

What remains worth doing locally is normalisation, in one of two declared modes: strict for documented API input, lenient for checkout, where spaces, dots, a lowercase b and a missing NL prefix are auto-corrected and the original logged ^[10]. In the guide's examples, "NL 0016 3145 7 B01" normalises to NL001631457B01, "001631457B01" returns null in strict mode and NL001631457B01 in lenient mode, and "NL001631457B0" returns null on length ^[11].