Este es un recorrido de producto, no el caso de ningún despacho real: describe cómo se mueve -y dónde se desconecta de la norma- el timbrado de un CFDI dentro de ServiWare. La pregunta que resuelve es concreta: ¿en qué paso exacto la descripción de "qué vendiste" deja de tener oportunidad de convertirse en la clave del SAT que le corresponde? Según lo visto en ServiWare timbra cada CFDI con la misma clave SAT, sin importar qué servicio vendiste.
Esquema del recorrido · ilustración, no es una pantalla del sistema
- 1. El despacho crea una factura con descripción libre"Auditoría interna", "Consultoría de procesos", lo que sea -el formulario sólo pide texto, cantidad, unidad y precio.
- 2. El backend valida el concepto con
invoiceItemInputAceptadescription,quantity,unityunitPriceCents-ningún campo de clave de producto/servicio. - 3. El despacho solicita el timbrado
POST /facturacion/invoices/:id/stampllama aInvoicesService.stamp(). - 4. El servicio arma el cuerpo y llama al proveedor del PAC
FacturamaCfdiProvider.stamp()recorre cada concepto de la factura. - 5. Cada partida se arma con la clave fija
ProductCode: '84111506'-literal, igual para cualquierdescription. - 6. El CFDI se timbra y llega al SATVálido técnicamente, pero con la clave de "servicios de facturación" sin importar el servicio real.
1-2. La descripción se captura, pero no se traduce a una clave
El despacho puede escribir cualquier descripción del servicio -ese dato sí llega intacto hasta el CFDI, en el atributo de descripción-. Lo que no existe en el formulario ni en el esquema que lo valida es un campo para elegir la clave del catálogo del SAT que corresponde a ese servicio: el dato de "qué vendiste" (texto libre) y el dato de "qué código del SAT es eso" (catálogo cerrado) nunca se conectan.
3-6. El proveedor de timbrado impone su propia clave, siempre la misma
Cuando llega el momento de timbrar, el proveedor que arma el cuerpo del CFDI no lee ninguna clave calculada -porque no existe- ni deriva una de la descripción: asigna el mismo literal a cada concepto, de cada factura, de cualquier despacho que use ServiWare. El resultado es un comprobante técnicamente válido (el SAT sí lo acepta, porque la clave existe en su catálogo) pero que describe la operación real de forma incorrecta.
| Parada | ¿La clave refleja el servicio real vendido? |
|---|---|
| 1. Descripción libre capturada | No aplica -aún no hay clave en juego |
| 2. Validación del concepto | No -el esquema no tiene ese campo |
| 3. Solicitud de timbrado | No -no se calcula ninguna clave antes de este paso |
| 4. Armado del cuerpo del CFDI | No -el proveedor no recibe clave, sólo descripción |
5. Asignación de ProductCode | No -literal fijo, igual para todos los conceptos |
| 6. Timbrado ante el SAT | No -se acepta porque la clave es válida, aunque no corresponda |
Puedes estimar la exposición de este hallazgo, con tus propios números, en la calculadora de exposición por clave SAT fija.
Preguntas frecuentes
¿Por qué el SAT acepta un CFDI con la clave equivocada?
Porque el SAT valida que la clave exista en su catálogo y que la estructura del comprobante sea correcta -no valida, al momento de timbrar, si esa clave corresponde de verdad al servicio descrito. La discrepancia se detecta después, por análisis de la autoridad.
¿Pasa lo mismo con cualquier tipo de servicio?
Sí: el literal está en el proveedor de timbrado, no depende de la descripción, el monto ni el tipo de cliente. Aplica igual a una auditoría, una consultoría o una capacitación.
¿ServiWare corrige esto automáticamente?
No, hoy no. Es un hallazgo verificado en el código actual, no una función ya resuelta.
Ve el recorrido completo en tu propia demo
Te mostramos en vivo una factura de cualquier servicio y la clave con la que se timbra.
Agenda una demo gratis