---
title: "BSN on Employee"
space: "ERPNext"
url: "https://www.prilk.com/docs/erpnext/localization/netherlands/bsn"
updated: "2026-05-15"
---

# BSN on Employee

The *Burgerservicenummer (BSN)* is the Dutch citizen service number —
every resident has one. As an employer, you're legally required to record
it for every Dutch employee and to handle it with the same care as a
health record under the AVG (Dutch GDPR).

This module adds an encrypted `BSN (Burgerservicenummer)` field to the
**Employee** doctype, but only if HRMS is installed — there's no point
adding it on a bench that doesn't have payroll/HR.

## Where it lives

After installation, open any Employee record. Below the **Passport
Number** field you'll see **BSN (Burgerservicenummer)** — a masked
password-style input. Type the 9-digit number; it accepts spaces and
strips them. Save.

The value is encrypted at rest using Frappe's field-level encryption (the
same mechanism that protects API keys and database passwords). Anyone
opening the Employee record sees masked dots — even System Managers. Only
code that explicitly decrypts the value can read it back.

## Elfproef validation

Dutch BSNs aren't just 9 digits — they follow the **elfproef** (11-test):
a weighted digit sum that must be divisible by 11. The module validates
this on every save:

- The first 8 digits are weighted 9, 8, 7, 6, 5, 4, 3, 2.
- The 9th digit is weighted –1.
- The total must be divisible by 11.

Typos and made-up numbers fail this check immediately. If save fails,
recheck the BSN against the employee's ID document — there's almost
certainly a digit transposed.

The validator strips spaces and dashes before checking, so `123 456 789`
and `123-456-789` and `123456789` all work the same way.

## Compliance notes

Under Dutch and EU law, BSN is a *bijzondere persoonsgegeven* (special
category personal data). Storing it means you must:

- **Limit who can read it.** Use ERPNext's role-permission system to
  restrict Employee read access to HR roles only.
- **Have a legal basis.** Employment is one; you can't store BSNs for
  contractors or job applicants without separate justification.
- **Have a retention policy.** BSN should be deleted when the employment
  relationship ends and the legal retention period (seven years for
  payroll records) lapses.
- **Document the processing.** Your AVG processing register should
  include "BSN voor loonadministratie" as a stored data category.

This module enforces the encryption-at-rest and elfproef-validation
pieces; the role permissions and retention policy are your call to set
up.

## What you can do with it

Most operators never need to read the BSN back in plain text — payroll
tools that need it can call ERPNext's encryption API. For ad-hoc reads
(e.g. confirming a value with the employee), open the record, click into
the field, and the value reveals while you have it focused.

If you're integrating a third-party payroll system, that integration
will need to decrypt the field; your developer can use Frappe's standard
password-field read API. Don't put the BSN into custom reports or
exports unless the export channel is encrypted end-to-end.