Integrar CFDI con un ERP no consiste en copiar campos hacia un servicio de timbrado. La integración debe conservar una sola historia para el pedido, la entrega, la factura, el pago y cualquier corrección posterior. Cuando cada sistema asigna referencias distintas o interpreta por su cuenta el estado de la operación, la recaptura reaparece como aclaraciones, reintentos y conciliaciones. El objetivo es definir un contrato de datos y controles que permita automatizar sin perder trazabilidad.
El problema operativo no termina al conectar la API
Una conexión técnica puede responder correctamente y aun así dejar una operación incompleta. El ERP quizá marque la venta como facturada antes de recibir el UUID; el sistema fiscal puede timbrar dos veces si un reintento no reconoce la solicitud original; cobranza puede aplicar un depósito a una referencia que no regresó al sistema de origen. Estas fallas nacen cuando la empresa integra mensajes, pero no acuerda estados y responsabilidades.
La fuente de verdad también debe quedar explícita. Si el ERP gobierna clientes, productos, pedidos e inventarios, otra plataforma no debería modificar esos catálogos sin una ruta aprobada. A su vez, el resultado fiscal —UUID, XML, PDF, estado de timbrado y eventos posteriores— debe regresar al ERP con un identificador estable. La integración CFDI con ERP funciona mejor cuando cada dato tiene dueño y cada cambio deja evidencia.
El diseño debe incluir excepciones desde el inicio. Un receptor incompleto, una clave de producto pendiente, una indisponibilidad temporal o un documento que requiere revisión no son casos raros que deban resolverse fuera del flujo. Son estados previstos que necesitan responsable, mensaje comprensible y una acción segura.
Datos y documentos que deben prepararse
Antes de desarrollar, conviene levantar un ejemplo real de principio a fin y reunir los elementos que intervienen. El equipo debe identificar el documento comercial de origen, los catálogos que alimentan la factura, las reglas de autorización y la evidencia que debe regresar después de emitir. Este inventario evita diseñar la integración a partir de una lista genérica de campos.
- Identificador único e inmutable de la operación, pedido o transacción.
- Datos fiscales del emisor y receptor, con responsable para altas y cambios.
- Conceptos, cantidades, unidades, precios, descuentos, impuestos y moneda.
- Condiciones comerciales, forma y método de pago, vencimiento y referencias.
- Eventos de surtido, entrega o prestación que autorizan facturar.
- Resultados que regresarán: folio, UUID, XML, PDF, mensajes y estado.
- Reglas para cancelación, sustitución, notas de crédito, pagos y REP cuando apliquen.
También se necesita un catálogo de errores que distinga validaciones de negocio, rechazos de datos y fallas técnicas recuperables. El usuario no debería recibir el mismo mensaje para un RFC incompleto que para una espera de comunicación. Esa clasificación determina si se corrige información, se solicita autorización o se reintenta sin duplicar el documento.
Flujo paso a paso para integrar CFDI y ERP
1. Seleccionar un proceso y fijar su frontera
Empiece con un tipo de operación representativo: una venta de contado, un pedido a crédito o un servicio recurrente. Dibuje desde la captura hasta el cobro y marque qué sistema crea cada dato. Incluir todos los escenarios en la primera entrega dificulta comprobar dónde nació una diferencia.
2. Definir el contrato y la fuente de verdad
Documente campos obligatorios, formatos, catálogos, identificadores y reglas de versión. Para cada elemento, indique quién puede modificarlo y cómo se propaga el cambio. El contrato debe precisar qué acepta el servicio fiscal y qué necesita el ERP para reconocer el resultado sin buscarlo por importe o fecha.
3. Modelar estados antes de automatizar
Una solicitud puede estar preparada, validada, enviada, timbrada, rechazada, pendiente de conciliación o cancelada. Los nombres concretos pueden variar, pero el negocio debe saber qué acciones están permitidas en cada estado. Por ejemplo, una operación enviada no debe editarse como si todavía fuera borrador, y una respuesta incierta no debe generar inmediatamente un segundo CFDI.
4. Hacer idempotentes solicitudes y reintentos
Cada intento debe conservar la referencia original. Si se corta la comunicación después de timbrar, el siguiente paso es consultar o reconciliar, no emitir a ciegas. La idempotencia evita que el mismo evento comercial produzca comprobantes duplicados y permite que soporte investigue con una clave común.
5. Regresar resultados y evidencia al ERP
El UUID, el XML, la representación PDF, los mensajes y el estado deben vincularse con el pedido correcto. El ERP necesita mostrar que la emisión concluyó y conservar rutas de consulta para usuarios autorizados. Si el resultado sólo queda en el sistema fiscal, ventas y cobranza volverán a solicitar archivos por correo.
6. Conciliar excepciones y liberar por etapas
Antes de ampliar el volumen, compare pedidos, solicitudes, CFDI emitidos, rechazos y saldos. Revise manualmente una muestra de casos normales y excepcionales. La guía sobre gobierno de una integración ERP fiscal ayuda a colocar responsables y controles alrededor de la conexión, sin confundir disponibilidad técnica con cierre operativo.
Caso práctico común: un pedido con entrega parcial
Una comercializadora recibe un pedido que se surtirá desde dos almacenes. El ERP reserva existencias y libera una primera entrega. En lugar de recapturar al cliente y los conceptos, genera una solicitud con el identificador del pedido, las partidas entregadas y la condición de pago autorizada. La plataforma fiscal valida la información y devuelve el resultado asociado a esa misma referencia.
La segunda entrega no reutiliza la solicitud anterior: conserva el pedido como relación, pero lleva su propio identificador de evento. Si la primera respuesta queda incierta por una interrupción, el sistema consulta antes de reintentar. Cobranza recibe los folios y vencimientos correctos, mientras inventarios mantiene la diferencia entre solicitado, surtido y pendiente.
Al llegar un pago, administración lo aplica contra los documentos identificados y revisa si corresponde emitir el comprobante relacionado. Contabilidad obtiene el XML y las referencias operativas sin reconstruir la cadena. El beneficio no depende de eliminar toda intervención humana, sino de reservarla para diferencias y decisiones que sí requieren criterio.
Errores comunes y sus consecuencias
Integrar usando únicamente el folio visible es riesgoso porque puede repetirse entre series o empresas. Buscar coincidencias por importe y fecha tampoco ofrece una relación confiable. Sin un identificador estable, una corrección termina ligada al pedido equivocado y la investigación cruza registros que no pertenecen al mismo expediente.
Otro error es considerar cualquier respuesta HTTP como cierre. Una confirmación de recepción no equivale necesariamente a un CFDI timbrado, y un tiempo de espera no demuestra que la operación falló. Tratar ambos casos igual puede duplicar comprobantes o dejar ventas marcadas como facturadas sin UUID disponible.
También falla el proyecto cuando los catálogos se limpian sólo durante las pruebas. Si producción conserva clientes duplicados, unidades inconsistentes o impuestos definidos de forma distinta, la integración automatiza la divergencia. Los cambios sensibles necesitan gobierno, validación y una ruta de corrección.
Cómo ayuda SOATI E-Factura® Plataforma Fiscal
SOATI E-Factura® Plataforma Fiscal ofrece una API de timbrado para conectar sistemas propios y puede relacionar la emisión con capacidades de consulta, XML/PDF y operación fiscal. Para empresas que también usan los módulos disponibles de ventas, inventarios, cobranza o contabilidad, el flujo puede mantener referencias comunes entre áreas sin convertir el CFDI en un archivo aislado.
El alcance debe acordarse según el ERP, los eventos de negocio y los controles de la empresa. La plataforma no corrige por sí sola catálogos sin dueño ni decide criterios fiscales. Sí aporta una capa fiscal y documental que puede integrarse con el sistema donde ya se captura la operación. En el Centro de soluciones puede revisarse qué componentes conviene incorporar y cuáles deben permanecer en el ERP.
Checklist para liberar la integración
- Existe un dueño por catálogo y una fuente de verdad documentada.
- Cada operación viaja con un identificador único y reutilizable para consulta.
- Los estados distinguen preparación, envío, resultado, excepción y cierre.
- Los reintentos consultan primero y no crean otro CFDI por defecto.
- El ERP recibe UUID, XML, PDF, mensajes y estado vinculados al pedido.
- Cancelaciones, sustituciones y pagos tienen flujos definidos y auditables.
- Las diferencias cuentan con responsable, evidencia y tiempo de atención.
- La salida a producción incluye conciliación y crecimiento gradual del volumen.
Antes de automatizar más escenarios, conviene comparar la integración con la captura manual de CFDI y confirmar que el nuevo flujo realmente conserva las referencias que hoy se pierden. La configuración fiscal final y los casos especiales deben validarse con el contador o asesor fiscal de la empresa.