Ya documentamos que ServiWare siempre factura PUE y nunca genera el complemento de pago cuando el cobro es a crédito. Este hallazgo es distinto: no es sobre el método de pago del CFDI, es sobre a nombre de quién sale la factura. Verificamos en el código que si el cliente del despacho tiene un RFC real capturado pero le falta el código postal o el régimen fiscal -dos campos opcionales en el alta del cliente-, el sistema no detiene el timbrado ni pide completar el dato: sustituye el RFC del cliente por la clave genérica de "público en general" y arma una factura global, sin ninguna advertencia visible.
La clave genérica no es para "faltan otros datos": es para "no hay RFC"
El artículo 29-A, fracción IV, del Código Fiscal de la Federación exige que el comprobante fiscal contenga el RFC, el nombre o razón social, el código postal del domicilio fiscal y la clave de uso fiscal del receptor. El mismo artículo señala cuándo se permite usar la clave genérica en su lugar:
"La clave del Registro Federal de Contribuyentes, nombre o razón social; así como el código postal del domicilio fiscal de la persona a favor de quien se expida [...] Cuando no se cuente con la clave del Registro Federal de Contribuyentes a que se refiere esta fracción, se señalará la clave genérica que establezca el Servicio de Administración Tributaria mediante reglas de carácter general [...] considerando dicha operación como celebrada con el público en general."
La condición es "no se cuente con el RFC" -no "falta el código postal" ni "falta el régimen fiscal" cuando el RFC sí existe-. Son dos motivos distintos, y la ley sólo autoriza la clave genérica para el primero.
La sanción: expedir un comprobante sin los requisitos del art. 29-A
El catálogo de infracciones del CFF nombra este caso de forma expresa. El artículo 83, fracción VII, sanciona:
"No expedir, no entregar o no poner a disposición de los clientes los comprobantes fiscales digitales por Internet de sus actividades cuando las disposiciones fiscales lo establezcan, o expedirlos sin que cumplan los requisitos señalados en este Código, en su Reglamento o en las reglas de carácter general que al efecto emita el Servicio de Administración Tributaria [...]"
El artículo 84, fracción IV, inciso a), fija la multa correspondiente, actualizada para 2026 (Anexo 5 de la Resolución Miscelánea Fiscal, DOF 28 de diciembre de 2025):
"De $22,300.00 a $127,530.00. En caso de reincidencia, las autoridades fiscales podrán, adicionalmente, clausurar preventivamente el establecimiento del contribuyente [...]"
Es una multa por comprobante, no un cobro único: cada CFDI que salió a "público en general" en lugar de al RFC real del cliente es, en principio, una infracción independiente.
| Elemento | Qué dice la norma |
|---|---|
| Datos que exige el receptor del CFDI | Art. 29-A fr. IV, CFF: RFC, nombre, código postal del domicilio fiscal, uso del CFDI |
| Cuándo se permite la clave genérica (público en general) | Art. 29-A fr. IV, CFF: sólo cuando no se cuenta con el RFC del receptor |
| Infracción por expedir sin cumplir los requisitos del 29-A | Art. 83 fr. VII, CFF |
| Multa | Art. 84 fr. IV inciso a), CFF: $22,300.00 a $127,530.00 MXN por comprobante (2026) |
| Reincidencia | Clausura preventiva del establecimiento, 3 a 15 días |
Verificado en el código: falta el CP o el régimen, y el RFC real desaparece
Confirmamos el hallazgo directamente en el código de ServiWare (repo medware-servicios, rama main). La función InvoicesService.stamp() (apps/services/facturacion/src/facturacion/invoices.service.ts:344-349) decide el receptor del CFDI así:
const perfilFiscalCompleto = !!cl.rfc && cl.rfc !== 'XAXX010101000' && !!cl.fiscal_regime && !!cl.postal_code;
const receiverRfc = perfilFiscalCompleto ? cl.rfc : 'XAXX010101000';
El propio comentario del código lo dice sin rodeos: "Si falta CUALQUIER dato, CAE a público en general (XAXX010101000) [...] Nunca se bloquea el timbrado por perfil incompleto." Es una decisión explícita, no un descuido -y aun así, el efecto es el mismo: un cliente con RFC real capturado, al que sólo le falta el código postal o el régimen fiscal en su ficha del CRM, recibe una factura a "público en general" en vez de una factura a su nombre.
El adapter que llama al proveedor autorizado de certificación (PAC) confirma que no es un simple cambio de campo: FacturamaCfdiProvider.stamp() (apps/services/facturacion/src/pac/facturama-cfdi-provider.ts:59-81) arma, para ese receptor, el uso de CFDI S01 ("sin efectos fiscales"), el régimen 616, el domicilio fiscal del propio emisor en vez del cliente, y el nodo GlobalInformation que identifica una factura global real ante el SAT. El código postal y el régimen fiscal del cliente son opcionales desde el propio esquema de alta (packages/shared/src/crm.ts:24-25, fiscalRegime y postalCode con .optional()), y el formulario de alta de clientes no marca ninguno de los dos como obligatorio ni advierte de esta consecuencia.
Qué significa en la práctica, y qué falta en el producto
Un cliente con RFC real, dado de alta sin capturar su código postal fiscal -algo tan simple como que quien lo registró no tenía ese dato a la mano-, recibe una factura que no lleva su RFC. No puede usarla para deducir ni acreditar el IVA de esa operación, y el despacho que la emitió queda con un CFDI de "factura global" que en realidad corresponde a una venta perfectamente identificable. Lo que falta no es el dato: fiscal_regime y postal_code ya existen en la ficha del cliente. Lo que falta es que stamp() detenga el timbrado nominativo -y pida completar el dato, o exija una elección explícita de facturar a público en general- en vez de decidirlo en silencio por el cliente. Puedes ver ese recorrido completo, del dato faltante a la factura global, en del dato faltante a la factura global: el flujo completo en ServiWare, o estimar la exposición con tus propios números en la calculadora de exposición por CFDI a público en general sin motivo legal.
Preguntas frecuentes
¿Esto es lo mismo que "ServiWare siempre factura PUE"?
No. Aquella pieza trata del método de pago del comprobante (PUE vs. PPD/complemento de pago). Ésta trata de a nombre de quién sale el comprobante: con RFC real del cliente, o con la clave genérica de público en general.
¿El código postal o el régimen fiscal son obligatorios en algún punto del proceso?
No en ServiWare hoy: son campos opcionales desde el alta del cliente, y ningún paso posterior -incluido el timbrado- exige completarlos antes de facturar de forma nominativa.
¿Cuál es la multa exacta?
El CFF no fija un monto único: de $22,300.00 a $127,530.00 MXN por cada comprobante expedido sin cumplir los requisitos del art. 29-A (cifras 2026, actualizadas anualmente por el SAT), y clausura preventiva del establecimiento en caso de reincidencia.
¿Significa que mi despacho ya tiene facturas mal emitidas?
No necesariamente: el hallazgo es que el sistema lo permite y no lo detecta, no que ya haya ocurrido. Si en tu despacho todos los clientes con RFC tienen también su código postal y régimen fiscal capturados, hoy no se manifiesta el problema -pero tampoco hay ninguna alerta si algún cliente nuevo se da de alta sin ese dato.
Fuentes consultadas: Código Fiscal de la Federación, texto vigente publicado por la Cámara de Diputados del H. Congreso de la Unión, artículos 29-A, 83 y 84. Anexo 5 de la Resolución Miscelánea Fiscal 2026 (DOF 28 de diciembre de 2025), montos de multas actualizados. Este artículo es orientativo y no sustituye una revisión de tu caso por tu contador o asesor fiscal.
Ve cómo ServiWare decide hoy el receptor del CFDI, y dónde falta el candado
Te mostramos en vivo el alta de un cliente sin código postal fiscal, el timbrado de su factura, y el punto exacto donde el RFC real se sustituye sin avisar.
Agenda una demo gratis