Saltar al contenido
Krezkadev

El ciclo SUNAT

Qué significa cada estado de un comprobante y qué hacer en cada uno.

Emitir no es un paso: son tres. Tu solicitud, la firma y el envío, y la respuesta de SUNAT. El estado del comprobante te dice en cuál está.

EstadoSignificaQué hacer
pendingKrezka lo aceptó, asignó correlativo y lo puso en cola.Nada. Guarda el id y el full_number.
sentEl XML firmado salió hacia SUNAT.Nada. Suele durar segundos.
acceptedSUNAT lo aceptó. El CDR está disponible.Es válido. Entrega el PDF al cliente.
observedSUNAT lo aceptó con observaciones.Es válido. Lee el mensaje y corrige en adelante.
rejectedSUNAT lo rechazó.Corrige y emite uno nuevo. Este no se cobra.
reconcilingSUNAT dice que el documento ya está registrado, pero no devuelve el CDR.No lo reemitas. Espera el webhook.
voidingComunicación de baja enviada.Espera invoice.voided.
voidedLa baja fue aceptada.Revierte la venta en tu sistema.

Si SUNAT no responde

Si SUNAT está caída, el comprobante se queda en sent y Krezka reintenta solo. No emitas de nuevo: usarías otro correlativo para la misma venta. Cuando SUNAT vuelva, llega el webhook con el resultado.

Si Krezka no responde

Si tu POST no recibe respuesta (timeout, 5xx), reintenta con la misma Idempotency-Key. Si el comprobante ya se había creado, recibes el mismo; si no, se crea ahora. Nunca se emiten dos.

El CDR

El CDR es la constancia de SUNAT. Está disponible en GET /invoices/{id}/cdr desde accepted, observed o rejected. Guárdalo si tu auditoría lo exige; Krezka lo conserva de todos modos.

reconciling: el estado que existe para que no dupliques

A veces SUNAT responde que el comprobante ya está registrado (código 1033) sin devolver el CDR. El documento existe para SUNAT; lo que falta es la constancia.

Es poco frecuente pero real: al escribir esto son 118 comprobantes de 18,207 — 6 de cada mil. Lo peligroso no es el estado, es la reacción. Si lo leyeras como rejected corregirías y emitirías de nuevo, y tendrías dos comprobantes para una sola venta, los dos válidos ante SUNAT. Deshacer eso son dos comunicaciones de baja y una conversación con tu cliente.

Por eso reconciling no es un error ni un rechazo. Significa: está en SUNAT, nos falta el papel, lo estamos resolviendo. Lo único que tienes que hacer es nada.

Krezka reconsulta hasta obtener el CDR y te avisa con invoice.accepted (o invoice.rejected, si al final SUNAT lo rechazó). Mientras tanto:

  • El comprobante ya consume su correlativo: no lo reutilices.
  • GET /invoices/{id}/cdr devuelve 404 hasta que el CDR llegue — por eso sunat.cdr_available es false.
  • El PDF se genera igual: es válido para entregarle al cliente.

Nunca reemitas un comprobante en reconciling

Si tu integración trata cualquier estado que no sea accepted como "falló, reintentar", este es el que te va a morder. Trata explícitamente reconciling como "esperar".