Errores comunes al emitir facturas electrónicas

Una factura electrónica mal emitida no siempre se nota en el momento. SUNAT puede aceptarla y el problema aparece semanas después, cuando el cliente la rechaza porque la razón social no coincide, cuando el contador detecta que el IGV se convirtió con un tipo de cambio equivocado o cuando el RUC resulta estar de baja.

La mayoría de esos errores tiene una causa común: datos que alguien escribió a mano y que nadie contrastó con la fuente oficial antes de numerar el comprobante. Y casi todos se pueden prevenir con validaciones automáticas en el momento correcto.

En este artículo repasamos los errores que más se repiten, por qué ocurren, qué consecuencia tienen y cómo evitarlos, con una validación previa en código al final.

---

Por qué los errores se detectan tarde

Cuando envías una factura, SUNAT o el OSE la validan contra reglas técnicas: estructura del XML, firma, catálogos, cuadre de totales, existencia del RUC del cliente. Lo que no pasa esas reglas se rechaza y, aunque molesta, se corrige y se vuelve a enviar.

El problema son los errores que pasan la validación. Una razón social con una palabra de más, una dirección antigua, un tipo de cambio de ayer o un cliente que ya no está activo pueden entrar en un comprobante aceptado. En ese punto ya no se edita: hay que anular con una nota de crédito y emitir de nuevo. Anular con nota de crédito y volver a emitir es el remedio; aquí nos concentramos en no llegar a él.

La regla general es simple: todo lo que se pueda validar contra una fuente oficial se valida antes de asignar serie y número. Después es tarde.

RUC inválido, inexistente o de baja

Es el error más frecuente y el más fácil de prevenir. Tiene tres variantes:

• Formato inválido. Un dígito de más o de menos, o un número que no cumple el dígito verificador. El RUC tiene 11 dígitos y el último es un dígito de control calculado a partir de los demás; en cómo validar un RUC con el dígito verificador está el algoritmo en JavaScript y Python. Esta validación es local, gratuita e instantánea.
• RUC inexistente. El formato es correcto, pero SUNAT no tiene registrado ese número. Suele venir de un error de tipeo que casualmente da un dígito verificador válido. SUNAT rechaza la factura, pero mejor detectarlo antes.
• RUC de baja o suspendido. El RUC existe, pero su estado no es ACTIVO: puede estar en SUSPENSIÓN TEMPORAL, BAJA PROVISIONAL, BAJA DEFINITIVA o BAJA DE OFICIO. Facturarle a un contribuyente así es un problema para él (no podrá usar el comprobante con normalidad) y una señal de alerta para ti.

Aparte del estado está la condición del domicilio: HABIDO, NO HABIDO, NO HALLADO o PENDIENTE. Un cliente NO HABIDO no te impide facturar, pero sí conviene saberlo si además es tu proveedor. En qué significan ACTIVO y HABIDO está el detalle de cada valor.

La prevención es una validación en dos pasos: formato en el frontend (longitud y dígito verificador) y existencia y estado en el backend, consultando la fuente oficial. Con la API de consulta RUC de endpoint.pe es una llamada:

curl https://api.endpoint.pe/v1/ruc/20131312955 \
  -H "Authorization: Bearer TU_TOKEN"

Si el RUC no existe, la respuesta es un 404 con un mensaje de error, y esa consulta no se cobra. Si existe, obtienes estado, condicion, razon_social, direccion y ubigeo, que son justamente los datos que necesitas para los siguientes errores.

Razón social y dirección copiadas a mano

La razón social que va en la factura tiene que ser la que figura en SUNAT, no el nombre comercial ni una versión "limpia" que alguien escribió. "Comercial Pérez" no es lo mismo que "COMERCIAL PEREZ S.A.C.", y "SAC" no es lo mismo que "S.A.C." para un cliente cuyo sistema compara textos.

Causas típicas:

• El vendedor escribe lo que el cliente dicta por teléfono.
• El sistema guarda la razón social de la primera factura y no la actualiza aunque la empresa haya cambiado de nombre.
• Alguien "corrige" mayúsculas, tildes o abreviaturas para que se vea mejor.

La consecuencia no suele ser un rechazo de SUNAT, sino un rechazo del cliente: su área contable compara la factura con sus registros y, si no coincide, la devuelve. Eso retrasa el cobro.

Con la dirección pasa algo parecido. La dirección del cliente puede ser opcional según el tipo de comprobante, pero cuando la incluyes tiene que ser la correcta, y las empresas cambian de domicilio fiscal más de lo que uno cree. Una dirección incompleta (sin distrito, sin número) o desactualizada en la factura genera observaciones del cliente y confusiones en las entregas.

La prevención para ambos es la misma: no tipear, consultar. La razón social y la dirección se toman de la respuesta de la consulta al RUC y se guardan tal cual, con sus mayúsculas, puntos y guiones. Si cacheas esos datos, dales un tiempo de vida corto para la dirección y el estado, que cambian, y más largo para la razón social, que cambia poco.

Tipo de documento del cliente equivocado

Cada comprobante lleva el tipo de documento de identidad del cliente según el catálogo de SUNAT: 6 para RUC, 1 para DNI, 4 para carnet de extranjería, 7 para pasaporte, entre otros. Los errores aparecen cuando el código no corresponde al número o al tipo de comprobante:

• Factura con tipo de documento DNI. Una factura requiere RUC (código 6). Si el sistema permite elegir "factura" y el cliente solo tiene DNI, el comprobante está mal desde el origen.
• Boleta con RUC donde correspondía factura. El cliente dio su RUC porque quería factura; alguien emitió boleta. El cliente no podrá usar el crédito fiscal.
• Número que no cuadra con el tipo. Tipo 1 (DNI) con un número de 11 dígitos, o tipo 6 (RUC) con 8 dígitos. Pasa cuando los campos de tipo y número se llenan por separado y nadie los cruza.
• Extranjero registrado como DNI. El carnet de extranjería tiene su propio código (4) y formato. Registrarlo como DNI produce un comprobante con datos inconsistentes.

La prevención es derivar el tipo de documento del número cuando sea posible (11 dígitos que empiezan en 10, 15, 17 o 20: RUC; 8 dígitos: DNI) y validar la combinación tipo, número y comprobante antes de numerar. Cuándo corresponde factura y cuándo boleta lo explicamos en factura o boleta: cuándo emitir cada una.

Tipo de cambio incorrecto en operaciones en dólares

Cuando facturas en dólares, el comprobante lleva los montos en moneda extranjera, pero el IGV se expresa en soles. Para esa conversión se usa el tipo de cambio venta que publica SUNAT para la fecha de emisión, que es el promedio ponderado que calcula la SBS del día anterior. Si tu sistema usa otro valor, el IGV en soles sale distinto al que tu cliente y SUNAT esperan.

Los errores más comunes:

• Usar el tipo de cambio de otra fecha. El sistema toma "el último que tiene guardado" en lugar del de la fecha de emisión. Es típico cuando el tipo de cambio se carga a mano una vez a la semana.
• Usar compra en lugar de venta. Son dos valores distintos y la diferencia, aunque pequeña por unidad, se nota en montos grandes.
• Usar el tipo de cambio de un banco o de una casa de cambio. Puede servir para cobrar, pero no es el que corresponde al comprobante.
• Redondear antes de tiempo. Convertir cada línea, redondear y luego sumar da un resultado distinto a convertir el total; define una sola regla y aplícala siempre.

Qué tipo usar en cada caso (venta para el IGV, compra o venta para otros fines contables) lo tratamos en tipo de cambio SUNAT: cuál usar. Para prevenir el error en el sistema, el tipo de cambio no se escribe: se consulta por fecha y se guarda junto al comprobante. Con la API de tipo de cambio la llamada es GET /tipo-cambio y la respuesta trae fecha, compra y venta del valor vigente (en el ejemplo, 3.708 y 3.712), listos para guardarlos junto al comprobante.

Un detalle: los fines de semana y feriados no hay publicación nueva, y el valor aplicable sigue reglas propias. Tu sistema debería resolver eso automáticamente en lugar de dejar el campo vacío o pedirlo al usuario.

Una validación previa que los atrapa todos

Todo lo anterior se resume en una función que corre antes de asignar número. Recibe el borrador del comprobante, consulta lo que haga falta y devuelve una lista de problemas. Si la lista está vacía, se numera y se emite.

async function validarAntesDeEmitir(borrador, api) {
  const errores = [];
  const { tipoComprobante, cliente, moneda, fecha } = borrador;

  // 1. Tipo de documento coherente con el comprobante
  if (tipoComprobante === "01" && cliente.tipoDoc !== "6") {
    errores.push("Una factura requiere un cliente con RUC");
  }
  if (cliente.tipoDoc === "6" && !/^(10|15|17|20)\d{9}$/.test(cliente.numeroDoc)) {
    errores.push("El RUC no tiene un formato válido");
  }
  if (cliente.tipoDoc === "1" && !/^\d{8}$/.test(cliente.numeroDoc)) {
    errores.push("El DNI debe tener 8 dígitos");
  }
  if (errores.length) return errores;

  // 2. Existencia, estado y datos oficiales del RUC
  if (cliente.tipoDoc === "6") {
    const r = await api.ruc(cliente.numeroDoc); // null si la API devolvió 404
    if (!r) {
      errores.push("El RUC no existe en SUNAT");
    } else {
      if (r.estado !== "ACTIVO") errores.push(`El RUC está en estado ${r.estado}`);
      if (r.razon_social !== cliente.razonSocial) {
        errores.push("La razón social no coincide con SUNAT; usa la oficial");
        borrador.cliente.razonSocialOficial = r.razon_social;
      }
      if (cliente.direccion && r.direccion !== cliente.direccion) {
        errores.push("La dirección no coincide con el domicilio fiscal registrado");
      }
    }
  }

  // 3. Tipo de cambio de la fecha de emisión
  if (moneda === "USD") {
    const tc = await api.tipoCambio(fecha);
    if (!tc) {
      errores.push("No se pudo obtener el tipo de cambio de la fecha");
    } else {
      borrador.tipoCambioVenta = tc.venta;
    }
  }

  return errores;
}

Observa que la función no corrige en silencio: reporta y deja los datos oficiales a mano para que la interfaz los proponga. Así el usuario entiende qué pasó y el sistema no sobrescribe sin aviso.

Para probar este flujo sin compromiso, endpoint.pe incluye 150 consultas gratis al mes sin tarjeta y cobra un crédito por consulta en cualquier API, sin cobrar las que no devuelven resultado.

En resumen

• Los errores que más cuestan son los que SUNAT acepta: se corrigen con nota de crédito y nueva emisión.
• Valida el RUC en dos pasos: formato y dígito verificador en local, existencia y estado contra la fuente oficial.
• La razón social y la dirección se toman de la consulta, carácter por carácter; nunca del teclado.
• Deriva el tipo de documento del número y valida que cuadre con el tipo de comprobante.
• En dólares, usa el tipo de cambio venta de la fecha de emisión que publica SUNAT, consultado y guardado con el comprobante.
• Todo esto corre antes de asignar serie y número; después ya es tarde.

Preguntas frecuentes

¿SUNAT rechaza una factura si la razón social está mal escrita?

No siempre. SUNAT valida sobre todo que el RUC exista y que el XML cumpla las reglas técnicas; una razón social con diferencias puede pasar como observación o ni siquiera marcarse. Quien la rechaza suele ser el cliente al conciliar. Por eso conviene validarla tú antes de emitir.

¿Qué hago si ya emití la factura con un error?

Un comprobante aceptado no se edita. Según el tipo de error, se anula con una nota de crédito y se emite uno nuevo, o se ajusta con una nota de crédito o débito. Confirma el procedimiento con tu contador y revisa las reglas vigentes antes de automatizarlo.

¿Puedo facturar a un cliente en estado distinto de ACTIVO?

Técnicamente el sistema podría generar el XML, pero es una mala idea: el cliente tendrá problemas para usar el comprobante y es una señal de riesgo comercial. Lo recomendable es bloquear la emisión y pedir confirmación explícita.

¿Cada cuánto debo revalidar los datos de un cliente frecuente?

El estado, la condición y la dirección pueden cambiar en cualquier momento, así que conviene revalidarlos con un tiempo de vida corto en caché o directamente en cada emisión. La razón social cambia poco; puedes refrescarla con menos frecuencia. En cualquier caso, una consulta por comprobante cuesta mucho menos que una anulación.