Dígito de control personnummer Suecia
Las nueve cifras 811228987, fecha de nacimiento más serie, llevan el dígito de control 4, y el personnummer queda 8112289874. Escriba nueve cifras para completar un número de identidad sueco, o diez o doce para confirmar su último dígito. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Número
- 811228987
- Modo de cálculo
- Compute
- Entrada
- 811228987
- Fecha
- 811228
- Número de serie
- 987
El personnummer sueco (número personal de identidad) es el identificador civil nacional usado en fiscalidad, sanidad, banca, empleo y la mayoría de los formularios públicos de Suecia. En su forma corta tiene diez dígitos: seis para la fecha de nacimiento como año-mes-día (YYMMDD), tres de serie asignados dentro de ese día y un dígito de control final. La forma de doce dígitos antepone el siglo (YYYYMMDD más serie y control). El dígito de control no es decoración aleatoria: se obtiene con el algoritmo de Luhn sobre los primeros nueve dígitos de la forma corta, de modo que un solo error de tecleo o un par intercambiado suele rechazarse antes de almacenar o emparejar el número. Esta capacidad implementa solo esa suma de control. El modo compute acepta exactamente nueve dígitos —fecha más serie sin el control— y devuelve el dígito Luhn más la cadena completa de diez dígitos. El modo validate acepta diez o doce dígitos (guiones o signos más opcionales) e indica si el dígito final coincide con el valor esperado recalculado.
Cómo se calcula el dígito de control del personnummer sueco
Según las reglas de la Agencia Tributaria sueca (Skatteverket), el dígito de control del personnummer es un valor Luhn mod-10 calculado sobre nueve dígitos: la fecha de nacimiento de seis dígitos YYMMDD seguida de la serie de tres dígitos. Desde la izquierda, contando las posiciones del uno al nueve, cada posición impar se duplica; si el doble de un dígito es mayor que nueve, se resta nueve (o se suman las dos cifras del producto). Las posiciones pares aportan el dígito sin cambio.
Se suman los nueve valores ponderados; el dígito de control es diez menos esa suma módulo diez, módulo diez otra vez, de modo que al añadir el control la forma corta de diez dígitos sea coherente con Luhn. La validación recalcula el dígito esperado a partir de la carga útil de nueve dígitos y lo compara con el último dígito del número enviado.
En la forma de doce dígitos con siglo YYYYMMDDNNNC, la carga Luhn sigue siendo los nueve dígitos YYMMDDNNN: los dígitos del siglo son metadatos de visualización para edad y ordenación, no parte de los pesos de la suma de control. Un ejemplo conocido es la base 811228987, que produce el dígito de control 4 y la forma corta completa 8112289874 (a menudo escrita 811228-9874).
Los números de coordinación (samordningsnummer) usan el día del mes más sesenta y siguen la misma regla Luhn sobre los nueve dígitos del cuerpo; esta herramienta no inventa un algoritmo distinto para ellos. El algoritmo es determinista y local: sin llamada al registro de población, sin reloj y sin aleatoriedad.
Frente a herramientas genéricas de Luhn de tarjetas o IMEI, la intención de búsqueda aquí es estrecha: personas que necesitan una calculadora del dígito de control del personnummer sueco a partir de fecha y serie, o un comprobador de números personales suecos de diez o doce dígitos, no una herramienta de pago o de dispositivo.
Dónde encajan los dígitos de control del personnummer en flujos suecos reales
Bancos y fintech validan valores de personnummer de diez o doce dígitos al abrir la cuenta para que una sola transposición no cree un cliente fantasma ni un registro KYC rechazado. Los trabajos ETL que cargan ficheros maestros de clientes o empleados suecos recorren cada columna personnummer en un feed CSV o XML, llaman al modo validate y ponen en cuarentena las filas donde valid es false, capturando tanto ediciones humanas como errores de uno en generadores.
Los sistemas municipales y escolares suelen aceptar formas con guion y compactas; eliminar espacios, guiones y signos más antes de la comprobación de dígitos mantiene el contrato simple sin inventar un segundo algoritmo. No trate un personnummer con suma de control correcta como prueba de que el titular vive en el registro de población, tiene tarjeta de identidad sueca o está autorizado para un servicio; solo demuestra que el dígito Luhn es coherente con la fecha y la serie según los pesos oficiales del personnummer sueco.
Qué puede hacer con ella
Auditar columnas personnummer en datos maestros
Valide por lotes cada personnummer de un CSV de CRM, EHR o nómina y ponga en cuarentena las filas cuyo dígito de control ya no coincida con el valor esperado recalculado.
Preguntas frecuentes
¿Qué es el dígito de control de un personnummer sueco?
Es el décimo dígito de la forma corta del número personal de identidad sueco, calculado con el algoritmo de Luhn sobre la fecha de nacimiento de seis dígitos y la serie de tres, de modo que los errores de tecleo y de escaneo suelen detectarse antes de almacenar el número.
¿Qué ocurre con longitud incorrecta, letras o puntuación extraña?
Las tareas de validación fallidas no se facturan.
¿Es gratuita la herramienta del dígito de control del personnummer?
La herramienta del navegador es gratuita y se ejecuta en local.
¿Cómo se calcula el dígito de control del personnummer?
Se toman las nueve cifras de fecha y serie y se duplica cada cifra en posición impar desde la izquierda, restando nueve a lo que pase de nueve. Se suma todo y el dígito de control lleva el total a un múltiplo de diez. Para 811228987 es 4.
¿La forma de doce cifras cambia el dígito de control?
No. En la forma de doce cifras, las dos primeras solo indican el siglo para mostrar y ordenar. El dígito de control se sigue calculando con las mismas nueve cifras de la forma corta.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/enc/personnummer-sweden \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"811228987"}'const res = await fetch("https://api.kit.forhosting.com/enc/personnummer-sweden", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "811228987"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/personnummer-sweden",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "811228987"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/personnummer-sweden", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"811228987"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"811228987"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/personnummer-sweden", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"number": "811228987"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.personnummer_sweden",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Los cuerpos no numéricos y las longitudes incorrectas fallan con invalid_input en lugar de un recorte silencioso. La misma aritmética pura se ejecuta gratis en el navegador y al precio publicado de la API, sin consulta a registro y sin afirmar que una suma de control válida implique que la persona viva, esté empadronada o tenga derecho a un servicio.
Contrato de entrada, modos y comportamiento ante errores
Una longitud incorrecta es un error explícito que nombra el modo y la longitud enviada —nueve para compute, diez o doce para validate— para que los formularios del cliente muestren un mensaje preciso sin adivinar. Cadenas vacías, number ausente y valores de mode inválidos fallan antes de ejecutar cualquier suma Luhn y no se facturan. HH. a un personnummer completo de un usuario o de un feed de socio. Una cadena bien formada que simplemente tiene el dígito de control incorrecto devuelve valid false sin lanzar error. Envíe un campo number con el cuerpo del personnummer. Se eliminan espacios, guiones y signos más para que las formas de visualización suecas habituales como 811228-9874 o 19811228-9874 se acepten tras la normalización; otra puntuación y letras se rechazan como entrada no numérica con invalid_input, de modo que un valor limpiado en silencio nunca llegue al almacenamiento. El modo compute es el predeterminado: el motor exige exactamente nueve dígitos, devuelve check_digit como cadena de un carácter, with_check como el personnummer corto de diez dígitos que puede imprimir o persistir, y también date (YYMMDD) y serial (tres dígitos) para auditorías. El modo validate acepta exactamente diez dígitos (YYMMDDNNNC) o doce (YYYYMMDDNNNC); la respuesta indica valid true cuando el dígito final coincide con expected_check_digit recalculado, e incluye siempre payload (los nueve dígitos Luhn), check_digit, expected_check_digit, date, serial, form ("10" o "12") y length. En entradas de doce dígitos la respuesta también incluye century y full_date (YYYYMMDD) sin tratar el siglo como parte de la suma Luhn. Se aceptan alias como personnummer, pnr, digits y code para el mismo campo de carga útil, de modo que las integraciones que ya usan nombres de campo suecos no necesiten renombrarlo. Como la ruta es parse puro sin reloj, fuente aleatoria ni red, el mismo cuerpo JSON produce siempre el mismo resultado JSON en la herramienta gratuita del navegador y en la API a $0.002 por solicitud correcta.
Dónde encajan los dígitos de control del personnummer en flujos suecos reales
Los portales sanitarios y los sistemas de farmacia recalculan expected_check_digit cuando una clínica lee un número por teléfono o lo pega desde una tarjeta escaneada, capturando errores de tecleo antes de archivar una entrada de historial o una receta. Empleadores y proveedores de nómina completan bases de nueve dígitos en sandboxes con el modo compute y luego almacenan with_check en empleados de prueba que deben parecer identificadores de producción. En todo flujo la promesa es la misma: solo dígitos tras el recorte opcional de separadores, longitud fija por modo, JSON estructurado que puede probarse con goldens, comportamiento idéntico en navegador gratuito y API de prepago, e invalid_input honesto cuando la cadena no es una secuencia pura de dígitos de la longitud correcta.
Casos de integración
Completar una base de personnummer de 9 dígitos para pruebas
Llame al modo compute con YYMMDD más tres dígitos de serie, almacene with_check y use el personnummer de diez dígitos en registros de prueba de KYC, nómina o sanidad.
Validar números personales suecos tecleados o importados
Cuando un formulario, un fichero bancario o un feed de RR. HH. envíe diez o doce dígitos, llame al modo validate y bloquee el alta si valid es false, mostrando expected_check_digit para ayudar a corregir un solo error de tecleo.
Preguntas técnicas
¿Cómo calculo el dígito de control de un personnummer con esta API?
Haga POST con number en exactamente nueve dígitos (YYMMDD más serie) y mode compute (o omita mode). La respuesta incluye check_digit y with_check (la forma corta completa de diez dígitos).
¿Cómo valido un personnummer completo de diez o doce dígitos?
Haga POST con la cadena de dígitos (guiones o signos más opcionales) y mode validate. La respuesta incluye valid, check_digit, expected_check_digit y payload (los nueve dígitos Luhn).