Cuando una gran cadena de retail le compra a un proveedor, no manda un correo con un PDF para que alguien lo teclee al otro lado. Manda una orden de compra que la computadora del proveedor entiende sola, la carga en su sistema y responde con una factura por el mismo canal. Ese diálogo entre máquinas —sin humanos en medio— tiene nombre desde hace medio siglo: EDI. Es una de las tuberías más viejas y más ignoradas del comercio, y sigue moviendo un volumen enorme.
Qué es EDI
La idea es sencilla de enunciar y poderosa en consecuencias: en lugar de que dos empresas se manden documentos que una persona lee y re-teclea, sus sistemas los intercambian directamente en un formato que ambos acordaron entender.
EDI (Electronic Data Interchange) es el intercambio de documentos de negocio —órdenes de compra, facturas, avisos de envío— directamente entre computadoras, en un formato estándar y sin intervención humana.
Nació en los años 70 y 80, décadas antes de las APIs web. No es una tecnología nueva reinventándose: es infraestructura que lleva funcionando desde antes de que existiera internet como la conoces.
Cómo funciona
El ciclo, visto de punta a punta, es un traspaso limpio entre dos sistemas que hablan el mismo idioma acordado:
- El sistema origen genera el documento —por ejemplo, una factura— y lo traduce a un formato EDI estándar. Deja de ser un PDF o una pantalla y pasa a ser una estructura de datos rígida y predecible.
- El documento se transmite a la contraparte por el canal que ambos usen (más sobre esto abajo).
- El sistema destino lo interpreta automáticamente y lo carga en su ERP, sin que nadie lo teclee. Entra directo al flujo de compras, cuentas por pagar o logística.
La clave que sostiene todo: ambos sistemas acuerdan de antemano el formato exacto. No hay lugar para la ambigüedad. Cada campo está en una posición o segmento definido, con un tipo y una longitud esperados. Esa disciplina es lo que permite que la máquina de un lado confíe ciegamente en lo que le manda la del otro.
Los estándares
EDI no es un formato, sino una familia de estándares. Dos dominan el panorama:
- ANSI X12 — el estándar dominante en Norteamérica. Cada tipo de documento tiene un código numérico: el 850 es una orden de compra, el 810 una factura, el 856 un aviso de envío.
- EDIFACT — el estándar internacional, mantenido por la ONU. Cumple el mismo papel que X12 pero con nomenclatura propia (ORDERS para una orden, INVOIC para una factura).
Puede parecer burocrático que exista un código para cada documento, pero esa es justamente la gracia. La rigidez del estándar es lo que permite automatizar: si el proveedor sabe que "850" significa siempre y en todas partes una orden de compra con una estructura fija, su sistema puede procesarla sin que un humano confirme qué es. La flexibilidad sería el enemigo aquí.
Cómo se transmite
Una cosa es el formato del documento y otra el camino por el que viaja. EDI ha usado varios a lo largo de su historia:
- VANs (Value-Added Networks) — redes de valor agregado, intermediarios privados que actúan como buzón entre socios comerciales. Históricamente fueron el medio por defecto: cada empresa deposita y recoge sus documentos en la VAN, que se encarga del enrutamiento.
- AS2 — un protocolo moderno que transporta EDI sobre HTTP, con firma y cifrado, y con acuse de recibo. Elimina al intermediario: los socios se conectan punto a punto.
- SFTP — el intercambio de los archivos EDI por un canal cifrado sobre SSH, muy común en integraciones donde ya se mueven lotes de archivos.
Sobre este último vale detenerse: EDI y transferencia de archivos van de la mano, y ahí es donde importa que el canal sea seguro. Si te interesa por qué SFTP y no FTP para mover estos archivos, lo desarrollé en FTP vs SFTP: por qué la banca nunca transfiere por FTP.
Errores comunes
"EDI es cosa del pasado, ahora todo es API." Falso. EDI sigue moviendo gran parte del comercio mundial —retail, logística, salud, banca— por volumen, madurez y contratos ya establecidos entre socios. No compite con las APIs: convive con ellas. Las APIs cubren lo nuevo y lo de tiempo real; EDI sostiene lo que ya funciona a escala.
Más allá del mito de la obsolescencia, hay dos errores prácticos que se repiten:
- Creer que EDI es "un archivo cualquiera". No lo es. Es un estándar estricto: cada segmento, cada separador y cada campo tiene reglas. Un documento que no cumple el estándar al pie de la letra, el sistema destino lo rechaza.
- Subestimar el mapeo entre el estándar y tu propio sistema. Traducir tu factura interna al 810 —o del 850 a tu orden de compra— es el trabajo real de un proyecto EDI. Es ahí donde se van las horas, no en "mandar el archivo".
El ángulo banca
En banca, EDI aparece donde el negocio se cruza con las empresas. Bancos y clientes corporativos lo usan para remesas, pagos e integración B2B: instrucciones de pago, avisos de cobro, conciliación con grandes clientes que quieren que su ERP hable directamente con la plataforma del banco.
Y como esos intercambios llevan dinero e instrucciones sensibles, no viajan por cualquier canal: suelen ir por MFT o SFTP, transportes seguros con cifrado, control de acceso y auditoría de cada entrega. El formato es EDI; el sobre es cifrado.
EDI no es glamoroso. No sale en las charlas de arquitectura ni en los lanzamientos. Pero es la tubería silenciosa por la que corre el comercio: mientras el foco está en la última API, el 850 y el 810 siguen moviendo órdenes y facturas por millones, sin que nadie los teclee.
