Autorización de un sistema de facturación en los servicios SOAP v3: pruebas, inspecciones y vigencia

Experiencia de un proceso de pruebas en piloto, el cierre de pruebas y el estado AUTORIZADO, el mensaje de finalización, el documento de autorización, la actualización de v2 a v3, la asociación de NIT, la inspección, los eventos 5, 6 y 7, los errores 976 y 901, la vigencia y los puntos por confirmar

Experiencia compartida en el grupo; no constituye norma. Este artículo describe el proceso de pruebas y autorización de un sistema de facturación sobre los servicios SOAP de la versión 3 (v3), tal como lo relató un participante con las capturas de los mensajes oficiales. Sirve como referencia de los pasos y de los mensajes que aparecen. Los plazos y condiciones deben confirmarse en la norma vigente y con el SIN.

Secuencia observada

1. Pruebas en piloto. El sistema consume los servicios de facturación v3 del ambiente piloto (ver el artículo sobre servicios web v2 y v3).
2. Finalización de pruebas. Al cerrar las pruebas, el sistema pregunta si se está seguro de finalizarlas y muestra una advertencia antes de confirmar. Indica que la administración tributaria dispone de 3 inspecciones y de un plazo de 30 días para autorizar el sistema, y que el detalle de las inspecciones se envía por correo electrónico y al buzón tributario. El plazo de 30 días no está confirmado (ver la sección siguiente).
3. Autorización. Si el sistema cumple, el SIN emite un comunicado que indica que se superaron las pruebas de los servicios SOAP Facturación V.3 y que se emite la autorización.

Cierre de pruebas y estado AUTORIZADO

Experiencia compartida en el grupo; no constituye norma.

Un participante describió cómo se llega al cierre de las pruebas en el ambiente piloto de la v3:

• El ambiente muestra un contador de avance de los paquetes de prueba. El botón «Finalizar pruebas» se habilita solo cuando el contador llega al 100 %.
• En el caso relatado, el avance estaba en 80 % porque faltaban los envíos de los eventos 5, 6 y 7. Al completarlos, el contador llegó al 100 % y el proceso avanzó sin intervención manual del participante.
• Otro participante observó que, aunque el botón seguía deshabilitado, el estado del sistema cambió de «EN PRUEBAS» a «AUTORIZADO» y el contador de días restantes quedó en cero. Antes de dar por cerrado el proceso, conviene verificar ambos indicadores.

Para los eventos 5, 6 y 7 véase el artículo sobre el error 976 en la v3 del SIAT.

Qué contiene el documento de autorización

El documento compartido es un comunicado titulado Actualización de sistemas informáticos de facturación. Sus campos principales son:

Conviene revisar que las modalidades y los documentos sector del documento coincidan con lo que el sistema va a emitir. Una modalidad o documento sector no listado no queda cubierto por la autorización.

Vigencia de la autorización: v2 y v3

Interpretación de un participante, no confirmada por una norma de la wiki.

Según lo comentado en el grupo:

• La autorización de la v2 tendría una vigencia de 3 años y un proceso de inspección.
• La autorización de la v3, según el PDF de autorización recibido, indicaría una vigencia de 1 año.
• La autorización de la v3 no reemplazaría la de la v2. Por eso podrían coexistir dos fechas de validez para el código del sistema: 3 años para la v2 y 1 año para la v3.

Este punto no está confirmado. Antes de planificar renovaciones, consulte al SIN por escrito cómo se aplicará la vigencia de cada versión.

Ventana normativa

La RND 102600000034 establece que los sistemas propios o de proveedor deben cumplir el Anexo Técnico Ley 1733 para las pruebas en piloto y la autorización, en el periodo del 01/10/2026 al 16/11/2026. En el caso relatado, la autorización es de fecha 29/10/2026, dentro de ese periodo. El relato no indica si el sistema cumplió el Anexo Técnico, por lo que esta condición debe verificarse.

En el grupo se mencionó que el plazo para concluir las pruebas piloto sería el día 16. Esa fecha coincide con el cierre de la ventana, pero la fuente no confirma si la ventana aplica a todos los cambios de la v3. Verifique la norma y los comunicados del SIN antes de planificar.

Validación de paquetes y pruebas de eventos 5, 6 y 7 en el piloto v3

Durante las pruebas en piloto de la v3 aparecen problemas recurrentes: el paquete de facturas queda en estado PENDIENTE al validarlo, el evento 5 puede ser rechazado, y no siempre está claro si las pruebas de los eventos 5, 6 y 7 requieren CAFC.

Caso 1: el paquete de facturas queda en estado PENDIENTE

Problema planteado. La recepción del paquete de facturas de la v3 devuelve un código de recepción sin errores, pero al validarlo el estado permanece PENDIENTE y no es posible avanzar con las pruebas piloto.

Qué indica la lista de códigos. En la lista de códigos de respuesta del SIAT, el código 901 corresponde a recepción pendiente. Un estado pendiente significa que el SIAT aún no terminó de procesar el paquete, por lo que, antes de cambiar datos, conviene confirmar la recepción y reconsultar.

Solución reportada. Un participante notó que la validación era lenta y que, al repetir la validación del mismo paquete por segunda o tercera vez, el estado pasó a VALIDO. Por eso se recomienda reintentar la validación sin reenviar el paquete, dejando un intervalo razonable entre intentos. Otro participante indicó que pudo continuar usando el otro servicio de validación del paquete. No se confirmó en el grupo si se refería al servicio de la v2 o a otro método de la v3, por lo que este punto debe verificarse antes de aplicarlo.

Si el estado no cambia tras varios reintentos, otro participante sugirió revisar los errores individuales de cada factura con una herramienta de pruebas de servicios SOAP, porque la respuesta del servicio puede no detallarlos. Después, consulte al soporte técnico con el código de recepción.

Campos de la solicitud de validación. Según el ejemplo compartido, la solicitud incluye: codigoAmbiente, codigoDocumentoSector, codigoEmision, codigoModalidad, codigoPuntoVenta (opcional), codigoSistema, codigoSucursal, cufd, cuis, nit, tipoFacturaDocumento y codigoRecepcion. El codigoRecepcion es el que devuelve el SIAT al recibir el paquete; sin él no puede consultarse el resultado.

Fórmula. Las fuentes no definen un cálculo para este caso. El control es operativo: reconsultar con el codigoRecepcion devuelto y no reenviar el paquete mientras el estado siga pendiente.

Ejemplo ilustrativo (intervalos no fijados por norma). Se envía el paquete a las 10:00 y la respuesta es 901. Se reconsulta a las 10:15 y a las 10:30 con el mismo codigoRecepcion. Si a las 11:00 sigue PENDIENTE, se registra el caso con el número de envío y se consulta al soporte técnico.

Caso 2: evento significativo 5 rechazado con código 976

Problema planteado. Al intentar registrar el evento significativo 5, el sistema respondió 976 – EL CÓDIGO DEL EVENTO ES INCORRECTO.

Solución reportada. Un participante recomendó reenviar los eventos desde el 1 hasta el 4, después de lo cual el contador de la certificación llegaría al 100%. Otro participante reportó que el problema se resolvió tras una gestión por ticket, pero no se confirmó qué acción del SIN lo corrigió. El reenvío no está confirmado como solución oficial: consulte al soporte técnico del SIN antes de aplicarlo.

Fórmula de avance (ilustrativa, no oficial). Avance = eventos aceptados / eventos requeridos × 100.

Ejemplo numérico ilustrativo. Con 4 eventos aceptados de 5 requeridos, el avance es 4 / 5 × 100 = 80%. Cuando el evento 5 también sea aceptado, el avance sería 5 / 5 × 100 = 100%.

Caso práctico: error 976 en los eventos 5, 6 y 7 con avance parcial de la lista de pruebas

Problema planteado. La lista de pruebas en el piloto tenía 32 registros, paginados de 5 en 5. En la captura compartida el avance general era de 78%, y las pruebas de la modalidad Electrónica en Línea de los sectores educativo y ventas estaban aprobadas hasta la página 4. Al llegar a las páginas 5 a 7, que corresponden a los eventos 5, 6 y 7, el registro del evento respondió 976 - EL CODIGO DEL EVENTO ES INCORRECTO. Según la guía del SIAT, estos eventos habilitan facturas manuales de contingencia con CAFC. Otro participante reportó el mismo error con documento sector 11. Un tercer caso de la misma modalidad y sectores no presentó el error, lo que sugiere que el problema depende de la configuración de cada caso y no solo de la modalidad.

Parámetros del ejemplo compartido (evento 5, virus informático o falla de software).

Solución. No hay solución oficial compartida, y el participante consultó al SIN sin que la respuesta se compartiera en el grupo. Antes de escalar, en la práctica conviene verificar:

• Que codigoEvento contenga el número del tipo de evento (5, 6 o 7). La descripción del ejemplo lo presenta como código de recepción, lo que puede confundir ambos valores. Confirme en la documentación del método registroEventoSignificativo.
• Que cantidadFacturas, codigoDocumentoSector y codigoEmision coincidan con lo declarado.
• Si el error persiste, reúna las capturas del listado, el mensaje exacto y los parámetros enviados, y consulte al soporte técnico del SIN.

Fórmula del avance de la lista (captura del participante). Avance = registros aprobados / registros totales × 100. No es la misma medida que el avance de eventos de la sección anterior.

Ejemplo numérico. Con 32 registros, las páginas 1 a 4 suman 20 registros: 20 / 32 × 100 = 62,5%. La captura mostró 78%, que equivale a unos 25 registros aprobados (25 / 32 × 100 = 78,1%). Esto indica que hay aprobaciones fuera de las páginas 1 a 4. Verifique en el listado qué registros figuran como aprobados.

Caso práctico: contador de pruebas al 80 % y cierre de pruebas

Problema planteado. El botón «Finalizar pruebas» del ambiente piloto v3 estaba deshabilitado. El contador de avance de los paquetes de prueba marcaba 80 % porque faltaban los envíos de los eventos 5, 6 y 7.

Solución reportada. Completar los envíos pendientes de los eventos 5, 6 y 7. Según el participante, al completarlos el contador llegó al 100 % y el proceso avanzó sin intervención manual. Tras esto, el botón se habilitó. Otro participante observó que el estado del sistema pasó a «AUTORIZADO» aunque el botón seguía deshabilitado. Esta conducta no está confirmada como regla y debe verificarse.

Fórmula. No definida en las fuentes. El contador se toma como indicador visual del avance de las pruebas, sin fórmula oficial publicada.

Ejemplo ilustrativo. Si el contador marca 80 % y faltan los eventos 5, 6 y 7, el cierre no se habilita. Al completar esos envíos, el contador debe llegar al 100 %. Luego se verifica que el botón esté habilitado, que el estado del sistema figure como «AUTORIZADO» y que el contador de días restantes esté en cero.

Plantilla de envío de eventos de prueba

El grupo compartió una plantilla con tres tipos de evento (falla de software o virus, cambio de infraestructura o falla de hardware, y corte de suministro de energía eléctrica). Cada uno se envía en dos variantes:

En todas las variantes: codigoAmbiente 2 (piloto), codigoEmision 2, codigoSucursal 0, codigoRecepcion «no aplica» y tipoFacturaDocumento 1. En la plantilla, codigoEvento se describe como el código de recepción del evento ya registrado, por lo que el evento debe registrarse antes de enviar el paquete. Esa descripción no está confirmada (ver el caso práctico anterior).

Pasos recomendados

1. Verificar el valor que exige codigoEvento en la documentación oficial, registrar el evento significativo y guardar su código de recepción.
2. Enviar el paquete con ese código en codigoEvento y codigoRecepcion «no aplica».
3. Consultar el resultado con la validación del paquete, usando el codigoRecepcion devuelto.
4. Si el estado sigue en PENDIENTE, reintentar la validación sin reenviar el paquete. Si persiste, registrar el caso con el número de envío y consultar al soporte técnico.
5. Si el piloto exige eventos 5, 6 o 7 con CAFC, solicitarlo por el canal oficial y no suponer que el CAFC va en el XML del evento.

Nota: los pasos 2 y 4, el uso del otro servicio de validación, la plantilla de envío, la fórmula de avance y el comportamiento del contador y del estado AUTORIZADO se basan en la práctica reportada en el grupo, no en una norma. Confirme con el SIN antes de aplicarlos en producción.

Novedades de la experiencia en pruebas v3

Experiencia compartida en el grupo; no constituye norma. Los siguientes puntos fueron observados por los participantes y no reemplazan el comunicado ni la normativa del SIN.

Asociación de nuevos NIT durante las pruebas v3

Un participante reportó que, mientras se está en pruebas de la v3, no es posible asociar nuevos NIT. Otro confirmó que el problema continúa y no es un error ya corregido. Algunos participantes consideraron este comportamiento un error, pero no se confirmó si ya fue corregido. No quedó confirmado si la asociación se habilita automáticamente al concluir las pruebas. Si necesita asociar un NIT en este periodo, consulte primero el estado con el SIN antes de planificar la emisión.

Inspección posterior a las pruebas

Al terminar las pruebas, la inspección no fue solicitada todavía. Algunos participantes consideraron suficiente concluir las pruebas por el momento. Un participante vio en el mensaje de finalización un plazo de 30 días para la inspección, pero el sistema se habilitó de inmediato. Se sospecha que ese texto fue copiado de la v2 a la v3 sin ajustarse, por lo que no conviene dar por cierto el plazo de 30 días. Otro participante esperaba una notificación de inspección dentro de ese plazo, pero consideró poco probable que ocurra porque ya se emitió el PDF de autorización. Como indica el propio mensaje, revise el correo con frecuencia, porque el SIN puede comunicar la inspección por esa vía.

Caso práctico: eventos 5, 6 y 7 que no aparecen en la v3 de pruebas

Problema planteado. En la v3 de pruebas, los eventos 5, 6 y 7 (uso de facturas manuales de contingencia, que requieren CAFC según la guía del SIAT) no aparecían en el ambiente, lo que impedía registrarlos. Al intentar registrar uno de ellos, el SIAT respondió con el error 976 (el código del evento es incorrecto).

Solución reportada. No hay una regla única. Según los participantes, el caso se resolvió solo, sin acción del usuario; en otros casos se resolvió al cerrar operaciones; y en otros fue necesario enviar un ticket al SIN. Ninguna de estas salidas está confirmada como procedimiento oficial.

Fórmula. No aplica. No existe un cálculo para este caso; el control es operativo.

Ejemplo ilustrativo. Al registrar el evento 5 se recibe el error 976. Se revisa que el código de evento sea 5 y que la configuración del sistema coincida con la modalidad y el ambiente de prueba. Si el error persiste, se anotan la fecha, la hora y el mensaje exacto, y se abre un ticket ante el SIN con esos datos.

Notas de conciliación y notas de crédito ICE

Durante la validación, un participante preguntó si se habían probado las notas de conciliación y las notas de crédito ICE en el sistema v3. Otro respondió que sí las había probado. Conviene incluirlas en la lista de pruebas antes de solicitar la autorización.

Puntos pendientes de confirmar en esta sección

• Si la asociación de NIT se habilita al concluir las pruebas v3.
• El plazo real para la inspección, dado que el mensaje de finalización puede ser un texto copiado de la v2.
• La causa por la que los eventos 5, 6 y 7 no aparecían en el ambiente de pruebas v3.
• Si el estado «AUTORIZADO» puede aparecer con el botón de finalización deshabilitado.

Recertificación v2 y actualización a v3

Experiencia compartida en el grupo; no constituye norma. Un participante relató que, al hacer seguimiento a un sistema con certificación próxima a vencer, la plataforma no habilitó la recertificación de la v2, sino únicamente la actualización a la v3. Según su relato, las pruebas habilitadas correspondían solo a la v3.

Otros hechos reportados por el grupo:

• En la Oficina Virtual, dentro del listado de certificaciones de los sistemas anteriores, aparece un botón verde con el signo +. Desde ahí se inicia la autorización de la v3, siguiendo el Anexo Técnico y sus variaciones.
• Al solicitar un sistema nuevo, el documento de la plataforma mostró las rutas de ambas versiones (v2 y v3). Otro participante reportó lo mismo en un pase a producción.
• La recomendación del grupo es no asumir que la presencia de ambas rutas implica que ambas puedan certificarse.
• Quien tenga una certificación v2 próxima a vencer debe consultar el trámite de actualización a v3 antes del vencimiento.

Puntos a confirmar con el SIN: qué versión queda habilitada para las pruebas en cada caso; si la recertificación de la v2 sigue disponible para sistemas que vencen antes de la migración; y cómo se registra la actualización a v3 en el documento de autorización. Las fuentes verificadas no contienen un procedimiento específico de recertificación v2 ni de actualización a v3. Antes de actuar, confirme con la documentación oficial vigente, incluidas la RND 102600000034 y el Anexo Técnico Ley 1733.

Puntos por confirmar

• Vigencia. El documento indica una vigencia de 1 (un) año, computable desde la fecha de emisión. En el grupo se señaló que no se identificó una resolución normativa que confirme expresamente ese plazo para la autorización de servicios SOAP v3. Un participante también comentó que la v2 tendría 3 años de vigencia; ese dato no está confirmado. Trátelo como datos pendientes de confirmar y no como norma. Consulte el listado oficial de RND y el portal de información del SIN, y anote el vencimiento que figura en el documento para renovar a tiempo.
• Verificación de la autorización. Según el participante, la autorización se verifica del lado del SIN y no requiere un trámite adicional. Es un relato no confirmado. Compruebe el estado en el portal del SIN.
• Inspecciones. El participante asumió que el trámite de inspecciones es automático. No se confirmó, y el plazo de 30 días es dudoso (ver la sección Novedades). Revise el correo y el buzón tributario tras finalizar las pruebas.
• Cambios de versión. Como la autorización identifica sistema y versión, conviene consultar con el SIN si una nueva versión requiere una nueva autorización, incluido el caso de la actualización de v2 a v3.
• Agregar sectores a una certificación emitida. Según los participantes, no existe a la fecha la opción de agregar sectores a una certificación ya emitida. Para trabajar con otro documento sector, el procedimiento vigente en el grupo fue solicitar una nueva certificación o consultar al SIN.
• Cierre de operaciones. Un participante describió que su proceso se resolvió al cerrar operaciones; otro indicó que en su caso la sincronización fue automática. Verifique el estado de sus eventos en el ambiente piloto antes de asumir que el cierre es necesario.

Buenas prácticas

1. Guarde copia del documento de autorización y del mensaje de finalización de pruebas.
2. Revise que el tipo de sistema, las modalidades y los documentos sector del documento sean los correctos.
3. Anote la fecha de vencimiento de la autorización y el plazo de las inspecciones, y programe la revisión antes de que venza.
4. Guarde el codigoRecepcion de cada envío y el número de envío para poder reintentar la validación y reportar casos pendientes.
5. Antes de finalizar las pruebas, confirme que el contador esté en 100 % y que el estado del sistema figure como «AUTORIZADO».
6. Si tiene una certificación v2 próxima a vencer, consulte la actualización a v3 con suficiente antelación.
7. Confirme en el portal del SIN que el sistema figura como autorizado para las modalidades y documentos sector indicados.
8. Incluya en las pruebas las notas de conciliación y las notas de crédito ICE.
9. Esté atento al buzón tributario y al correo electrónico, donde llega el detalle de las inspecciones.

Ante cualquier diferencia, prevalece la normativa vigente publicada por el Servicio de Impuestos Nacionales (SIN).

Documentos y capturas del caso