Facturación en contingencia en Bolivia: cómo funciona

Facturar en Bolivia depende, en última instancia, de que el sistema del SIN esté disponible para validar tus documentos. Pero ¿qué pasa si el servicio de Impuestos Nacionales se cae, o si tu propio negocio se queda sin internet, justo cuando tienes clientes esperando su factura? Para eso existe el mecanismo de contingencia, y la API de facturación lo implementa a través de los llamados eventos significativos.

Qué es un evento significativo

Un evento significativo es el aviso oficial que le mandas al SIN para dejar constancia de que algo pasó: que su servicio no respondió, que perdiste conexión a internet, o cualquier otra situación que te obligue a facturar sin conexión directa. Es el mecanismo formal, no un simple registro interno tuyo.

POST /events

{
  "event_type": "contingencia_inicio",
  "pos_uid": "018f3a2b-7c4d-7e1a-9b2c-3d4e5f6a7b8c",
  "description": "Se cayó la conexión a internet de la sucursal"
}

Fíjate que el event_type se indica por su nombre corto (por ejemplo contingencia_inicio), no por un código numérico: el sistema se encarga de traducirlo al código oficial que pide Impuestos, y te devuelve ambos en la respuesta.

Si en el momento de registrar el evento el SIN tampoco responde, no hay problema: el evento queda guardado como pending_sync y se reintenta más tarde de forma automática.

Cómo saber si el SIN está disponible

Antes de asumir que necesitas entrar en contingencia, puedes comprobar el estado del servicio directamente:

GET /events/connection

{
  "status": "down",
  "response_time_ms": 4200,
  "checked_at": "2026-09-11T14:32:00Z"
}

Un detalle importante: que el SIN esté caído no se considera un error para la API. La petición responde 200 igual, y el estado (up o down) viene dentro de los datos. Con esa información decides si sigues facturando normal o abres una ventana de contingencia.

Abrir una ventana de contingencia

Cuando confirmas que necesitas facturar sin conexión, el paso correcto es abrir una ventana de contingencia:

POST /events/start

{
  "event_type": "contingencia_inicio",
  "pos_uid": "018f3a2b-7c4d-7e1a-9b2c-3d4e5f6a7b8c"
}

Esto hace algo específico: congela el CUFD vigente de ese punto de venta y lo usa como respaldo para todas las facturas que emitas mientras la ventana esté abierta. Así, aunque no haya conexión con el SIN en ese momento, cada factura queda igualmente amparada por una credencial válida.

Mientras la ventana está abierta, sigues emitiendo facturas de forma normal con POST /invoices, salvo que ahora dos campos entran en juego:

• cafc: un código especial que marca que esa factura se está emitiendo sin conexión con Impuestos, exclusivo del modo contingencia.
• emission_date: la fecha y hora real de la venta, útil porque en modo offline el sistema no puede tomarla del reloj del servidor del SIN como en el flujo normal.

Cada factura emitida en este estado queda con emission_type: "offline" en su registro, lo que te permite diferenciarlas después de las que se emitieron en línea.

Cerrar la ventana y despachar lo acumulado

Cuando el SIN vuelve a estar disponible, o recuperas la conexión, el siguiente paso es cerrar la ventana:

POST /events/end

{
  "event_uid": "...",
  "end_at": "2026-09-11T18:00:00Z"
}

Cerrar la ventana no es solo un trámite administrativo: dispara automáticamente el envío de todas las facturas acumuladas durante esa contingencia hacia el SIN, para que queden validadas como corresponde. No necesitas reenviarlas una por una.

Verificar que todo cuadra

Después de una contingencia, es razonable querer confirmar que lo que tu sistema registró coincide con lo que el SIN efectivamente recibió. Para eso existe:

GET /events/{event_uid}/consult

Este endpoint compara tu registro local del evento contra lo que consta en Impuestos, lado a lado, lo cual ayuda a detectar casos donde tu sistema cree que hubo una contingencia que el SIN nunca llegó a registrar, o al revés.

También puedes revisar el historial completo de contingencias pasadas:

GET /events?pos_uid={pos_uid}&from=2026-01-01T00:00:00Z

Qué tipos de evento existen

El campo event_type no acepta cualquier texto: sale de un catálogo cerrado de eventos que define el SIN, con nombres cortos como contingencia_inicio. Puedes consultar los tipos disponibles junto con el resto de catálogos oficiales:

GET /catalogs?catalog_type=significant_events

Esto es importante porque un event_type que no existe en ese catálogo simplemente no es aceptado por la API: el sistema no adivina ni corrige automáticamente un nombre mal escrito.

Contingencia y emisión masiva: no es lo mismo

Vale la pena aclarar una confusión frecuente: hay otro flujo, el de paquetes de contingencia offline, pensado para negocios en modalidad masiva que acumulan facturas fuera de línea y las agrupan para enviar después. Ese flujo es distinto del de cajas, que sirve para juntar facturas online en el momento. Si tu necesidad es puntual, por una caída de conexión, el camino correcto sigue siendo abrir y cerrar una ventana de contingencia con /events/start y /events/end.

En resumen

La contingencia no es una falla del sistema: es un mecanismo previsto y aceptado por el SIN para que tu negocio nunca deje de facturar por un problema de conexión. El flujo se resume en cuatro pasos: comprobar si el SIN está disponible, abrir la ventana si hace falta, seguir emitiendo con el CUFD congelado, y cerrar la ventana apenas se restablece la conexión para que todo lo acumulado se despache automáticamente.

Si quieres revisar el resto de la API de facturación, puedes verla en nuestra página de facturación electrónica, o consultar el detalle de precios en los planes disponibles.