Clientes duplicados tras migrar de sistema: cómo depurar la base

Los clientes duplicados son el recuerdo más común que deja una migración de sistema: el mismo cliente aparece dos o tres veces, con el nombre escrito distinto, una ficha con DNI y otra con RUC, y sus facturas, cobros y notas de crédito repartidos entre ellas. El resultado es un estado de cuenta partido, saldos a favor que “desaparecen” y reportes de ventas por cliente que no sirven.

En esta guía verás cómo detectar duplicados con criterio (no solo por nombre), cómo saber si un DNI y un RUC 10 son de la misma persona con el dígito verificador, qué hacer con los documentos que apuntan a clientes que ya no existen y cómo fusionar sin romper la contabilidad.

Por qué aparecen clientes duplicados al migrar

• El sistema anterior no validaba el documento. Se podía crear la misma persona dos veces, con o sin DNI.
• Cada vendedor creaba “su” cliente. “Juan Pérez”, “PEREZ JUAN” y “Juan Perez Quispe” conviven.
• La persona natural con negocio tiene dos documentos. Compra con boleta usando su DNI y con factura usando su RUC 10.
• Se importaron documentos antes que clientes. Quedan comprobantes con un cliente cuyo identificador no existe en la nueva base (documentos huérfanos).
• Clientes genéricos mal usados. “Clientes varios” con un DNI de relleno (00000000) que “agrupa” a cientos de personas distintas.

Cómo detectar un duplicado de verdad

El nombre es una mala llave: se escribe distinto, tiene tildes o no, el orden de apellidos cambia. La llave confiable es el número de documento normalizado y válido:

• Solo dígitos, sin espacios ni guiones.
• Al menos 8 dígitos (DNI) u 11 (RUC).
• No genérico: 00000000, 11111111, 12345678 o 99999999 no identifican a nadie.
• Nunca de un cliente genérico (“Clientes varios”, “Público en general”).

Dos fichas con el mismo documento válido son la misma persona: es un duplicado seguro. Dos fichas con el mismo nombre o el mismo teléfono, pero sin documento coincidente, son solo una sugerencia: pueden ser homónimos o familiares que comparten número. Esas las revisa una persona.

DNI y RUC 10: la misma persona con dos números

Una persona natural con negocio tiene un RUC que empieza con 10. Ese RUC se arma con su DNI: 10 + los 8 dígitos del DNI + un dígito verificador. Por eso, si una ficha tiene el DNI y otra el RUC 10 de ese DNI, son la misma persona.

El dígito verificador del RUC se calcula con el método de módulo 11:

1. Toma los 10 primeros dígitos del RUC.
2. Multiplica cada uno por los factores 5, 4, 3, 2, 7, 6, 5, 4, 3, 2 y suma los resultados.
3. Calcula 11 menos el residuo de dividir esa suma entre 11.
4. Si el resultado es 10, el dígito es 0; si es 11, el dígito es 1; en otro caso, es el propio resultado.

Ejemplo con un DNI ilustrativo, 41234567:

La suma es 123; 123 entre 11 deja residuo 2; 11 − 2 = 9. El RUC 10 de ese DNI es 10412345679. Si en tu base aparece un “RUC” 10412345670, el dígito no cuadra: es un error de digitación y no debe emparejarse con el DNI.

Al fusionar ese par conviene que la ficha final guarde los dos documentos: el RUC 10 para las facturas y el DNI para las boletas.

Documentos huérfanos: comprobantes con un cliente que no existe

Un documento huérfano es una factura, boleta, cobro o nota de crédito cuyo cliente apunta a un identificador que ya no está (o nunca estuvo) en la base. Pasa mucho cuando se migra el histórico de ventas sin haber migrado antes todos los clientes. Hay tres salidas, en este orden:

1. Reasignar: si el DNI o RUC impreso en el documento coincide con una ficha vigente, el documento pasa a esa ficha.
2. Crear la ficha: si no hay ficha con ese documento y el número es válido, se consulta en SUNAT o RENIEC y se crea con el nombre oficial.
3. Revisar a mano: si hay varias fichas posibles, solo coincidencia por nombre, o el número no existe en la consulta oficial.

Qué cambia y qué no al fusionar dos fichas

El método seguro: línea base, un caso, verificación

Fusionar en lote “a ciegas” es la forma más rápida de arruinar un estado de cuenta. El método que recomendamos, venga de donde venga tu migración:

1. Vista previa en seco: lista los casos sin tocar nada.
2. Línea base por empresa: anota cuántos comprobantes, cobros, notas de crédito y créditos hay, y cuánto suman, por empresa y por cada ficha del caso.
3. Aplica un caso.
4. Verifica: los totales por empresa no debieron cambiar, la suma de la ficha origen debió pasar entera a la destino y no debe quedar ningún documento apuntando a la origen.
5. Si algo no cuadra, revierte ese caso y márcalo para revisión. Después, el siguiente.

¿Cómo lo resuelve KELUA?

KELUA trata la identidad del cliente con una regla única, la misma en la pantalla y en el servidor: dos documentos son del mismo cliente si tienen la misma ficha o el mismo DNI/RUC normalizado y válido. Los números genéricos y los clientes genéricos nunca cruzan fichas. Y un DNI con su RUC 10 (con dígito verificador válido por módulo 11) se reconoce como la misma persona; un RUC 10 con dígito inválido no se empareja.

Aviso en Clientes. Cuando hay posibles duplicados, la vista de Clientes muestra el botón ⚠ N posibles duplicados. Separa los seguros (mismo documento válido, o DNI y RUC 10 con el mismo nombre) de las sugerencias (mismo nombre, mismo teléfono, o DNI y RUC 10 con nombres distintos). Para fusionar eliges la ficha destino y escribes el motivo, que es obligatorio.

La fusión re-apunta todo. KELUA cambia el identificador de cliente en todas las colecciones donde aparece (comprobantes, notas de crédito, cobros, cotizaciones, pedidos, proyectos, leads…), sin tocar el nombre ni el documento impresos en comprobantes emitidos y sin cambiar la empresa de ningún documento. Completa los datos vacíos de la ficha destino, da de baja lógica la ficha origen (que queda como alias) y guarda un respaldo de lo que modificó, con candado e idempotencia: un doble clic no fusiona dos veces. Si fusionas un DNI con su RUC 10, la ficha final queda con ambos, y al emitir KELUA imprime el RUC en las facturas y el DNI en las boletas.

Saneamiento de datos maestros. En Control Interno → 🧹 Saneamiento de datos, el ERP propone y aplica solo los arreglos seguros, con el método de línea base por empresa: fichas de cliente duplicadas, documentos con cliente inexistente (reasignar por el documento impreso), crear la ficha desde el documento verificado en SUNAT o RENIEC (con cupo y pausa entre consultas), productos sin gemelo en la otra empresa del grupo y líneas de documentos abiertos con productos de otra empresa. Cada caso se aplica uno por uno: si después de aplicarlo cambió algo que no debía, se revierte solo y queda en “revisar” con el motivo. Los dudosos los aprueba o descarta una persona, y lo descartado no se vuelve a proponer.

Modo proponer o automático. Por defecto el saneamiento solo propone (de noche calcula la propuesta, sin tocar datos). Si la empresa lo decide, puede pasar a modo automático en una ventana horaria nocturna, aplicando solo los casos seguros.

El saldo no se pierde. Como la identidad se reconoce por documento, un saldo a favor que quedó en una ficha y una boleta pendiente en otra del mismo cliente se pueden cruzar, dejando rastro del cruce. Lo explicamos en nota de crédito y saldo a favor del cliente.

Mini-caso: una ferretería que migró cinco años de historia

Antes. Una ferretería ficticia de Arequipa migró 9,000 clientes y cinco años de comprobantes desde su sistema anterior. En la primera semana, cobranzas notó que varios clientes frecuentes tenían dos estados de cuenta, y que 600 boletas apuntaban a clientes que no estaban en la base.

Después. El saneamiento propuso 310 fusiones seguras (mismo documento válido, o DNI y RUC 10 con el mismo nombre), 540 reasignaciones de documentos huérfanos por su DNI impreso y 45 casos para revisar. Se aplicaron los seguros por la noche; dos casos se revirtieron solos porque sus totales por empresa no cuadraban, y quedaron para revisión con el motivo. Al día siguiente, cada cliente tenía un solo estado de cuenta.

Cómo evitar que los duplicados vuelvan

Depurar una vez sirve de poco si el equipo sigue creando fichas repetidas. Tres hábitos lo evitan:

• Buscar antes de crear. Que el vendedor busque por DNI o RUC, no por nombre, antes de registrar un cliente nuevo.
• Crear desde el documento. Al digitar el RUC o DNI, que el sistema traiga la razón social o el nombre oficial; así no hay “Juan Perez” y “PEREZ JUAN”.
• Revisar duplicados cada semana, no solo tras la migración. Una lista corta se resuelve en minutos; una de mil, en días.

En KELUA, la ficha de cliente se puede completar consultando el RUC o el DNI, y el aviso de posibles duplicados reaparece en Clientes cada vez que se forma uno nuevo, así el problema se corta cuando todavía es pequeño.

Errores frecuentes al depurar la base de clientes

• Fusionar por nombre. Dos “María Quispe” no son la misma persona.
• Usar DNI de relleno. Un 00000000 en cien fichas no las vuelve una.
• Editar el nombre impreso en comprobantes emitidos. El comprobante es el que se envió a SUNAT; se corrige la ficha, no el documento.
• Borrar físicamente la ficha duplicada. Los enlaces antiguos quedan rotos; mejor baja lógica con referencia a la destino.
• Fusionar sin respaldo ni verificación. Sin línea base no sabrás si cambió un total.

Checklist después de una migración

• ¿Cuántas fichas comparten DNI o RUC válido?
• ¿Cuántas personas tienen DNI en una ficha y RUC 10 en otra?
• ¿Cuántos documentos apuntan a un cliente inexistente?
• ¿Cuántos clientes genéricos tienen documentos de personas identificables?
• ¿Los totales por empresa (ventas, cobros, notas de crédito) cuadran antes y después del saneamiento?

Si estás por migrar, empieza por cómo migrar de Excel a un ERP; y para que estos controles se repitan solos cada semana, revisa el control interno automático para pymes. La guía general de qué es un ERP y para qué sirve explica por qué un maestro de clientes único es la base de todo lo demás.