How to Connect Suppliers Who Won't Use Your Portal

You connect suppliers who won't use your portal by meeting them on the channel they already use: email. An AI intake reads their order confirmations, PDFs and replies, turns them into structured data and books them, so nothing changes for the supplier. Portal, EDI and email then work side by side, and supplier coverage reaches 100 percent instead of stalling at the willing half.

Why do suppliers refuse portals?

Every supplier collaboration project starts the same way. The buyer rolls out a portal, the first wave of suppliers signs up, and adoption climbs to somewhere between 40 and 70 percent. Then it stops. The remaining suppliers do not log in, or log in once and go back to email. The buyer's team keeps two processes running, one structured and one manual, and the business case that assumed full coverage never arrives.

In our interviews with industrial buyers this autumn, the reasons came up unprompted and were always the same three:

• The thousand-portals problem. A large component maker told one of our customers that it has a thousand customers, each with its own portal, and that it will keep working from its own ERP. That supplier is not being difficult. It is making a rational choice: a thousand logins is not a process.

• Maturity. Some suppliers, often smaller or further away, do not have the people or the habit for structured data exchange. A Chinese casting supplier with one export clerk will answer email. It will not maintain a European customer's portal.

• Perceived extra work. Even a well-designed portal asks the supplier to re-enter what their ERP already produced. The confirmation exists; the portal wants it typed again.

The result is predictable. In the Tradecloud network, where over 1,300 European suppliers received orders in the past year, the suppliers who connect fastest are the ones with several customers on the same network. The long tail, suppliers serving one customer, is where adoption is slowest, and that long tail is most of any supply base.

None of this is a portal design problem. It is a channel problem. The fix is not a better portal; it is more channels.

Which channels can a supplier use, and what does each cost you?

There are four ways a supplier's confirmation can reach your systems. Each trades setup effort against data quality, and each suits a different part of the supply base.

Two observations from the table. First, EDI is often chosen for the wrong suppliers: it pays off on volume, not on importance, and a six-month EDI project with a strategic supplier who sends 20 lines a month is a poor trade. One of our customers had 50 suppliers earmarked for EDI, and after half a year exactly one was live, held up by field mappings and minimum order quantities. Second, email is not the problem. Email is how most suppliers already work, and it carries the confirmation their ERP produced. The problem is that a person has to read it and type it in.

AI intake removes that step. The supplier keeps sending what it sends today. The buyer's side changes.

How does AI email intake work?

The mechanism is simpler than the name suggests. The supplier is told one thing: send your order confirmation to this address. From there, six steps run without a person:

1. Receive. The message lands in a dedicated mailbox. Each purchase order carries its own reply address, so the system knows which order a reply belongs to even when the supplier changes the subject line.

2. Classify. Is this a confirmation, a change, a shipping notice, a question, or an out-of-office reply? Each type takes a different path.

3. Extract. The AI reads the body and any attachment, including a PDF confirmation generated by the supplier's own ERP, and pulls out the order number, line references, quantities, prices, delivery dates and units.

4. Match. Each extracted line is matched to the open order line. Supplier item codes are mapped to your item codes; units are normalised (a supplier confirming 2 boxes of 50 against an order for 100 pieces is a match, not a deviation).

5. Validate. The result is compared with the order. Lines that match, or deviate within the tolerance set for that supplier and item class, are booked. The rest go to a buyer as exceptions, with the original email attached.

6. Learn. Every correction a buyer makes teaches the system that supplier's format, so the second confirmation from the same supplier reads better than the first.

The buyer sees each line marked as "confirmed by email, read by AI", with a confidence score and a link to the source message. A supplier who prefers the portal still uses the portal; the two channels feed the same order record.

What this does to supplier onboarding is the real point. Instead of inviting suppliers one at a time and waiting for them to register, you send every open order to every supplier on day one and let the responses come back on whichever channel they choose. Coverage is 100 percent from the first week, and the portal becomes an upgrade some suppliers take rather than a barrier all suppliers must pass.

Which suppliers belong on which channel?

Do not aim for one channel for everyone. Segment the supply base by order volume and by what the supplier can realistically do, then assign the channel. A workable split for a mid-sized manufacturer with 300 suppliers looks like this:

The long tail is the largest group by count and the smallest by volume, which is exactly why it never got connected: no individual supplier justified the effort. With AI intake the effort per supplier is zero, so the count stops mattering.

Two refinements help. First, let suppliers move between channels. A long-tail supplier that lands a second customer on the same network will often switch to the portal on its own, because then one login covers two customers. Second, keep the escalation path separate from the channel. Whether a confirmation arrives by EDI or by email, a deviation outside tolerance should reach the same buyer in the same queue. Buyers should never have to know which channel a supplier uses.

How accurate is it, and what can go wrong?

Three questions come up in every conversation about reading supplier email with AI.

Will it read the confirmation correctly? Modern document reading is good at the common case: a PDF or email that states an order number, lines, quantities and dates in some recognisable layout. The hard cases are the ones buyers already struggle with: confirmations covering several orders, lines renumbered by the supplier, units that differ from the order, prices quoted per hundred. The right standard is not perfection but a measured accuracy with a safety net. Run the system in shadow mode for four to six weeks, compare its reading with what your buyers booked, and insist on 95 percent or better before it books anything on its own. Below the confidence threshold, it should ask, not guess.

What about suppliers who confirm twice? This is more common than most buyers expect. A supplier with its own ERP enters a confirmation in the portal and then, by habit or by system, also sends the PDF confirmation by email. The two can differ, usually in date, sometimes in quantity. Today nobody notices until goods receipt. An intake that reads both channels flags the difference as an exception. That is a class of error that disappears, not a new one that appears.

Can someone forge a confirmation? Yes, if the mailbox trusts whatever lands in it. Three controls make that hard. Check that the sending domain is authenticated (SPF, DKIM and DMARC are the standard mechanisms, and your IT team will know them). Use a unique reply address per order, so a message that claims to confirm order 4711 has to arrive at 4711's address. And route any confirmation from an unknown sender, or any change to price above a threshold, to a person. Ask these three questions of any vendor before you connect a mailbox.

The honest summary: AI intake is not a replacement for structured channels where they exist. It is the way to stop the unstructured ones from costing you a buyer's afternoon, with controls that are stricter than the manual process they replace.

How do you measure coverage, and how fast can you get there?

Most teams measure portal adoption as the share of suppliers with an account. That number flatters the project and hides the problem. Measure instead the share of order lines confirmed through a structured channel, whether portal, EDI or AI intake, and the share of suppliers active within 30 days of their first order. The first number tells you how much manual work remains. The second tells you whether onboarding works.

A realistic 30-day plan for a company starting from a partly adopted portal:

• Week 1. Export open orders from the ERP and send them to all suppliers, portal and email alike. Switch on the intake mailbox. Tell suppliers one thing: reply or send your confirmation here. No registration, no training.

• Week 2. Run in shadow mode. Buyers keep booking as they do today; the system reads alongside them. Review the first week's reading accuracy per supplier.

• Week 3. Switch date confirmations within tolerance to automatic booking for the suppliers with proven accuracy. Keep price and quantity on review.

• Week 4. Measure. Share of lines structured, share of suppliers active, hours saved per buyer. Invite the suppliers with the highest volumes to the portal, now as an improvement rather than a precondition.

The target at day 30 is 80 percent of suppliers active, meaning their confirmations arrive and are read without a person retyping them. From there the remaining work is tolerance tuning and the gradual move of high-volume suppliers to structured channels, at their pace rather than yours.

If you want to see what your current coverage is, start with one number: how many of last month's order lines did a buyer type into the ERP by hand? That is the size of the gap, and the size of the opportunity.

Frequently asked questions

Why do suppliers not use our portal? Usually one of three reasons: they serve many customers and cannot maintain a login for each, they lack the people or habit for structured data entry, or the portal asks them to retype what their own ERP already produced. None of these is solved by a better portal; they are solved by accepting email as a channel.

Is email a reliable channel for order confirmations? Email is reliable as a transport; the unreliable part was the person retyping it. With AI intake reading the message, matching it to the order and flagging deviations, email becomes a structured channel with an audit trail. Accuracy should be measured in shadow mode before anything is booked automatically.

Should we still invest in EDI? For the few suppliers that send hundreds of lines a month and have the IT capacity, yes. For everyone else, the setup cost per supplier is hard to recover. Many companies plan EDI for dozens of suppliers and connect a handful; AI intake covers the rest from day one.

What if a supplier confirms both in the portal and by email? That happens often with suppliers who run their own ERP, and the two confirmations can differ. An intake that reads both channels compares them and raises an exception when they disagree, which today usually goes unnoticed until delivery.

How do we stop a forged email from changing a delivery date? Authenticate the sender (SPF, DKIM, DMARC), use a unique reply address per purchase order, and route confirmations from unknown senders or with price changes above a threshold to a person. Any vendor should be able to show you these controls.

How quickly can we reach full supplier coverage? With orders exported from the ERP and an intake mailbox, every supplier can be live in the first week, because nothing changes on their side. A realistic target is 80 percent of suppliers active within 30 days, with the remaining time spent on tolerance tuning rather than onboarding.

About the author

Tonnis de Boer is CEO of Tradecloud, the supply chain platform connecting around 30,000 industrial companies across Europe, and leads Syracus AI, Tradecloud's AI product line. He has spent over a decade on the operational side of industrial procurement and supplier collaboration.

Syracus AI Supply Chain Ops reads supplier confirmations from any channel, portal, EDI or email, and runs the order flow on the Tradecloud network so your team steers only the exceptions. It is in development; apply for the closed beta, read more about Supply Chain Ops, or start with our guide to AI agents in procurement.