Reading EDI 850 POs via your email translator: a poor-man's EDI workflow

Some of your bigger customers send EDI 850 purchase orders. Their VAN drops the file in your email as an attachment. Here is the workflow we use to feed those into SideQuest without buying a full-blown EDI integration.

EDI 850 is the ANSI X12 transaction for purchase orders. If you've never seen one, it looks like this:

ISA*00*          *00*          *ZZ*ACMECORP       *ZZ*WIDGETCO       *240115*1234*U*00401*000000001*0*P*>
GS*PO*ACMECORP*WIDGETCO*20240115*1234*1*X*004010
ST*850*0001
BEG*00*SA*PO-88421**20240115
PO1*1*10*EA*123.00**BP*DM19012*VP*BR-ELB-075-NPT
PID*F****Rollerblade
PO1*2*5*EA*90.00**BP*DM78123
PID*F****Gas Can Sunglasses
CTT*2
SE*8*0001
GE*1*1
IEA*1*000000001

Two line items, a header, a footer, segment terminators every few characters. It's machine-readable, sort of, after you've spent an afternoon learning the segment grammar. The good news: a lot of EDI is delivered to you the same way email is — as a file. Your VAN (Value-Added Network) translates the wire-protocol delivery into a flat text file and emails it to a designated inbox. From there, SideQuest's pipeline just needs to know how to read 850 segments.

The poor-man's workflow

You don't need a real EDI integration to handle a low volume of 850s. You need:

1. A Gmail address where your VAN drops files (most VANs offer email delivery as a non-default option — ask them).
2. A Gmail filter that labels anything from that VAN as purchase-orders.
3. A small Claude prompt that knows how to read EDI 850 syntax.

That's the whole list. The piece SideQuest contributes is steps 2 and 3 — the connector reads the labeled email, pulls out the .txt or .edi attachment, and when its default extractor fails (because EDI is neither PDF nor table) Claude vision falls back. We've found Claude reads 850 segments fluently because the grammar is documented enough to be in the training data.

The mapping that matters

For SideQuest's matcher to use EDI lines, we care about three segments:

• BEG — the PO header. Position 3 is the customer's PO number.
• PO1 — one per line item. Position 1 is the line number, position 2 is quantity, position 4 is unit price, then a series of qualifier/code pairs. BP means buyer's part number, VP means vendor's part number, UP means UPC.
• PID — product description, immediately following the PO1 it describes.

The trick: VP is your part number (the vendor's). If the buyer included one, SideQuest's exact-SKU match resolves the line at confidence 1.0 with zero work. If only BP is present (the buyer's part), the cross-reference table kicks in. If neither is present, the PID description gets fuzzy-matched.

What this doesn't handle

This workflow handles inbound 850s. It doesn't handle:

• EDI 855 (PO acknowledgement) — the response your customer expects after you accept their PO. Your VAN sends this on your behalf if you give it the data. SideQuest doesn't generate 855 today.
• EDI 810 (invoice) — your invoice back to the customer. Most VANs accept a flat file from you and translate to 810. QB can export the data; you do the file dance manually.
• True AS2 / VAN-direct delivery — if your customer mandates AS2 with signed receipts, you need a real EDI service. Cleo, SPS, OpenText, etc.

For distributors doing 1-30 EDI POs a week from one or two bigger customers, the email workflow is plenty. If you're moving 200 a day, you'd want a real EDI integration regardless. We'd help you scope that decision honestly.

What we'd build next

An EDI 850 parser native to SideQuest is on the medium-term roadmap. It would skip the email-attachment hop and Claude-vision fallback and instead handle 850 segments deterministically. If you're hitting this workflow today, write us — knowing you exist moves the priority up.