The Dutch IBAN is short, strict and letter-prefixed, which makes it deceptively easy to get wrong in test data. An NL test IBAN is exactly 18 characters: NL, two mod-97 check digits, a 4-letter bank code and a 10-digit account number padded with leading zeros. If your fixture generator emits digits where the bank code belongs, or drops the zero padding, Dutch validation fails instantly.
The hidden second check: the elfproef
The Netherlands has a national tradition worth knowing when you test for this market. Classic Dutch account numbers satisfy the elfproef (11-test): multiply each digit by its position weight, sum, and the total must be divisible by 11. Many Dutch backends and libraries still apply this test to the account-number part of the IBAN on top of the ISO mod-97 check. A test IBAN that ignores it can sail through generic validators and then be rejected by a Dutch PSP integration. The generator here produces account numbers that pass the 11-test, so the output behaves like real-world Dutch data in every validator you are likely to meet.
Fitting it into your workflow
A typical use: an end-to-end Playwright test of an iDEAL-adjacent signup flow that also collects an IBAN for refunds. The test fills the field, expects the inline validator to show green, and proceeds to submission. Another: seeding a staging database with a few hundred Dutch users, each needing a unique, well-formed IBAN so downstream export jobs and SEPA batch generators do not choke. Generate values one at a time here, entirely in your browser; nothing is uploaded, and each IBAN carries a TEST label.
Testing only
Passing every checksum in the stack still proves nothing about account existence. These IBANs belong in test code, fixtures and demos. They must never appear on an invoice or in a payment instruction, and EU Verification of Payee name-matching now checks payee details on euro transfers precisely to catch fabricated or mismatched IBANs.