Our orders come in through portals, faxes and email at once. Can one AI test cover all three?

Picture one order for 40 cases sent three ways. By email it is the buyer's own words: a PDF from their purchasing software, or a few lines in the body of a reply, sometimes with a quantity changed in the message but not on the attachment. On a portal it is the buyer's system speaking. The fields, the item numbers and the order number follow their layout, terms may be accepted with a click, and the order may exist only on a screen that the next revision overwrites. By fax it is a picture of paper: a printed form or a handwritten list, with a cover sheet and a line of small type across the top.

That line of type is a legal requirement. Under the FCC's rule at 47 CFR 68.318(d), anyone in the United States sending a fax from a computer or other device must mark the date and time, an identification of the sender, and the telephone number of the sending machine or of the sender, in a margin at the top or bottom of each page or on the first page. The number a machine announces during the call is separate. ITU-T T.30, the fax procedure standard, defines it as an optional signal carrying the sending terminal's international number in a 20-digit field. Both name a machine or a line, not the customer account an order belongs to, and a shared office line or a fax service can sit between the buyer and you.

The channels blur, too. A 2019 declaratory ruling by the FCC's Consumer and Governmental Affairs Bureau, DA 19-1247, describes online fax services that let people get faxes the way they get email, by logging in to a server or receiving a PDF attachment. The door an order came through tells you little about what is inside it. We cite these fax rules for context only; none of this is legal advice.

For a test, nothing logs in to a portal, a mailbox or a fax line. Your team saves what it already sees on finished orders: the file a portal lets a supplier download, a page printed to PDF, or a screenshot when the order only ever lived on a screen; the fax image as it was stored, or a scan of the paper; the email as a saved message with its attachments. Each is a copy of a document your team already handled, and a copy is all a test needs.

Send fax images as they were stored rather than fresh scans of printouts. T.30 splits a call into five phases, and in the fourth the receiving machine confirms what arrived. How that machine judges copy quality is left to its own algorithm, and error correction is optional, so a page your machine accepted can still be hard to read.

Portal copies need one extra note. A portal may show an order under its own document number as well as the buyer's PO number, and a revision may replace the original on screen. Save each version your team saw, with the date it appeared, because the draft is scored against the order as your team entered it at the time.

Take orders from all three channels in roughly the proportions your desk handles them, and for each one bring:

• From email. The saved message with every attachment, not just the PDF. Buyers change quantities and ship-tos in the body, and a forwarded chain can hold two versions of a PO.
• From portals. The download, printout or screenshot your team worked from, both the portal's document number and the buyer's PO number, and any later revision or cancellation.
• From the fax line. Every page as received, cover sheet included, with the header line intact and handwriting left in.
• For every order. The sales order your team entered, any change made to it afterward, and one line saying which channel it came by and when it arrived.
• The repeats you already know about. Three or four orders that came twice by different routes, with what your team did about each.
• The lists your desk checks against. Exports of customers, ship-tos, items and customer part numbers.

An order faxed in and then keyed by the buyer on their portal. An emailed PO resent because no acknowledgment came back. A portal order printed and faxed over by a branch that didn't know it was already in. On its own channel each one looks new, and a desk that works one inbox, one fax tray and one portal queue sees two orders.

Auditors know the problem from the payment side. Richmond, Virginia's Office of the City Auditor, in a May 2026 review, listed the usual causes of duplicates: the same invoice submitted more than once, slight variations in invoice numbers, duplicate vendor records, and numbers assigned inconsistently when a request arrived without one. It searched for different numbers with the same amount, date and vendor, and noted that its criteria might not find them all. The Washington State Auditor's Office adds that no single control prevents duplicates, and that invoice numbers keyed inconsistently can get past the software's own checks.

Orders repeat for the same reasons, and one number isn't enough to match on. A duplicate-PO warning only works when the numbers match, and a portal's own document number, a fax with no PO number or a buyer who adds "-R" to a resend all slip past it. So each draft is compared with the open orders you send and the other orders in the sample on several things at once: customer and ship-to, lines and quantities, requested date, and how close together the two arrived. A likely repeat is marked with the earlier order it resembles. The draft never drops, merges or cancels it.

Your reviewer scores repeats like any other field: caught, missed, or flagged when the two orders really were different. The known repeats you sent are the answer key for that score.

A person decides every possible repeat, every change to an open order, and every case where two channels disagree, such as a fax that says 40 and a portal entry that says 400 for the same PO. Handwriting that changes a printed line or a note on a cover sheet is read by the draft and judged by your team.

Acknowledgments carry weight. Under UCC 2-201(2), between merchants, a written confirmation the other side receives and has reason to know the contents of can satisfy the code's writing requirement against that side unless it objects in writing within 10 days of receiving it. So when channels disagree, a person decides what to confirm. This isn't legal advice; your counsel can say how the rule applies to your terms.

Whatever happens inside a customer's portal stays with your team: accepting an order, acknowledging a change, updating a ship date.

Our free AI proof of concept covers all three channels in one sample. Your reviewer, the person who knows your order desk best, picks 20 to 30 orders your team already entered, in about the mix you see, plus the known repeats. Once an NDA is signed you send copies, and nothing touches a live portal, mailbox or fax line. Each order is tagged by channel, so a desk that does well on portal downloads but struggles with handwritten faxes learns that from one test, not three.

The success criteria and a price range for the live job are agreed before anything starts, and your reviewer's call decides it. After a yes, the job runs on new orders from all three channels for about 30 days, with a person approving each order before it posts. Orders that arrive by EDI are a separate question, answered in our field note "We already take EDI orders. Where does AI fit?", and this test leaves them where they are.