PDF and email → EDIFACT
Convert PDF purchase orders to EDIFACT
Most customers don’t order via EDI but with a PDF attachment or an informal email. every-edi extracts these orders, has a person review them and outputs them as EDIFACT ORDERS D96A: with AI the first time, then with a learned profile and no AI.
At a glance
- Input
- Text-based PDF (attachment or upload), email body
- Output
- EDIFACT ORDERS D96A; alternatively cXML, openTRANS 2.1, JSON
- First file from a sender
- One-off analysis with AI, checked by a person
- Later orders
- Learned profile, no AI
- Release
- After review in the dashboard; automatic only for known profiles with high confidence
Why PDF orders are a problem of their own
To a person a PDF is unambiguous; to an ERP it is just text at certain positions on a page. Every customer has their own layout: the order number sits top right or in the subject line, lines come as a table or as running text, the delivery date as a date or as “week 42”. Traditional EDI providers have no answer to this, because they only connect customers who already send structured data.
So in many companies someone retypes these orders. With a handful of orders that works. With hundreds a month it costs staff hours and produces typos that only surface at delivery.
How the conversion works
- Receipt. The order arrives as before: by email to a watched mailbox, through a folder or by upload. Your customer changes nothing.
- First contact: extraction with AI. If every-edi doesn’t know this customer’s layout yet, a language model extracts header and line data. If you prefer, this model runs locally on your own infrastructure.
- Review by a person. The extracted fields appear in the review dashboard next to the original. You correct anything that’s wrong and approve.
- Profile learned. The approved order becomes a profile for this customer’s layout. From that sender’s next order on, the profile reads the data: rule-based, reproducible, without AI and in seconds.
- Release. Orders are checked before release. They are released automatically only when the profile is known and the extraction is highly confident; everything else goes to review.
- Output as EDI. The order is generated as EDIFACT ORDERS D96A and delivered to wherever your ERP picks it up.
Example
First, an order from a fictitious German customer as it arrives as a PDF (shown here as text), then the EDIFACT message generated from it, without the interchange header. The table shows which value goes where and what has to be translated on the way.
Beispiel Haustechnik GmbH · Am Hafen 12 · 28217 Bremen
BESTELLUNG Nr. B-26-0815 Datum: 08.10.2026
Kunden-Nr. bei Ihnen: 10042 Liefertermin: KW 42
Lieferanschrift: Lager Nord, Tor 3, Hafenstraße 40, 28217 Bremen
Pos Art.-Nr. Bezeichnung Menge Einh. Preis/Einh.
1 ART-7720 Hydraulikzylinder HZ-200/100 4 Stk 285,00 €
2 ART-3381 Dichtungsset DS-200 4 Satz 42,50 €
3 ART-9910 Hydraulikschlauch 2m DN10 10 m 18,90 €
Summe netto: 1.499,00 €UNH+1+ORDERS:D:96A:UN'
BGM+220+B-26-0815+9'
DTM+137:20261008:102'
DTM+2:20261012-20261016:718'
NAD+BY+4012345000009::9'
NAD+DP+4012345000016::9'
CUX+2:EUR:9'
LIN+1++ART-7720:SA'
IMD+F++:::Hydraulikzylinder HZ-200/100'
QTY+21:4:PCE'
PRI+AAA:285.00'
LIN+2++ART-3381:SA'
IMD+F++:::Dichtungsset DS-200'
QTY+21:4:SET'
PRI+AAA:42.50'
LIN+3++ART-9910:SA'
IMD+F++:::Hydraulikschlauch 2m DN10'
QTY+21:10:MTR'
PRI+AAA:18.90'
UNS+S'
MOA+79:1499.00'
UNT+22+1'All names, numbers and GLNs in the example are fictitious.
| In the PDF | In EDIFACT | What happens |
|---|---|---|
| Bestellung Nr. B-26-0815 | BGM+220+B-26-0815+9 | The customer’s order number; 220 = order. |
| Datum: 08.10.2026 | DTM+137:20261008:102 | The German date format becomes CCYYMMDD. |
| Liefertermin: KW 42 | DTM+2:20261012-20261016:718 | A calendar week is not a date. Here it is output as a Monday-to-Friday range (format 718). If your ERP expects a single date, that rule has to be settled before go-live. |
| Kunden-Nr. bei Ihnen: 10042 | NAD+BY+4012345000009::9 | The customer number alone isn’t enough for EDI: the buyer appears as a party with an unambiguous ID, here a GLN. |
| Lager Nord, Tor 3, … | NAD+DP+4012345000016::9 | The delivery address becomes a party of its own (DP), separate from the buyer. |
| 4 Stk · 4 Satz · 10 m | QTY+21:4:PCE · SET · MTR | In-house units like “Stk” (pieces), “Satz” (set) and “m” become codes. |
| 285,00 € | PRI+AAA:285.00 · CUX+2:EUR:9 | The decimal comma becomes a full stop and the euro sign becomes the currency segment. |
| Summe netto: 1.499,00 € | MOA+79:1499.00 | The total serves as a check value: it has to match the lines. |
Common pitfalls
-
Every customer has their own layout
Fixed templates per customer break as soon as the customer changes their form. What matters is that this gets noticed: an order that no longer matches the known layout belongs in review, not in your ERP with wrong values.
-
A customer number is not a GLN
The PDF shows your customer number, sometimes none at all. The EDI for your ERP or your EDI provider needs unambiguous partner IDs. Without a mapping from your master data, even perfect extraction is useless.
-
Numbers and dates in local formats
To a program, “1.499,00” is not the same as “1,499.00”. “Week 42”, “mid-October” or “as soon as possible” are not dates. Each of them needs a fixed rule.
-
Units and pack sizes
“1 carton” can mean 12 pieces, and “set” is not a standard code. The conversion to the units in your item master must be unambiguous, or you ship twelve times the quantity.
-
Scanned PDFs and faxes
A scanned PDF is an image with no text. every-edi can’t process such files yet, because there is no text recognition (OCR) so far. The system detects them and asks for a text-based PDF instead of guessing.
-
Informal emails
“Same as last week, but 20 hoses instead of 10”: references to earlier orders can’t be resolved automatically with certainty. Orders like that belong in review, not straight in your ERP.
What every-edi does with it
- Watched mailbox and inbound folder: orders are processed as soon as they arrive.
- AI only for the first file from a sender; a person checks the result, then the learned profile processes their orders without AI.
- Optionally with a local model, so your order data never leaves your infrastructure.
- Review dashboard with the original and the extracted fields side by side, corrections in one click. Automatic release only for known profiles with high confidence.
- Output as EDIFACT ORDERS D96A or as cXML, openTRANS 2.1, JSON or CSV, whichever your ERP understands.
What is not included (yet)
Scanned and image-only PDFs are not processed yet, because there is no text recognition (OCR); every-edi detects them and asks for a text-based PDF. Beyond that, every-edi only converts purchase orders: invoices, delivery notes and order confirmations in PDF form are not currently in scope, and neither is generating e-invoices such as XRechnung or ZUGFeRD.
Other formats
every-edi also handles GEVIS XML (GEVISEDI01), CSV with header and line records (HDR/POS), free-form CSV tables via learned CSV profiles, and JSON over a REST interface.
Send us a real file.
The quickest way to find out whether every-edi fits your customers is with real examples: three orders and, if you have one, your partner’s specification. You get the result back in the target format.
Request a demo