We already take EDI orders. Where does AI fit?

EDI is a set of agreements as much as a technology. X12, the standards body behind the EDI transaction sets used across US supply chains, describes itself as ANSI-accredited, consensus-based and non-profit, chartered by the American National Standards Institute for more than 40 years, with more than 320 transaction standards available. Each transaction set has a number and a name, and one X12 subcommittee is assigned to maintain it. The standard is published once a year, in January, after proposed changes pass a series of ballots.

On top of the standard sits each trading partner's own rulebook. Best Buy's public vendor EDI page is one example. It names six documents that must all be in production, by traditional or web-based EDI, before the first PO is cut: the purchase order (850), the PO change (860), the invoice (810), the application advice (824), the ship notice (856) and the functional acknowledgment (997). It asks for a 997 within 24 hours, a separate invoice for each PO sent on the day it ships, and an SSCC-18 barcode label on every shipment.

Once a connection like that is built and tested, a partner's order loads without anyone reading it. That is the work EDI does well, and nothing below suggests changing it.

EDI needs both sides to build and test a connection, so it tends to cover the accounts big enough to be worth one. Everyone else reaches your desk some other way:

• Customers too small to connect. The contractor, the clinic, the independent store. Their POs arrive as email text, a PDF printed from their accounting software, or a photo of a form.
• Partners not yet live. A new account's orders come as PDFs or emails until its connection has passed testing.
• Portals. Web-based EDI lets a supplier without a translator work a partner's documents on a screen, and some buyers post orders to supplier portals of their own. If the order shows up on a screen rather than as a file your ERP reads, a person retypes it.
• Spreadsheets. Blanket releases, store-by-store allocations and replenishment lists sent as a file with one row per line.
• Orders that went around EDI. An EDI customer's buyer who phones or emails a rush order, or sends a change in a note instead of a change transaction.

Before choosing a tool, count. Pick a recent stretch that includes a month-end and a busy week, and work from data you already hold:

• Split orders by how they arrived. Many ERPs record an order source, an entry method or the user who created each order, and EDI orders often carry the translator's user or a batch number. Orders without it were keyed. If your system records none of this, your EDI translator's log gives the EDI count for the same dates, and the remainder is the gap.
• Count lines as well as orders. One EDI replenishment order can carry many lines; one emailed order may carry three. The keying time follows lines and exceptions more than order counts.
• Sort the keyed orders by customer. A short list of accounts that each send many orders may be worth an EDI conversation. A long tail of accounts that each send a few is where EDI will never reach.
• Note each order's format. Typed email, PDF, scan, portal screen, spreadsheet, phone. Clean PDFs from one accounting package make a different job from handwritten faxes.
• Mark the corrections. Credit memos, reissued orders and changed lines on keyed orders show where hand-keying goes wrong today, and for which customers.

If the keyed orders come to a few a day from a handful of steady accounts, AI is probably not worth a project. An EDI connection for the largest of them, or a fixed order form, may do the job with less to check.

If they come from many accounts in many formats, with corrections spread across them, that tail is where a test belongs. It is also where EDI will never help, because those customers have no reason to build a connection for the few orders they send you.

An EDI order loads cleanly because a great deal of checking was built around it. The functional acknowledgment, the 997, only confirms that a transaction was put together correctly; X12's own description says it does not cover the semantic meaning of what is inside. Whether the order makes business sense is a separate check, the kind X12's 824 application advice exists to report: the results of an application's data content edits, from acceptance through acceptance with change to rejection. Those edits live in your ERP and your translator maps: a valid item, a known ship-to, a price within contract, a quantity in a unit you sell.

An order keyed from a PDF should meet the same edits, and an AI draft of it should too. The draft resolves the customer's item numbers through the same cross-reference your EDI orders go through and converts their units the same way. It also has to land on the right ship-to record. GS1 US calls the Global Location Number, a 13-digit identifier for parties and locations, an integral data element of most EDI transactions, and since July 2022 a GLN that has been shared can't be reused, so it keeps naming one place. An emailed PO gives a street address instead, and the draft has to reach the record the GLN would have named.

Partner rules follow the order downstream too. A customer's requirements for labels, ship notices and invoices don't change because one order arrived by email, and Best Buy's page tells vendors not to accept verbal POs unless an 850 confirms them. An order taken outside EDI from a partner like that has to be matched to the EDI order that follows it, never entered twice. So the real test is not whether AI can read a PDF. It is whether its drafts pass the edits your EDI orders pass, and whether the person approving them can see which line failed which rule.

Our free AI proof of concept is aimed at the gap and leaves EDI alone. Your reviewer, the person who knows your order desk best, picks 20 to 30 non-EDI orders your team already entered, from the tail your count turned up, each with the sales order it became. After an NDA is signed you send copies of both, plus exports of the cross-reference and ship-to lists your EDI orders run through. Nothing logs in to your ERP, your translator or any portal, and nothing changes in your EDI setup.

Each draft is scored against the order your team entered, field by field and against the same edits an EDI order must pass. The success criteria and a price range for the live job are agreed before it starts, and your reviewer's call decides it. After a yes, the job runs on new non-EDI orders for about 30 days, with a person approving each order before it posts. Acknowledgments, ship notices and invoices keep going out the way they do today.