Factura o boleta: cuándo emitir cada una

"¿Factura o boleta?" es la pregunta que se hace en cada caja del Perú. Para el cajero es un clic. Para el sistema que emite el comprobante, ese clic define el tipo de documento, la serie, los datos que debe pedir al cliente y lo que SUNAT va a validar.

Equivocarse cuesta: una boleta emitida a una empresa que necesitaba factura se anula con una nota de crédito y se vuelve a emitir, y mientras tanto el cliente no puede usar su crédito fiscal. Una factura a un RUC que no existe directamente no pasa.

Aquí vas a ver qué diferencia a los dos comprobantes, cuándo corresponde cada uno, qué pasa con el DNI en la boleta y cómo hacer que tu sistema tome la decisión solo, con un ejemplo en JavaScript.

---

Qué diferencia a una factura de una boleta

Las dos son comprobantes de pago electrónicos y las dos acreditan una venta o un servicio. La diferencia está en quién es el comprador y para qué le sirve el documento.

La factura se emite a un comprador identificado con RUC. Le sirve para sustentar costo o gasto y, si es contribuyente del IGV, para usar el IGV pagado como crédito fiscal. Por eso una empresa que compra insumos pide factura: sin ella, ese IGV se convierte en costo puro.

La boleta de venta se emite a consumidores finales. Como regla general no permite ejercer crédito fiscal ni sustentar gasto para fines tributarios (hay excepciones puntuales que tu contador conoce). Identifica al comprador con DNI cuando la norma lo exige, y por debajo de ese umbral puede emitirse sin identificarlo.

En lo técnico, ambas viajan a SUNAT como XML, pero con tipo de comprobante distinto (01 factura, 03 boleta), series distintas (las facturas empiezan con F, las boletas con B) y flujos de envío distintos: las facturas se envían una por una y las boletas tradicionalmente se informan en un resumen diario. Si quieres el mapa completo, está en la guía de facturación electrónica para desarrolladores.

Cuándo corresponde factura

Emite factura cuando el comprador tiene RUC y la operación es para su actividad económica. Eso incluye:

• Personas jurídicas (RUC que empieza en 20): empresas, asociaciones, entidades del Estado.
• Personas naturales con negocio (RUC que empieza en 10): un profesional independiente o un comerciante que compra para su actividad y necesita sustentar el gasto. La diferencia entre ambos tipos la explicamos en RUC 10 vs RUC 20.
• Exportaciones a clientes del exterior, que se documentan con factura aunque el comprador no tenga RUC. En el XML hay un código de documento específico para no domiciliados sin RUC; revisa el catálogo vigente.

Que el comprador tenga RUC no basta: el RUC tiene que existir y, en la práctica, estar ACTIVO. Facturar a un RUC de baja o suspendido genera problemas al cliente y a ti. En qué significan ACTIVO y HABIDO está cada estado y condición.

Un caso frecuente: el cliente es una persona natural con RUC 10 que compra para uso personal. Técnicamente puede pedir factura, pero no debería usarla para sustentar un gasto que no es de su negocio. Tu sistema no tiene cómo saberlo; lo que sí puede hacer es emitir lo que el cliente pide con un RUC válido y dejar el resto a su contador.

Cuándo corresponde boleta

Emite boleta cuando el comprador es un consumidor final: alguien que compra para sí mismo y no va a sustentar la compra tributariamente. Esto cubre la mayoría del retail, restaurantes, servicios personales y comercio electrónico a personas.

También corresponde boleta cuando el comprador es una persona natural sin RUC, aunque la compra sea grande. Y cuando el comprador es extranjero sin RUC, la boleta se emite con su pasaporte o carnet de extranjería como documento de identidad.

Hay un detalle que afecta al emisor y no al comprador: quien está en el Nuevo RUS (NRUS) solo puede emitir boletas de venta y tickets, no facturas. Si tu software atiende a bodegas o pequeños negocios en ese régimen, tiene que bloquear la opción de factura para esos emisores.

El DNI en la boleta desde S/ 700

Cuando el importe de la boleta llega a S/ 700, el comprobante debe consignar el número de DNI y los nombres y apellidos del comprador. Por debajo de ese monto se puede emitir sin identificarlo, aunque nada impide hacerlo si el cliente lo pide o si tu negocio quiere llevar registro.

Para el sistema, esto implica tres cosas:

1. El umbral se evalúa sobre el total del comprobante, no línea por línea. Si un cliente agrega un producto y el total cruza S/ 700, el campo de DNI pasa de opcional a obligatorio en ese momento.
2. El DNI tiene que ser válido: 8 dígitos, guardado como texto para no perder ceros a la izquierda, y de preferencia verificado contra la fuente oficial. Con la API de DNI de endpoint.pe obtienes nombres y apellidos a partir del número, así el comprobante sale con el nombre correcto y sin tipeo.
3. Si el comprador es extranjero, el documento será un carnet de extranjería o un pasaporte, con su propio código en el catálogo de tipos de documento.

Un patrón de interfaz que funciona: el campo de DNI siempre visible, marcado como opcional, y que cambia a obligatorio con un aviso claro cuando el total cruza el umbral. Así el cajero no descubre el requisito al momento de cobrar.

Cómo decide tu sistema automáticamente

La decisión se puede modelar con pocas reglas. La entrada es lo que el cliente dice de sí mismo (tipo y número de documento, si quiere factura) y el total; la salida es el tipo de comprobante, la serie y los datos que faltan por validar.

// Códigos del catálogo de SUNAT para el tipo de documento de identidad
const DOC = { SIN_DOCUMENTO: "0", DNI: "1", CE: "4", RUC: "6", PASAPORTE: "7" };
const UMBRAL_DNI_BOLETA = 700;

function decidirComprobante({ tipoDoc, numeroDoc, total, quiereFactura }) {
  // Factura solo con RUC válido en formato
  if (quiereFactura) {
    if (tipoDoc !== DOC.RUC || !/^(10|15|17|20)\d{9}$/.test(numeroDoc)) {
      return { error: "La factura requiere un RUC válido" };
    }
    return { tipo: "01", serie: "F001", validar: ["ruc_activo", "razon_social"] };
  }

  // Boleta: identificación obligatoria desde el umbral
  const requiereIdentificacion = total >= UMBRAL_DNI_BOLETA;
  const identificado = tipoDoc !== DOC.SIN_DOCUMENTO && numeroDoc;

  if (requiereIdentificacion && !identificado) {
    return { error: "Desde S/ 700 la boleta debe llevar DNI y nombre del comprador" };
  }
  if (tipoDoc === DOC.DNI && !/^\d{8}$/.test(numeroDoc)) {
    return { error: "El DNI debe tener 8 dígitos" };
  }

  return {
    tipo: "03",
    serie: "B001",
    validar: identificado && tipoDoc === DOC.DNI ? ["nombres_dni"] : [],
  };
}

La función no consulta nada: solo decide y devuelve qué validaciones faltan. Esas validaciones las hace el backend antes de asignar número. Para una factura, consulta el RUC y comprueba estado, condición y razón social:

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

Con la API de consulta RUC la respuesta trae estado, condicion y razon_social. Si el estado no es ACTIVO, la regla más segura es bloquear la emisión y pedir confirmación. Si el RUC no existe, la API devuelve 404 y el comprobante no debe emitirse.

Dos decisiones de diseño que conviene tomar de una vez:

• Factura por defecto cuando hay RUC. Si el cliente dio un RUC, lo más probable es que quiera factura. Preselecciónala y deja que cambie a boleta si lo pide.
• Nunca cambiar de tipo después de numerar. Una vez asignado el correlativo, el comprobante es lo que es. Si hay que corregir, se anula con una nota de crédito y se emite otro, como explicamos en notas de crédito y débito.

Errores comunes y cómo evitarlos

• Boleta a una empresa que necesitaba factura. Causa: el cajero no preguntó. Prevención: si el sistema detecta un RUC, propone factura y muestra un aviso si se elige boleta.
• Factura a un RUC inexistente o de baja. Causa: número tipeado a mano, sin validar. Prevención: validación de formato con el dígito verificador y consulta a la fuente oficial antes de numerar.
• Boleta de más de S/ 700 sin DNI. Causa: el campo era opcional y nadie lo revisó al crecer el total. Prevención: el umbral se evalúa en cada cambio del carrito y el campo se vuelve obligatorio en caliente.
• Nombre del comprador mal escrito en la boleta. Causa: tipeo. Prevención: autocompletar nombres a partir del DNI y dejar los campos editables.
• Factura con razón social distinta a la de SUNAT. Causa: el cliente dictó el nombre comercial, no la razón social. Prevención: tomar la razón social de la consulta, no del formulario.
• Serie incorrecta para el tipo. Causa: configuración manual. Prevención: la serie se deriva del tipo de comprobante y del punto de venta, nunca la elige el usuario.

En resumen

• La factura va a compradores con RUC que necesitan sustentar gasto o usar crédito fiscal; la boleta, a consumidores finales.
• Una boleta no sirve para crédito fiscal: si el cliente es una empresa, pregunta antes de emitir.
• Desde S/ 700 la boleta debe consignar el DNI y el nombre del comprador; el umbral se evalúa sobre el total.
• Quien está en el NRUS solo emite boletas, nunca facturas.
• Tu sistema decide con pocas reglas: tipo de documento, formato, total y lo que el cliente pide; luego valida RUC o DNI contra la fuente oficial antes de numerar.
• Si te equivocaste de tipo, no se edita: se anula con nota de crédito y se emite el correcto.

Preguntas frecuentes

¿Puedo emitir factura a una persona natural sin RUC?

No. La factura requiere que el comprador esté identificado con RUC. Si una persona natural no tiene RUC, corresponde boleta de venta, con su DNI cuando el importe llega a S/ 700 o cuando ella lo pide.

¿Qué hago si emití boleta y el cliente quería factura?

A grandes rasgos, la boleta se anula mediante una nota de crédito y se emite la factura con los datos correctos. El procedimiento exacto y los plazos dependen de las reglas vigentes; confírmalo con tu contador antes de automatizarlo.

¿La boleta puede llevar el RUC del comprador?

Lo habitual es identificar al comprador de una boleta con DNI u otro documento personal. Si quien compra tiene RUC y va a sustentar la compra, lo que corresponde es una factura. Ante un caso particular, revisa la guía vigente de SUNAT.

¿Cómo evito que el cajero se equivoque de comprobante?

Haz que el sistema decida: si hay RUC válido, factura por defecto; si no, boleta; y si el total llega a S/ 700, el DNI se vuelve obligatorio. Valida el RUC o el DNI contra la fuente oficial antes de asignar número y deja la serie fuera del alcance del usuario.