Facturación y CFDI en México

---
name: facturacion-cfdi-mexico
description: emitir, timbrar y cancelar comprobantes sin fingir que un PDF es una factura.
---

# Facturación y CFDI en México

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
emitas CFDI, recibas datos fiscales o conectes un flujo de cobro con un PAC.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Una empresa mexicana debe entregar CFDI por una venta o servicio.
- El cliente captura RFC, razón social, régimen fiscal, código postal y uso de CFDI.
- Hay pagos diferidos que requieren complemento de recepción de pagos.
- La app administra cancelaciones, notas de crédito o descarga de XML fiscal.

Si solo muestras una cotización o recibo interno, no lo llames factura fiscal. Genera un
PDF claramente marcado y mantén el timbrado fuera del alcance.

## Cómo armarla

Usa la versión vigente de **CFDI publicada por el SAT** y timbra mediante un **PAC
autorizado** con API y ambiente de pruebas. No implementes un PAC ni el protocolo del SAT.

1. Pide a contabilidad una matriz de casos antes de escribir código: ingreso, egreso,
   pago, moneda, impuestos, pago en parcialidades y complementos que sí aplican.
2. Encapsula al PAC detrás de una interfaz propia: `crear`, `timbrar`, `consultar`,
   `cancelar` y `descargarAcuse`. Así puedes cambiar proveedor sin reescribir ventas.
3. Valida los datos fiscales contra catálogos vigentes antes del timbrado. Conserva los
   códigos del SAT, no solo sus etiquetas visibles.
4. Calcula importes en decimales, con reglas explícitas de redondeo. Guarda subtotal,
   descuentos, impuestos trasladados y retenidos por concepto y en totales.
5. Envía una llave de idempotencia propia al PAC o registra una por operación. Si vence
   la petición, consulta antes de reintentar para no timbrar dos CFDI.
6. Guarda XML timbrado, UUID, sellos, cadena original, fecha, estado, respuesta del PAC y
   acuses. El XML es el comprobante; el PDF es solo su representación impresa.
7. Modela cancelación como un proceso con estado y acuse, no como borrar una fila. Liga
   sustituciones y notas de crédito al comprobante original.
8. Emite complementos, como recepción de pagos o Carta Porte, solo cuando el caso fiscal
   lo requiera y con revisión de una persona especialista.

## En qué te vas a trabar

- **Los catálogos y reglas cambian.** Versiona la integración y programa una revisión
  fiscal; que el endpoint siga respondiendo no significa que el comprobante sea correcto.
- **Cada PAC tiene errores y sandbox distintos.** Conserva request, response y un id de
  correlación sin registrar certificados, llaves privadas ni datos innecesarios.
- **Cobro y timbrado no son el mismo evento.** Un pago aprobado puede requerir otra fecha,
  moneda, forma o método de pago; no los unas con un `if` improvisado.
- **El costo incluye timbres, soporte y operación.** Cotiza con el PAC elegido según el
  volumen real y anota la tarifa y fecha vigentes en la configuración interna.

## Qué NO hacer

- No fabriques XML a partir de una plantilla copiada de internet ni selles documentos a
  mano si el SDK o API del PAC ya resuelve el estándar vigente.
- No guardes la e.firma, el CSD o sus contraseñas en texto claro ni en el repo.
- No prometas que un CFDI es deducible; eso depende del caso fiscal del receptor.
- No borres comprobantes timbrados ni sobrescribas su XML para corregirlos.

## Checklist

- [ ] La matriz fiscal fue revisada por contabilidad para los casos que sí soportas.
- [ ] El PAC aparece como autorizado y las credenciales de prueba y producción están separadas.
- [ ] Catálogos, decimales e impuestos se validan antes de enviar.
- [ ] Un timeout y un reintento no producen dos UUID para la misma operación.
- [ ] XML, PDF, UUID, estado y acuses se pueden descargar por separado.
- [ ] Cancelación, sustitución y complemento de pagos tienen pruebas de punta a punta.
- [ ] Certificados y llaves están cifrados, rotables y fuera de logs.