Ya documentamos que En el diseño de ServiWare, el CFDI sale en PUE por omisión 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:407-412) 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:77-100) 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 "En el diseño de ServiWare, el CFDI sale en PUE por omisión"?
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