El técnico cierra la orden en la casa del cliente, cobra en efectivo y lo registra así en la app -FieldOps sí distingue efectivo de transferencia al capturar el cobro-. El problema aparece un paso después: cuando esa orden se factura, el comprobante fiscal que se timbra ante el proveedor autorizado de certificación (PAC) declara "transferencia electrónica" sin importar cómo se cobró en realidad. Verificamos en el código que el dato de forma de pago que sí se captura nunca llega a la llamada de timbrado.
La ley exige declarar cómo se pagó, no un valor fijo
El artículo 29-A, fracción VII, inciso c), del Código Fiscal de la Federación es explícito sobre qué debe contener el comprobante respecto al pago:
"Señalar la forma en que se realizó el pago, ya sea en efectivo, transferencias electrónicas de fondos, cheques nominativos o tarjetas de débito, de crédito, de servicio o las denominadas monederos electrónicos que autorice el Servicio de Administración Tributaria."
El catálogo c_FormaPago del SAT distingue explícitamente 01 = Efectivo de 03 = Transferencia electrónica de fondos: no son intercambiables ni equivalentes para efectos del comprobante.
La sanción: expedir el comprobante sin ese requisito
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 de una orden pagada en efectivo que salió declarando transferencia electrónica es, en principio, una infracción independiente.
| Elemento | Qué dice la norma |
|---|---|
| Requisito de forma de pago en el CFDI | Art. 29-A fr. VII inciso c), CFF: señalar cómo se pagó realmente (efectivo, transferencia, cheque, tarjeta, monedero) |
| Catálogo del SAT | c_FormaPago: 01 = Efectivo, 03 = Transferencia electrónica de fondos -no intercambiables |
| 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: el efectivo se guarda, pero no llega al timbrado
Confirmamos el hallazgo directamente en el código de FieldOps (repo medware-fieldops-mx, rama main). El cobro sí distingue la forma real de pago desde su propia validación de entrada, recordPaymentSchema (packages/shared-schemas/src/quoting.ts:44-54):
method: z.enum(['cash', 'transfer']),
Ese dato se guarda tal cual en la base de datos. QuotingService.recordPayment() (services/quoting/src/quoting.service.ts:1218-1234) inserta el pago con su columna method, tomada directamente de dto.method:
INSERT INTO payments (tenant_id, service_order_id, quote_id, method, amount_mxn, ...) VALUES ($1, $2, $3, $4, $5, ...)[tenantId, dto.serviceOrderId, dto.quoteId ?? null, dto.method, dto.amountMxn, ...]
El dato existe, íntegro, en la tabla payments. El problema está en el paso siguiente: cuando la orden se factura, OrderCfdiService.timbrarYSellar() (services/billing/src/order-cfdi.service.ts:201-229) arma la llamada al proveedor de timbrado con emisor, receptor, partidas, tasa de impuesto, total y folio -pero nunca lee la tabla payments ni pasa ningún dato de forma de pago. El adaptador que recibe esa llamada, FacturamaCfdiProvider.timbrar() (services/billing/src/cfdi/facturama-cfdi.provider.ts:114), resuelve la ausencia con un valor fijo en el cuerpo que envía al PAC:
PaymentForm: '03', // Transferencia electrónica
No es un valor por omisión configurable ni un campo opcional que alguien pueda corregir antes de timbrar: es un literal en el código. Ninguna interfaz de esa cadena de llamadas -ni CfdiTimbrarBase ni las que la extienden en cfdi-provider.ts- tiene siquiera un campo para forma de pago. Una orden con cotización aprobada, cobrada íntegramente en efectivo y registrada correctamente como cash en payments, puede pasar al flujo de facturación con Facturama habilitado y salir declarando transferencia electrónica.
Qué significa en la práctica, y qué falta en el producto
Un despacho que cobra en campo -efectivo, sobre todo, porque muchos clientes de servicio técnico a domicilio pagan así- termina con comprobantes fiscales que no reflejan cómo se cobró la operación. El dato correcto ya vive en el sistema, en la tabla payments: lo que falta es que timbrarYSellar() lo consulte y lo traduzca a la clave c_FormaPago correcta (01 para efectivo, 03 para transferencia) antes de llamar al PAC, en vez de que el adaptador imponga un valor fijo. Puedes ver ese recorrido completo, del cobro en efectivo a la forma de pago fija, en del cobro en efectivo a la forma de pago fija: el flujo completo en FieldOps, o estimar la exposición con tus propios números en la calculadora de exposición por forma de pago fija en el CFDI.
Preguntas frecuentes
¿FieldOps no sabe cómo se cobró la orden?
Sí lo sabe: el técnico elige "efectivo" o "transferencia" al registrar el cobro, y ese dato se guarda correctamente. El corte ocurre después, al facturar: ese dato nunca se lee ni se envía al proveedor de timbrado.
¿Aplica sólo a pagos en efectivo?
El código impone "03" (transferencia) siempre, así que el CFDI sale correcto sólo a quien pagó por transferencia -y por casualidad, no por diseño-. Cualquier otra forma de pago real (efectivo, cheque, tarjeta) queda mal declarada.
¿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 con certeza en tu operación. Si en tu despacho todos los cobros ya facturados fueron por transferencia, hoy no se manifiesta el problema -pero cualquier cobro en efectivo que se facture sí queda mal declarado.
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 (última reforma DOF 09-04-2026). 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 FieldOps decide hoy la forma de pago del CFDI, y dónde falta el candado
Te mostramos en vivo el cobro en efectivo de una orden, su timbrado, y el punto exacto donde la forma de pago real se pierde.
Agenda una demo gratis