Qué pasa realmente entre que se cobra y que el cliente recibe su factura, qué es el archivo .p12, y cómo conectar todo esto con GoHighLevel.
Tu pregunta: “¿el SRI autoriza la factura y solo ahí se la puedo enviar al cliente?”
El SRI sí autoriza cada factura, y el documento con valor legal es el XML autorizado — no el PDF.
Ahora el matiz: Ecuador usa el esquema “offline”. Eso significa que tú generas y firmas la factura por tu cuenta, y tienes hasta 24 horas para transmitirla al SRI. Legalmente puedes entregar el comprobante al cliente antes de que llegue la autorización — el esquema se diseñó justo para que puedas seguir vendiendo aunque el SRI esté caído.
Pero en la práctica nadie hace eso, y Billing Core tampoco: la autorización tarda segundos, así que esperamos. Si enviaras antes y el SRI la rechaza, quedas con una factura entregada que no existe fiscalmente. Esperar es lo correcto.
En el esquema offline, el “número de autorización” es la misma clave de acceso de 49 dígitos. No son dos números distintos. Por eso en el sistema verás el mismo valor repetido en ambos campos — está bien.
Lo que ocurre desde que el cliente paga hasta que recibe su factura.
Se arma un XML con la estructura exacta que exige el SRI (“ficha técnica”, factura versión 1.1.0): datos del emisor, del comprador, cada línea de detalle y los impuestos. Un campo fuera de lugar = rechazo.
49 dígitos que identifican el comprobante de forma única en todo el país. La calculas tú, no la pides. Incluye un dígito verificador (módulo 11) — si está mal, el SRI rechaza de inmediato.
.p12Se aplica una firma digital XAdES-BES usando tu certificado. Esto es lo que prueba que la factura la emitiste tú y que nadie la alteró. Sin firma válida, no hay factura.
Se manda el XML firmado al servicio RecepcionComprobantesOffline. El SRI responde RECIBIDA (entró a la cola) o DEVUELTA (error de estructura o firma, ni siquiera la procesa).
Se pregunta por la clave de acceso a AutorizacionComprobantesOffline. Responde AUTORIZADO, NO AUTORIZADO o EN PROCESAMIENTO (en cuyo caso se reintenta a los pocos segundos).
El XML autorizado es el documento legal y hay que conservarlo 7 años. El RIDE es el PDF “bonito” que lee el cliente — es solo una representación impresa, no reemplaza al XML.
Se envían ambos archivos (XML + PDF), normalmente por correo. El cliente necesita el XML para su propia contabilidad; el PDF es para que lo vea un humano.
El SRI tiene dos ambientes separados: pruebas (celcer.sri.gob.ec, ambiente 1) y producción (cel.sri.gob.ec, ambiente 2). Las facturas de pruebas no tienen ningún valor fiscal — sirven justamente para equivocarte sin consecuencias. Nunca saltes este paso.
Esta es una clave real generada por Billing Core. Cada bloque significa algo.
El secuencial no puede repetirse ni saltarse dentro de un mismo establecimiento y punto de emisión. Por eso Billing Core lo reserva dentro de una transacción de base de datos: si dos ventas entran al mismo tiempo, cada una recibe su número sin colisionar.
El algoritmo de la clave de acceso, incluido el dígito verificador módulo 11, es real en Billing Core — no es simulado. Lo verificamos matemáticamente contra el estándar del SRI.
.p12, explicado desde ceroEs la pieza que más dudas genera y la única que no puedes resolver programando.
Un archivo .p12 (o .pfx) es un contenedor cifrado que guarda dos cosas: tu llave privada y tu certificado digital. Está protegido por una contraseña. Piénsalo como tu firma manuscrita, pero en archivo: quien lo tenga junto con la contraseña, puede firmar facturas a tu nombre.
En Ecuador esto se llama “firma electrónica” y la emiten entidades certificadoras acreditadas. Las más usadas son Security Data, el Banco Central del Ecuador, ANF AC, Uanataca y el Consejo de la Judicatura. Conviene revisar la lista oficial vigente antes de comprar, porque la oferta cambia.
| Formato | ¿Sirve para Billing Core? | Por qué |
|---|---|---|
Archivo .p12 | Sí | Se puede subir al servidor y firmar automáticamente. Es el que debes pedir. |
| Token USB | No | Requiere estar físicamente conectado a una máquina. Un servidor en la nube no puede usarlo. |
| Firma en la nube | Depende | Funciona solo si el proveedor expone una API de firma. Se integra distinto. |
Si te venden el token USB no vas a poder automatizar nada. La vigencia suele ser de 1 a 3 años según el proveedor y el costo es relativamente bajo (decenas de dólares), pero confirma precio y vigencia al momento de contratar.
El certificado caduca. Cuando eso ocurre, todas las firmas fallan y las facturas dejan de autorizarse — de un momento a otro. Es una de las causas más comunes de “se me cayó la facturación”. Billing Core debería avisar con anticipación; lo dejo anotado como pendiente abajo.
La contraseña del certificado se guarda cifrada con AES-256-GCM, nunca en texto plano. El certificado se sube por el panel y queda asociado solo a esa organización.
Hoy el archivo .p12 en sí se guarda codificado en base64 pero sin cifrar en la base de datos (solo la contraseña está cifrada). Base64 no es cifrado, es solo una codificación. Para producción con clientes reales hay que cifrar también el archivo, o moverlo a un gestor de secretos. Lo incluí en los pendientes de Fase 2.
Cómo interpretar lo que responde el SRI.
| Estado | Qué significa | Qué hacer |
|---|---|---|
| AUTORIZADO | Factura válida fiscalmente. | Guardar XML, generar RIDE y enviar al cliente. |
| EN PROCESAMIENTO | El SRI aún no termina. | Reintentar en unos segundos, con espera progresiva. |
| DEVUELTA | Ni siquiera entró: error de estructura o de firma. | Corregir el XML o revisar el certificado y reenviar. |
| NO AUTORIZADO | Se procesó y fue rechazada. | Leer el mensaje del SRI, corregir y emitir de nuevo. |
El SRI devuelve un identificador y un mensaje. Las causas que más se repiten:
.p12 venció o la contraseña es incorrecta.Tu idea (webhook + código de autorización) vs. una app en el Marketplace. Analizo las tres rutas.
Las tres opciones son adaptadores. Ninguna toca el Billing Core. Puedes empezar por la más simple y migrar a la más completa después sin reescribir el motor de facturación — para eso se diseñó así la arquitectura.
El cliente genera una API Key en el panel y pega la URL en una acción “Webhook” de sus automatizaciones de GHL. Es exactamente lo que ya funciona hoy.
Igual que la anterior, pero el cliente además pega en nuestro panel un Private Integration Token de su sub-cuenta de GHL. Con eso sí podemos escribir de vuelta: actualizar un campo con el estado, dejar el link del PDF en el contacto, o crear una nota.
GhlNotifier)Publicas una app; el cliente la instala con un clic y autoriza por OAuth. Te quedas con tokens por sub-cuenta y te suscribes a eventos automáticamente.
Empieza por la Opción 2 y deja el Marketplace para cuando tengas clientes pagando. El Marketplace resuelve un problema de escala (onboarding sin fricción para decenas de clientes), no un problema de producto. Hasta que no valides que la facturación funciona bien con clientes reales, ese esfuerzo no se paga.
Es una buena idea y vale la pena soportarla. Muchas herramientas solo te dejan pegar una URL, sin poder añadir cabeceras personalizadas. Así que conviene aceptar las dos formas:
# A) Con cabecera (más seguro — preferido) POST /webhooks/ghl x-api-key: bk_live_a1b2c3... # B) Con el token en la URL (para sistemas que solo aceptan una URL) POST /webhooks/ghl/wh_live_a1b2c3...
Una URL queda registrada en logs, historiales y capturas de pantalla. Para que sea seguro: que ese token solo sirva para crear facturas (no para leer datos), que sea revocable desde el panel, y que sea distinto por cliente para poder cortarlo sin afectar a nadie más.
1. GHL no tiene campo de cédula/RUC. Hay que crear campos personalizados en la sub-cuenta (cedula_ruc, tipo_identificacion, razon_social) y mapearlos en el webhook. Sin identificación válida no hay factura — como máximo “consumidor final”, que además tiene un tope de monto que conviene confirmar con tu contador.
2. Los webhooks se duplican. Si GHL reintenta un envío, hoy Billing Core emitiría dos facturas por la misma venta, y anular en el SRI es un trámite. Hay que hacer el proceso idempotente usando el identificador de la orden. Está en los pendientes.
Esto no se resuelve programando — son trámites previos.
.p12 (no token USB) de una entidad acreditada.001 y 001).Estado honesto de lo construido: el sistema funciona de punta a punta, pero el SRI está simulado.
| Pieza | Estado |
|---|---|
| Clave de acceso (49 díg. + módulo 11) | Real y verificada |
| Generación del XML (formato SRI 1.1.0) | Real |
| Cálculo de IVA y totales | Real |
| RIDE en PDF | Real (diseño básico) |
Firma XAdES-BES con el .p12 | Simulada — Fase 2 |
| Envío y autorización SOAP al SRI | Simulada — Fase 2 |
| Escritura de vuelta en GHL | Simulada — Fase 2 |
Cifrado del archivo .p12 en reposo | Pendiente |
| Idempotencia de webhooks | Pendiente |
| Aviso de certificado por vencer | Pendiente |
| Envío del XML+PDF por correo al cliente | Pendiente |
Todo lo pendiente vive detrás de una interfaz (SriPort, CrmNotifierPort). Reemplazar el SRI simulado por el real es cambiar una clase — no hay que tocar el motor de facturación ni la base de datos.