Picture a call center operator in Caracas. It’s 9 AM and she has SAP Business One open on one monitor, and WhatsApp Web with 47 unread messages on the other. One of those messages is a two-minute audio from a field sales rep calling from a pharmacy in Valencia: “send me the same as last week but swap the paracetamol for the 400mg ibuprofen, and add two boxes of that anti-inflammatory, the big one, the one that comes in blister packs.”
That has to get into SAP. Someone has to translate it.
It’s 2026. The ERP has been in place for 15 years. The problem isn’t new either.
The ERP as a system of record, not of capture
There’s a technical distinction that most companies fail to make precisely: an ERP is a system of record for structured transactions, not a system of capture for unstructured commercial intent.
SAP Business One, Profit Plus, Oracle NetSuite — all were designed to store and process data that already arrives in the correct format. An order in the ERP has fixed fields: customer code, product code (exact SKU), quantity, unit of measure, price list, dispatch warehouse. The ERP is extraordinarily good at processing that data once it’s correctly formed.
What the ERP doesn’t do — and was never designed to do — is interpret “the 400mg ibuprofen” and convert it to SKU-IBUP-400MG-TAB-20 according to the customer’s product master. That translation has always been someone’s job.
The real channels of a LatAm distributor
A pharmaceutical laboratory or FMCG distributor in Venezuela, Colombia or Bolivia receives orders through a variety of channels that no IT department officially designed:
- WhatsApp Business: the dominant channel. Voice notes, photos of handwritten lists, text messages with buyer-specific abbreviations.
- Email with PDF attachment: the buyer has their own purchase order format. Each client has theirs, with their own columns, their own headers, sometimes in Spanish, sometimes mixed with English.
- Email with inline table: not even an attachment. Data pasted directly into the email body, with formatting that depends on which email client the buyer used.
- Phone call: the field sales rep calls from the point of sale. The operator takes notes on paper or in a personal Excel before entering the system.
- Proprietary web portal: if the distributor has one, clients who managed to register use it. Usually a fraction of the total.
Each of these channels arrives with a different format, different possible errors, different information completeness. One client sends the correct product code; another sends the product name as they know it at their pharmacy, which may differ from the name in the distributor’s catalog.
The manual entry trap
The visible cost of this process is the operator’s salary. But that’s not the real cost.
The real cost lives in three places:
Transcription errors. A product code with one wrong digit. A quantity of 20 read as 200. A 20-unit presentation SKU confused with the 100-unit presentation. These errors generate wrong shipments, returns, credit notes, complaint calls, deteriorating commercial relationships. They don’t show up as “operator errors” in management systems — they appear as “inventory adjustments” or “customer returns,” their true causes invisible.
Shadow spreadsheets. Operations teams develop their own workbooks to validate orders before entering them in the ERP: price lists extracted from the system, custom product coding, customer order history. These files are fragile, not synchronized with the ERP, and represent an operational risk that no audit typically detects in time.
Implicit growth ceiling. If processing 200 orders per day requires 4 operators, processing 400 orders requires 8. Business growth has a linear labor cost in data entry staff — a ceiling that appears in no board roadmap, but that inevitably surfaces when the business scales.
Why standard EDI connectors don’t solve this
The standard IT answer to this problem is “let’s implement EDI.” And they’re right — in the right context.
Classic EDI (ANSI X12, EDIFACT) is an extraordinarily effective solution when both parties have systems capable of generating and consuming structured documents in an agreed format. A large retail chain can require its suppliers to have EDI certification because it has the negotiating power to do so. Suppliers adapt or lose the contract.
In pharmaceutical and FMCG distribution in LatAm, that power asymmetry doesn’t work in the same direction. The laboratory can’t require a 3-employee pharmacy in Maracaibo to implement SAP and certify an EDI channel. That pharmacy will keep sending its order via WhatsApp because that’s what it has and knows how to use.
The result: 80% of orders from an average Venezuelan laboratory don’t come through EDI — they come through the unstructured channels described above. The EDI connector solves the 20% that already had a system. The other 80% remains manual labor.
The problem has a name
What we’ve just described is called unstructured order capture at the B-side of B2B. It’s the most common, most costly, and most ignored problem in the commercial supply chain in Latin America.
The solution is not forcing the client to change their channel. The neighborhood pharmacy is not going to adopt EDI. The field sales rep is not going to stop using WhatsApp.
The solution is to absorb the client’s channel — whatever it is — and deliver structure to the ERP. Receive the chaos and produce order. That’s what we do at Greicodex, and what we call Asymmetric EDI.
The next article explains how that architecture works in detail.