Módulo embebible

Factura desde tu producto, y que cada comprobante llegue al SAT una sola vez.

Una etiqueta HTML y tu aplicación emite CFDI 4.0: timbrado ante el PAC, cancelación con motivo y complementos de pago, con las reglas del SAT comprobadas antes de gastar un timbre. Con tus colores y en tu dominio.

Despacho Arrieta · MXN

Producción

Despacho Arrieta SC

ARR980214J21

CFDI 4.0 · Ingreso

A-00142

Receptor

Constructora Herrera SA de CV

CHE910312QX7 · Uso G03 · Régimen 601

Subtotal
$45,000.00
IVA 16 %
$7,200.00
Total
$52,200.00
Timbrado3F2A9C41-7B0E-4D52-9A18-C6E4B0D71F83

Facturado en septiembre

$70,760.00

  • Grupo Molino SA de CV

    $18,560.00

    A-00141 · GMO050822KL3

    En proceso
  • Público en general

    $1,276.00

    A-00139 · XAXX010101000

    Cancelado · 02
  • Estudio Vega SC

    $9,860.00

    Sin folio · EVE180604RT1

    Borrador
Timbres
4,200
PAC
Conectado
Lo que un sistema de facturación cualquiera no hace

Todos llenan el XML. La diferencia está en lo que pasa cuando algo sale mal a medio camino.

Un renglón mal tecleado en Cotizaciones se arregla tecleando otra vez. Un comprobante timbrado con el RFC equivocado se cancela —con motivo, con acuse y a veces con la aceptación del receptor— y se emite uno nuevo que lo sustituye. Estas tres reglas están ahí para que ese camino se recorra lo menos posible, y para que cuando se recorra quede escrito quién lo hizo.

Quien redacta no timbra, y quien timbra no cancela

Timbrar cuesta dinero, es irreversible y deja un documento en un servidor del SAT que ya no se borra. Separar a quien teclea de quien emite convierte un error irreversible en un borrador que alguien revisa. Y quien emite no cancela: eso es de quien responde por lo fiscal. Lo impone la base, por fila, no un botón escondido.

Un doble clic no emite dos comprobantes

El folio se reserva con la fila bloqueada, la llave de idempotencia la genera la base antes de la llamada al PAC, y si el proceso se muere a medio camino un trabajo diario le pregunta al PAC qué pasó de verdad en vez de suponerlo. Devolver a borrador sin preguntar es exactamente cómo se emite el segundo.

«Cancelado» sólo cuando lo está

El SAT exige motivo desde 2022, y cuando el importe pasa del límite el receptor tiene 72 horas para aceptar. Hasta entonces la pantalla dice «en proceso» y el comprobante sigue contando como facturado. Decir «cancelado» antes sería mentir sobre el estado fiscal de un documento, que es lo único que este módulo existe para no hacer.

Cómo funciona

Del receptor al complemento de pago, con una firma distinta en cada paso

01

Da de alta al receptor con su constancia

Razón social como está en la constancia de situación fiscal, RFC, régimen y código postal. Un RFC mal capturado se propaga a todos sus comprobantes, así que el alta es de quien responde por lo fiscal, no de la mesa de captura.

02

Redacta el borrador

Conceptos del catálogo con su ClaveProdServ y ClaveUnidad, IVA por línea, método y forma de pago. El borrador no existe para el SAT: se corrige cuantas veces haga falta y no quema folio.

03

Otra persona timbra

Las reglas cruzadas del SAT se comprueban todas a la vez antes de mandar. El folio se asigna en ese instante, el PAC devuelve el UUID, y el XML y el PDF quedan guardados tal como se entregaron.

04

Cobra, complementa o cancela

Cada pago de una factura PPD genera su complemento con número de parcialidad y saldos. Y si hay que cancelar, va con motivo, con el UUID que sustituye y con el plazo del receptor a la vista.

Qué trae

Lo que ya viene resuelto

Los rechazos del SAT, en español

CFDI40147 quiere decir que el régimen del receptor no cuadra con su RFC. Las reglas cruzadas —que PPD exige forma de pago 99, que el RFC genérico exige uso S01 y régimen 616— se comprueban antes de mandar, todas a la vez, no una para descubrir la siguiente.

Complementos de pago (REP)

Un pago puede saldar varias facturas PPD y una factura puede cobrarse en parcialidades. Cada reparto lleva su número de parcialidad y los saldos antes y después, y el complemento se timbra como lo que es: un comprobante de tipo P con su propio UUID.

Borradores desde la tienda y la caja

Una venta pagada en la tienda en línea o cerrada en el punto de venta llega aquí como borrador, con su importe y el RFC si el cliente lo dio. Borrador, no timbre: emitir automáticamente por cada error de captura de un cajero cuesta más que la venta.

El XML es el comprobante; el PDF, su imagen

Se guardan los dos al timbrar y no se regeneran nunca: un PDF regenerado con una plantilla nueva ya no es el documento que se entregó. Las descargas van por enlace firmado de vida corta, y reenviarlos al receptor lo puede hacer quien lo atiende.

Tu certificado no vive aquí

El certificado de sello digital lo custodia el PAC; nosotros guardamos un identificador, no un secreto de firma. Darlo de alta es sólo del dueño del espacio y no se hereda por rol: un administrador invitado no puede firmar a nombre del contribuyente.

Cinco papeles, permisos en la base

Dueño, administrador, operador, capturista y sólo lectura. Captura, emisión y cancelación son tres conjuntos disjuntos, y lo facturado del mes no lo ve la mesa de captura. Lo que cada uno no puede hacer lo impide la base de datos, no un botón deshabilitado.

Integrarlo

Esto es todo el código que escribes

El token lo emite tu backend con tu llave secreta y dura quince minutos. Cuando caduca, el módulo avisa con un evento; tu página pide otro y el comprobante a medio redactar sigue donde estaba. La llave del PAC nunca sale del servidor.

<script src="https://nexusnorth.dev/embed/v1/nexus-cfdi.js" defer></script>

<nexus-cfdi
  tenant-id="tu-tenant"
  auth-token="token-efimero-de-tu-backend"
  workspace-id="el-emisor"
  series="A"
  currency="MXN"
  ready-to-stamp
  live-mode
  style="--nexus-primary: #0e5c43; --nexus-radius: 0.75rem"
></nexus-cfdi>

<script>
  document.querySelector("nexus-cfdi")
    .addEventListener("token-expired", renovarToken);
</script>
  • live-mode y ready-to-stamp los declara tu página: sin ellos se asume ambiente de pruebas y el botón de timbrar apagado, que son las dos respuestas seguras.
  • La llave del PAC nunca viaja al navegador: el módulo llama a nuestro servidor y es él quien habla con el PAC.
  • Cambiar el token no remonta la app: el comprobante a medio redactar sigue donde estaba.
  • Cancelar, dar de alta el certificado y repartir papeles se hacen en /facturacion, con sesión con nombre y apellido; el widget no los expone.
  • Aislado en Shadow DOM, con tus colores y tus radios desde variables CSS. Un solo archivo, sin dependencias que choquen con las tuyas.
Preguntas

Lo que suelen preguntar antes de integrarlo

Ya tengo la tienda, el punto de venta o Cotizaciones. ¿No facturan?

No, y es a propósito. Cotizaciones responde «¿cuánto te costaría?»; la tienda y la caja, «¿me lo cobras?». Éste responde «¿me lo facturas?», y el que manda es el SAT: el documento no se corrige, se cancela y se emite otro. Los tres primeros le mandan sus ventas como borradores, y alguien con permiso de emisión decide qué se timbra. Se pueden llevar todos a la vez.

¿Guardan mi certificado de sello digital?

No. El CSD con su llave y su contraseña lo custodia el PAC; nosotros guardamos su identificador, que no sirve para firmar. Tener la llave de sellado de un contribuyente en nuestra base convertiría una filtración en la capacidad de emitir facturas a su nombre, y eso no es un riesgo que aceptemos por ahorrarnos una llamada.

¿Qué pasa si se corta la conexión mientras timbro?

El comprobante se queda en «timbrando» y no vuelve solo a borrador. La llave de idempotencia ya está guardada en la base, así que el reintento manda la misma y el PAC devuelve el comprobante que ya existía en vez de crear otro. Si nadie reintenta, un trabajo diario recoge los que llevan más de quince minutos así y le pregunta al PAC qué pasó de verdad.

¿Puedo corregir una factura ya timbrada?

No existe el permiso que lo permitiría: la tabla de comprobantes no tiene actualización para nadie, ni siquiera para el dueño. Lo que se hace es cancelarla con motivo 01 —«emitida con errores con relación»—, indicar el UUID de la que la sustituye y emitir la nueva. Queda registrado quién pidió la cancelación y cuándo quedó firme.

¿Por qué el folio saltó de 140 a 142?

Porque el 141 se reservó al intentar timbrar y el PAC rechazó o la llamada no contestó. El folio se toma en el instante de emitir, en la misma transacción que bloquea la fila, y un intento fallido lo quema a propósito: reusarlo exigiría saber que el PAC no llegó a crear nada, y eso es justo lo que no se sabe cuando una llamada no contesta. Un borrador que nunca se timbra no gasta folio.

¿Lleva la contabilidad?

No. No hay pólizas, cuentas ni balanza; eso es otro producto y se vende por separado. Lo que sí hay es el reporte de lo facturado por mes, por cliente y por estado, que un contador puede leer de una sola tabla, y el XML de cada comprobante tal como se entregó.

¿Comercio exterior, carta porte, nómina, factura global?

Todavía no. Lo que hay es el comprobante de ingreso y egreso con el complemento de pago, que es lo que necesita la gran mayoría de los negocios. Los otros complementos tienen esquemas propios y cada uno es una entrega aparte. La factura global —el CFDI diario de operaciones con público en general— es la pieza más cercana: falta la ventana de agregación, no el comprobante.

¿Dónde viven los datos?

En nuestra instancia por omisión, con aislamiento por cliente impuesto en la base de datos. El XML y el PDF van a un bucket privado y se sirven por enlace firmado de vida corta. Si lo prefieres, pueden vivir en la tuya: el módulo apunta a donde le digas.

¿Tu producto necesita facturar?

Cuéntanos qué estás construyendo y te decimos si este módulo encaja — o si lo tuyo necesita otra cosa.

Hablemos