The term “EDI” is nearly 50 years old. It was born in the 1970s to eliminate paper between the mainframe systems of American retailers and their suppliers. ANSI X12 in North America, EDIFACT in Europe — electronic interchange standards that defined with surgical precision what a purchase order, an invoice, or a shipment notice should look like.
It works. In the right context, EDI is one of the most reliable integrations in the global supply chain. The reason is simple: both parties speak exactly the same protocol. No ambiguity.
But that is also its fundamental assumption — and its most important limitation in Latin America.
The silent assumption of EDI
For EDI to work, the sender needs a system capable of generating structured documents in the correct format. An X12 EDI 850 purchase order has specific segments, elements, and qualifiers. To produce it, the sender needs EDI translation software, a mapper configured with the receiver’s requirements, and a VAN (Value Added Network) or AS2/SFTP connection for transmission.
In the U.S., large retailers (Walmart, Target, Home Depot) have the negotiating power to require this from every supplier that wants to do business with them. The supplier invests in EDI certification or loses the contract. Adoption is forced from above.
In Venezuela, Colombia, or Bolivia, that equation doesn’t work the same way. A pharmaceutical laboratory cannot require EDI certification from a regional drugstore with 12 employees. An FMCG distributor cannot make its sales conditional on the village grocer adopting SAP.
The result: most B2B orders in the region arrive outside structured channels. Email, WhatsApp, phone call, PDF with proprietary format. Classic EDI solves the exceptions; the volume remains manual.
Definition of Asymmetric EDI
Asymmetric EDI is the ability to receive an order in any format the client chooses to use — WhatsApp, PDF, email, Excel, web form, transcribed call — and produce as output an equivalent structured document, ready to enter the receiving ERP.
The asymmetry is in the input channels: the sender does not need to be structurally symmetric with the receiver. The laboratory has SAP; the pharmacy has an Excel. The distributor has Profit Plus; the regional supermarket sends a voice note. In Asymmetric EDI, that difference in technical sophistication stops being an operational problem.
What doesn’t change is the result: the order that reaches the ERP is as precise and traceable as if it had come through classic EDI. Correct product code, correct quantity, correct unit of measure, price list applied, warehouse assigned.
The three technical components
An Asymmetric EDI architecture has three layers:
1. Multichannel capture layer
Specific connectors for each input channel:
- WhatsApp Business API: receives text messages, voice notes (with automatic transcription), and images.
- Email IMAP: monitors inboxes, extracts attachments (PDF, Excel, Word), and reads message bodies.
- PDF processing: parses variable-format purchase order documents without depending on a fixed template.
- Web forms: structured interface for clients who prefer a guided channel.
Each connector delivers to the central engine the raw content of the order in plain text. No intelligence here yet — only extraction.
2. Cognitive interpretation engine
This is the differentiating layer. Not rigid rules like “if column B says ‘quantity’ then it’s field X.” These are models trained to:
- Identify entities: which text in the document is a product code, which is a quantity, which is a unit of measure, which is a free description.
- Resolve ambiguities: “the 400mg ibuprofen” is mapped to the correct SKU using the client’s catalog and the buyer’s order history.
- Detect inconsistencies: a quantity of 2,000 units for a product this client normally buys in lots of 50 generates an alert, not a silent order.
- Apply business rules: if product A has no stock, the rule configured for this client may be to offer substitute product B, or to halt the order for human review.
The output of this layer is an internally structured order, with confidence assigned to each interpreted field. High-confidence fields pass automatically; low-confidence fields are escalated for human review with full context.
3. ERP adapter
Once the order is structured, the adapter converts it to the exact format consumed by the destination ERP and executes the transaction:
- SAP Business One: uses the Service Layer (SAP B1’s native REST API) to create sales orders, verify stock, and apply the client’s commercial conditions.
- Profit Plus: integration via API or database layer depending on the client’s version.
- Oracle NetSuite, Odoo: configurable adapters by schema.
The adapter knows the client’s specific business rules: which price list to assign based on the buyer’s segment, which warehouse to use based on the dispatch region, how to handle products not in the catalog.
What Asymmetric EDI is not
Three common confusions:
Not generic OCR. OCR extracts text from images or PDFs but doesn’t interpret that text in the context of a specific business. The difference between OCR and Asymmetric EDI is the same difference between transcribing an audio and understanding what it says.
Not a chatbot. Chatbots are conversational interfaces. Asymmetric EDI is a transaction processing engine. It doesn’t answer questions — it processes orders.
Not RPA. Robotic Process Automation copies data from screen to screen, replicating human mouse movements. It’s fragile (an interface change breaks the robot), slow (executes step by step), and doesn’t interpret. Asymmetric EDI works with ERP APIs and Service Layers, not with the graphical interface.
The B2B Certainty principle
In industries like pharmaceuticals, a misprocessed order has consequences that go beyond financial cost. Dispatching the wrong medication or incorrect dosage is a public health issue, not just an operational one.
That’s why at Greicodex we apply what we call B2B Certainty: the system guarantees that every transaction reaching the ERP is correct, or raises a traceable exception with full context for human review. There are no orders that “were processed as best as possible with available information.” There are confirmed orders or orders under review.
This means the interpretation engine doesn’t maximize the percentage of automatically processed orders — it maximizes the percentage of correct orders. The automation rate matters, but the accuracy rate is non-negotiable.
All processing is auditable. Every decision made by the system has a log: what text arrived, how it was interpreted, with what confidence level, what business rule was applied. That log is available to the client in real time. No black box.
A concrete case: Pharma Conecta
The Asymmetric EDI architecture described here is not theoretical. Pharma Conecta is a real implementation of these principles applied to a Venezuelan pharmaceutical call center.
In that specific case, the input channel isn’t the external client channel (the order sender is the call center operator, not the drugstore), but the principle is the same: receive incompletely structured information — a phone call — and produce a perfect order in the ERP, with stock verification, price list, and complete traceability.
The next article describes how that system works in detail.