Paso a producción

Este contenido está verificado el 15/10/2026, con vigencias al 16/10/2026. Cada afirmación dice si su fuente es norma (obligación) o documentación técnica de la SUNAT (formatos y servicios; no crea obligaciones). «Verificado» quiere decir que se leyó el texto de la fuente. «No verificado» quiere decir que la fuente no se abrió o no se encontró, y dice qué faltó. Las marcas no se quitan ni se suavizan.

Alcance. SEE - Del contribuyente (RS 097-2012/SUNAT y modificatorias), con certificado y usuario SOL del propio contribuyente. Fuera de esta página: la modalidad PSE (plataforma que firma o envía con credencial propia) y la custodia de la clave privada.

1. Qué necesita el contribuyente para emitir así

Conclusión: hoy no hay homologación ni solicitud de autorización. Para ser emisor del SEE - Del contribuyente por elección basta indicarlo en SOL y cumplir las condiciones del art. 6 de la RS 097-2012 (RUC en regla, afecto a renta de tercera categoría o NRUS, y un certificado digital vigente registrado en SOL más un correo electrónico). Para enviar necesitas además un usuario SOL secundario con perfil de envío.

1.1 La RS 287-2017 sí reemplazó la parte que importa (verificado en el primario)

Norma: RS 287-2017/SUNAT, Lima 08/11/2017, vigente desde el día siguiente de su publicación (DCF única; la fecha de publicación en El Peruano no la verifiqué).

• Art. 2: sustituye el segundo párrafo del art. 3, los arts. 6 y 6-A, el numeral 10.2 y otros de la RS 097-2012.
• Primera disposición derogatoria: deroga los arts. 4, 5 y 8 y el anexo 7 (declaración jurada) de la RS 097-2012. Esos arts. eran la solicitud de autorización, su presentación y la nulidad.
• Considerandos: la resolución «elimin[a] la presentación de la solicitud de autorización así como el procedimiento de homologación».
• Consecuencia para el contenido: el texto original de los arts. 3-6 (solicitud, homologación, resolución en 30 días hábiles) ya no rige. No lo cites.
• Aclaración: la «homologación» que la RS 108-2022 derogó (art. 5 e de la RS 199-2015) es otra cosa: el requisito para inscribirse como PSE.
• Desfase de documentación técnica: el Manual del Programador v2.1 (mayo 2021), §2.2, todavía lista una URL «para envío en el proceso de homologación» (https://www.sunat.gob.pe/ol-ti-itcpgem-sqa/billService). Es documentación técnica y no una exigencia; no la pongas como paso. Si ese servicio sigue activo: no verificado.

1.2 Condición de emisor y requisitos (norma, verificado)

Dato de contexto: la RS 075-2026 (29/04/2026, vigente 01/06/2026) designa a los nuevos inscritos en MYPE, Régimen Especial o General desde el día de su inscripción en el RUC. La URL exacta del PDF no la abrí.

Condición extra para facturas (norma, verificado): RS 302-2024 (29/12/2024, vigente el día siguiente de su publicación) agrega el numeral 10.6 al art. 10 de la RS 097-2012: una factura o nota no se considera emitida si el emisor está en las publicaciones de «sujetos sin capacidad operativa» del D. Leg. 1532 (art. 12.5 explica que lo enviado no tiene calidad de factura). Efecto en el desarrollo: el rechazo puede venir del estado del emisor y no del XML. La URL del PDF de la RS 302-2024 no la abrí.

1.3 Certificado digital

• Registro en SOL: norma, art. 6.3 a) i). Manual 2.1 §3.1 b): se comunica con la opción «Actualización de certificado digital» del menú SOL (documentación técnica; el nombre de la opción en el portal de hoy: no verificado).
• Requisitos técnicos (documentación técnica, Manual 2.1 §3.1 a y c, p. 26): X.509 v3; clave privada mínimo 1024 bits; identifica al titular con nombres y DNI y el RUC de la empresa; el RUC va en el campo OU del Subject; vigente y no revocado (la SUNAT valida ambas cosas). Si falla: rechazo 2325 (no es el comunicado a SUNAT), 2326 (de baja), 2327 (no vigente), 2328 (revocado), 2335 (documento alterado), 2336 (error validando la firma): hoja CódigosRetorno, reglas de validación 24.04.2026.
• Qué tipo de certificado (norma): la «firma digital» del SEE es la del art. 6 del Reglamento de la Ley de Firmas y Certificados Digitales, D.S. 052-2008-PCM, con certificado que consigne «nombres y apellidos, la denominación o razón social y el número de RUC del titular» (RS 097-2012 art. 2, num. 2.12, texto RS 251-2012/SUNAT, 30/10/2012). Un certificado de persona con otro RUC no sirve.
• Certificado Digital Tributario (CDT): opción gratuita de la SUNAT para quien factura hasta 300 UIT (S/ 1 260 000 en 2019), está afecto a renta de tercera categoría, no está en el Registro OSE ni PSE y no tiene otro CDT vigente. Norma: RS 038-2020/SUNAT arts. 2 y 3.1. Solo sirve para firmar comprobantes por operaciones de su titular (art. 2). No verificado: que la SUNAT siga emitiéndolo hoy. La facultad temporal (Ley 27269, 4.ª DCTF) tenía tope 30/06/2020; una nota del Congreso del 29/12/2025 (enlace) dice que la Comisión Permanente aprobó prorrogarla hasta el 31/12/2027, sin número de ley ni publicación. Qué faltó: el texto publicado en El Peruano y la página del CDT (cpe.sunat.gob.pe/certificado-digital respondió 403 a la consulta automatizada).
• Lo que no es el SDK: un certificado de prueba autogenerado no pasa 2325-2328 en producción.

1.4 Usuario SOL secundario y su perfil

• Se puede y lo crea el contribuyente (norma, verificado): RS 109-2000 art. 4, 2.º párrafo (texto RS 159-2007): el Usuario puede generar otros códigos de usuario y claves SOL para usuarios subordinados, con autorización para todas o algunas de las operaciones. Art. 6 (RS 175-2017): lo que hagan se le atribuye al contribuyente. Texto: RS 109-2000.
• El perfil no está en la norma (documentación técnica): Manual 2.1 §2.2, p. 14: la clave debe ser «de tipo secundaria» y tener el perfil «Envío de documentos electrónicos - Grandes emisores» (Manual).
• Cómo lo rechaza el servicio (hoja CódigosRetorno, 24.04.2026): 0111 sin perfil para enviar, 0112 «El usuario debe ser secundario», 0113 no afiliado a Factura Electrónica, 0102-0105 usuario o clave inválidos, 0154 el RUC del archivo no corresponde al RUC del usuario o el proveedor no está autorizado.
• Pasos en el portal: no verificado en fuente SUNAT (ninguna guía de SUNAT con los pasos pudo abrirse: cpe.sunat.gob.pe da 403). No copies la ruta de menús de blogs de terceros; redacta «crea un usuario secundario con el perfil de envío» y marca el menú como pendiente.
• Credencial en el servicio: WS-Security UsernameToken; Username = RUC + usuario concatenados, Password = clave (Manual §2.2, p. 14).

1.5 ¿Algún otro paso previo?

No encontré en lo que leí otro paso normativo previo para el SEE - Del contribuyente por elección. No verificado, y cambiaría el texto si existiera: (a) si te corresponde por designación usar un OSE (RS 239-2018 y modificatorias, sin leer); (b) la obligación de llevar registros por SIRE (RS 112-2021, RS 075-2026 art. 1, sin leer completa). Series y rangos: no revisé qué exige el sistema para la serie del emisor.

2. Beta frente a producción

Conclusión: la beta prueba que tu XML tiene estructura válida y que tu cliente SOAP arma bien el envío; no prueba que puedas emitir. Una CDR de beta no es comprobante ni evidencia de cumplimiento.

2.1 Endpoints (documentación técnica, «Servicios web disponibles» mayo 2026 y Manual 2.1 §2.1)

Fuente: Servicios web disponibles, PDF de SUNAT de mayo 2026, consultado el 15/10/2026.

La guía de remisión tiene otro servicio y no entra en la fase 1 del SDK. Cada tipo tiene su método: sendBill (un XML en ZIP → CDR en ZIP, síncrono; factura y notas), sendSummary (resumen y baja → ticket), getStatus (ticket), sendPack (lote). Manual §2.4-2.5.

2.2 Qué dice la SUNAT de la beta (documentación técnica)

• Manual 2.1 §2.3: «servicio de pruebas alternativo»; «solo permite realizar pruebas de las estructuras XML»; «no es necesario contar con un certificado digital registrado en SUNAT». Credenciales de beta que documenta el Manual del Programador 2.1, §2.3: usuario [RUC]MODDATOS, clave MODDATOS. Vigencia en 2026: no verificada; el PDF de mayo 2026 no las repite.
• El PDF de mayo 2026 repite que es «servicio exclusivo para pruebas».

2.3 Qué prueba una aceptación en beta y qué no (derivado de lo anterior; es lectura, no texto SUNAT)

Sobre la firma en beta: no verificado si la beta valida la firma o solo la estructura. No escribas «la beta valida tu firma».

Estado del SDK: la aceptación en beta es pendiente. Lo permitido es «el CI prueba el fixture», no «aceptado por SUNAT».

3. Plazos de envío y de baja (vigentes al 16/10/2026)

Conclusión: factura y sus notas, 3 días calendario; boleta y sus notas, hasta 5 días calendario si las envías una a una, o resumen diario hasta el 7.º día; baja, 7 días calendario. Todos se cuentan desde el día calendario siguiente. Son plazos de envío; no son plazo para emitir, corregir, declarar ni pagar.

Zona horaria America/Lima. Cuenta en días calendario (no hábiles). Si cae en día no laborable, lo que leí no dice que se prorrogue: no verificado, no lo asumas.

Ejemplo (calendario, sin feriados): factura emitida el 16/10/2026 → se envía hasta el 19/10/2026; boleta enviada una a una → hasta el 21/10/2026; resumen diario o baja con CDR aceptada el 16/10 → hasta el 23/10/2026.

Consecuencia de vencer (norma + orientación):

• Factura/nota: «lo remitido […] transcurrido ese plazo no tendrá la calidad de factura electrónica […] aun cuando hubiera sido entregado al adquirente» (art. 12, texto RS 114-2019). La SUNAT lo repite en su FAQ (copia de 09/09/2026). Para boleta, el texto que leí dice que, vencidos los 5 días, el camino es el resumen diario.
• La fecha de emisión consignada puede anticiparse a la que correspondía según el art. 5 del RCP si decides anticipar la emisión (misma norma); no cambies la cronología para que pase.
• No verificado: infracciones y sanciones, y efecto en el crédito fiscal del adquirente.

Fuera de este sistema (no los traslades): DAE y recibo SP, 7 días; liquidación de compra, hasta el día siguiente; SFS y OSE tienen su propia norma (RS 003-2023 arts. 4 y 5).

4. Estados de respuesta, CDR, ticket y timeout

Conclusión: la aceptación es la CDR con estado, nunca un HTTP 200, un PDF o un ticket. Ante un timeout el resultado es desconocido: consulta y concilia antes de reenviar.

4.1 Cómo responde el servicio (documentación técnica, Manual 2.1 §4.1, pp. 28-29)

Clasificación verificada contra la hoja de códigos de respuesta (24.04.2026). Excepciones sobre el número: 1033 (ya registrado con otros datos: recupera su CDR con getStatusCdr, no reenvíes ni reuses) y 1032 (informado y anulado o rechazado: no se reusa).

Norma de la CDR (RS 097-2012 art. 13, texto RS 114-2019 párr. 2.4): para factura y notas la CDR tiene estado aceptada o rechazada y, si rechaza, el motivo; la SUNAT avisa al adquirente por buzón. Para la boleta y su nota, el texto solo exige que la CDR traiga numeración, firma de la SUNAT y hora de recepción; el estado de un resumen lo da la CDR-Resumen diario (aceptada o rechazada). Cuando el resumen es el que informa la boleta, la «aceptación» de la boleta es la de ese resumen.

4.2 Ticket y consulta

• Envío asíncrono (resumen diario, baja, reversión): sendSummary devuelve un ticket; con getStatus(ticket) obtienes el estado y, al terminar, la CDR (Manual §2.4, §2.7.2). Estados de getStatus: 0 y 99 con CDR, 98 en proceso (contrastar con el Manual al implementarlo).
• Factura y notas: getStatusCdr(RUC, tipo, serie, número) recupera la CDR (Manual §2.7.1); está solo en producción. La boleta individual no figura en el §2.7.1: no verificado si getStatusCdr la cubre.
• Códigos de ticket: 0125 no se pudo obtener la constancia, 0126 el ticket no es del usuario, 0127 el ticket no existe, 0140 existe un documento igual en proceso.

4.3 Timeout o respuesta perdida

1. No reemitas con otro número ni cambies de canal a ciegas.
2. Facturas y notas: getStatusCdr con el mismo RUC, tipo, serie y número. Resúmenes y bajas: getStatus con el ticket; si no lo recibiste, consulta por el identificador del resumen con tu registro de envíos.
3. Hay CDR → ya está resuelto, guárdala. «No encontrado» → recién ahí reenvía el mismo documento, mismo número, dentro del plazo de la sección 3 (0140 y 1033 te dicen que ya estaba o está en proceso).
4. Sin respuesta y plazo por vencer: reenvía el mismo documento sin cambiar el número; no inventes uno nuevo (el plazo se cuenta desde el día siguiente a la fecha de emisión consignada, no desde que reintentas).

Derivado de la clasificación de excepción/rechazo y de las reglas de números usados; el Manual no tiene una sección expresa de «timeout». No verificado: tiempos de espera recomendados y límites de frecuencia de consulta.

5. Contingencia

Conclusión: no existe una «contingencia electrónica» en este sistema. Si la SUNAT no responde o tu software falla, reintenta y concilia dentro del plazo de la sección 3. La contingencia de la norma es emitir en papel (formato impreso o de imprenta autorizada) y luego informarlo en un resumen de comprobantes impresos; solo está prevista para el emisor designado por la SUNAT y por causas que no le son imputables.

Fuente: RS 300-2014/SUNAT, art. 4 (leída del PDF por OCR, texto de 2014, págs. 7-9).

• 4.1: el «emisor electrónico por determinación de la SUNAT que, por causas no imputables a él, esté imposibilitado de emitir» puede emitir en formatos impresos, y debe dar a la SUNAT el resumen de comprobantes impresos (4.2).
• 4.1 b): el emisor por elección «no está impedido de emitir» en impreso «cuando corresponda»; lo que leí no le impone el resumen.
• 4.2 b): el resumen se envía el día de la emisión o, a más tardar, hasta el 7.º día calendario desde el día siguiente; una declaración por día.
• Quién puede enviarlo: ser emisor por determinación (art. 4.2 c i, texto RS 287-2017 art. 3, que también quitó la referencia a homologación; y RS 013-2019 art. 4-B para documentos autorizados).
• Dónde se envía: Manual 2.1 §4.3 (2021): opción de SOL con archivo TXT/ZIP, nombre RUC-RF-DDMMAAAA-NN. Desde el 01/08/2026, la RS 049-2026 crea el PEI Web, que reemplaza al PEI de la RS 159-2017 (art. 1 y DCF primera; el art. 9.2 remite al art. 4 de la RS 300-2014 para el plazo del resumen de comprobantes impresos).

Qué le cambia al SDK: nada que construir para la contingencia (es papel + declaración en SOL o PEI Web, fuera del XML). El resumen RC del SDK es el resumen diario de boletas, otro documento.

No verificado, y por qué: (1) el texto vigente del art. 4 de la RS 300-2014: el que leí es el original de 2014; fue modificado por RS 287-2017, 114-2019, 013-2019 y 049-2026 y no abrí una versión consolidada; los numerales (4.1 f, 4.2.4, 4.6) ya no coinciden con el original; (2) si una caída de tu propio software cuenta como «causa no imputable» (lectura prudente: no); (3) la URL del PDF de RS 049-2026. Corpus: cpe.sunat.gob.pe respondió 403 a consultas automatizadas.

Lo que no se abrió (resumen para el desarrollador y para Manuel)

1. Texto consolidado vigente de los arts. 12 y 21 de la RS 097-2012 y del art. 4 de la RS 300-2014 (solo las normas modificatorias).
2. Pasos de portal SOL: crear el usuario secundario con perfil, registrar el certificado. Sin fuente SUNAT abierta.
3. Si hoy se emiten CDT y la publicación de la prórroga en El Peruano.
4. Obligación de OSE por designación (RS 239-2018) y de SIRE; infracciones por envío tardío.
5. Credenciales beta vigentes y si la beta valida la firma.
6. Fecha de publicación en El Peruano de RS 287-2017, 302-2024, 075-2026.