Facturación electrónica y SUNAT: conecta

En tu día a día, la facturación electrónica es una obligación que no puedes delegar, pero tampoco puedes permitir que rompa la cadena de procesos que ya funcionan en tu empresa. En este artículo encontrarás una guía práctica para conectar SUNAT con los sistemas que ya usas, sin perder tiempo ni generar errores.

Con qué se tiene que hablar

Antes de tocar cualquier línea de código, es fundamental mapear los sistemas que ya están en producción. En la mayoría de las medianas empresas peruanas, estos son:

• ERP de gestión contable (puede ser un módulo financiero de un ERP general o una solución a medida).
• Sistema de ventas (punto de venta, e‑commerce o B2B).
• Plataforma de compras (ordenes de compra, gestión de proveedores).
• Módulo de nómina que ya envía datos a SUNAT para retenciones.
• Herramientas de reporting (Power BI, Tableau) que consumen datos de facturación.

Estos sistemas no se van a tirar; la meta es que la facturación electrónica se convierta en un servicio que se invoque desde ellos, como cualquier otro proceso interno. Identifica los puntos de integración actuales (web‑services, bases de datos, colas de mensajes) y verifica que existan canales seguros y con trazabilidad. En muchos casos, el ERP ya expone un API REST o SOAP que permite crear, actualizar o anular documentos; si no lo hace, será necesario desarrollar un adaptador interno.

SUNAT y facturación electrónica

Requisitos técnicos

SUNAT exige que los comprobantes electrónicos cumplan con el Formato UBL 2.1 y que sean firmados digitalmente con un certificado vigente. Además, el proceso debe seguir la secuencia:

1. Generación del XML con los datos del comprobante.
2. Firma electrónica usando el certificado del contribuyente.
3. Envío al servicio de SUNAT (API de Resumen Diario o Emisión de Comprobantes).
4. Recepción del CDR (Constancia de Recepción) y registro del código hash.
5. Almacenamiento del XML y del CDR en tu repositorio interno.

Errores típicos y cómo evitarlos

• El XML no pasa la validación de SUNAT. La causa suele ser campos obligatorios vacíos o formatos de fecha incorrectos; usar un validador local antes del envío reduce el rechazo en un 80 %.
• El certificado expira y los envíos fallan. Programa una alerta de 30 días antes del vencimiento y automatiza la renovación.
• Los códigos de respuesta de SUNAT no se procesan. Implementa una tabla de mapeo de códigos a acciones (re‑intento, corrección manual, anulación).

Tiempos de respuesta

• Envío y respuesta: SUNAT responde en promedio 5 segundos; sin embargo, en horarios pico puede tardar hasta 30 segundos.
• Reintentos: Configura un reintento automático cada 2 minutos, máximo 3 intentos, antes de escalar a soporte.

Cobros y bancos

Los pagos electrónicos en Perú se están diversificando: Yape, Plin, Niubiz y Izipay son los canales más usados. Cada uno ofrece una API distinta, pero el patrón de integración es similar.

1. Generar la orden de pago: después de que SUNAT devuelve el CDR, tu sistema debe crear una solicitud de cobro a la pasarela del banco.
2. Enviar la solicitud: la mayoría usa REST con JSON; se requiere token de autenticación (OAuth 2.0 o API‑Key).
3. Confirmar el pago: la pasarela envía una notificación webhook; tu ERP debe consumirla y marcar la factura como pagada.
4. Conciliación: al final del día, genera un reporte de conciliación que cruce los pagos recibidos con los CDR emitidos.

Comparativa rápida de pasarelas

Para una empresa que ya tiene un ERP con capacidad de consumir web‑services, la opción Niubiz suele ser la más flexible porque permite tanto SOAP (para sistemas legados) como REST (para módulos nuevos). En cambio, Yape es ideal para micro‑ventas y requiere menos infraestructura, pero su API solo está disponible en REST.

Qué pedirle al proveedor

Cuando evalúas un nuevo módulo o una solución a medida, la hoja de requisitos debe contener:

• Especificación OpenAPI/Swagger del servicio de facturación electrónica. Esto incluye los endpoints de generación, envío y consulta de CDR.
• Versionado claro: cada cambio de versión debe mantener compatibilidad backward por al menos 12 meses.
• Documentación de errores con códigos HTTP y mensajes en español, para que tu equipo de soporte pueda automatizar la gestión.
• Webhooks de eventos (p. ej., “comprobante aceptado”, “rechazo por error de formato”).
• Política de cambios: si el proveedor actualiza su API, debe notificar con al menos 30 días de antelación y ofrecer un sandbox para pruebas.

Qué ocurre cuando la otra parte cambia

1. Impacto inmediato: si el endpoint cambia sin aviso, tus procesos de envío fallarán y generarás rechazo en SUNAT.
2. Mitigación: implementa una capa de proxy que traduzca la llamada de tu ERP al endpoint actual del proveedor. Así, solo el proxy necesita actualizarse.
3. Pruebas de regresión: mantén un conjunto de pruebas automáticas que simulen la generación y envío de un comprobante cada semana. Si alguna prueba falla, detectas el cambio antes de que afecte la producción.

Conclusión

Al conectar la facturación electrónica de SUNAT con los sistemas que ya usas, el éxito depende de tres pilares: mapear los puntos de integración existentes, cumplir al pie de la letra los requisitos técnicos de SUNAT y establecer contratos claros con los proveedores de APIs y pasarelas de pago. Con un plan de pruebas semanal, alertas de certificado y una capa de proxy para aislar cambios externos, puedes lograr una integración estable en 4‑6 semanas de trabajo, dedicando alrededor del 30 % del esfuerzo al desarrollo y el resto a pruebas y documentación. Así, tu empresa mantiene la continuidad operativa mientras cumple con la normativa peruana.

Una integración bien diseñada permite que la facturación electrónica se convierta en un proceso automático, sin interrupciones en tus sistemas actuales.