Ten formats, three mailboxes, and nobody retyping anymore

Short answer. You import orders from a supplier portal automatically by reading the source (portal, EDI, or free-text email), normalizing the lines to your own item numbers, and writing them as structured order lines into your ERP. Standard imports cover one format. With ten formats and three mailboxes you build a layer that recognizes each format and sets aside the exceptions.

A buyer at a wholesaler does not retype orders because he is dim. He retypes because supplier A's order confirmation is a PDF in German, supplier B's is an Excel with a different column order, and supplier C's is only readable if you log in to their portal and copy the lines over by hand.

That is the real problem. Not the volume of orders, but the volume of variants. Every supplier has its own idea of what an order line looks like, and your ERP only has one.

Why your ERP's standard import stops here

AFAS, Exact, and Microsoft Dynamics 365 Business Central can import orders just fine. They simply expect one fixed format: a fixed column layout, your item numbers, a clean file. That is the happy path.

The reality in wholesale is not a happy path. Your supplier sends his item number, not yours. The price on the confirmation differs from what you purchased. The lead time sits in a free-text line at the bottom of the email. An order confirmation is something different from a purchase order: you send the purchase order, the supplier sends the confirmation back, and the two have to line up (Scan Sys explains that distinction clearly).

The moment more than a handful of suppliers are in play, it falls outside what a standard import can handle. Not because the software is bad, but because the variation at the source does not fit into one import profile.

Goal: lines that are correct, not just less typing

The point is not the time retyping costs, even though that is already a waste. The point is that manual retyping pollutes your numbers.

A quantity copied wrong means a stock level that is off. A missed price change on the confirmation means your margin quietly leaks away and you only spot it at the invoice, or not at all. A lead time that stays in someone's head instead of in the system means your purchasing plan is built on air.

What you really want is control: order lines that are correct in your ERP straight away, deviations that surface the moment they arise, and a buyer who looks at exceptions instead of at every line.

First audit the process, then build

Before I build anything, I look at why those ten formats exist. Often part of them is unnecessary.

A few suppliers turn out to already support EDI, but it was never switched on because it once seemed like too much hassle. For those suppliers an EDI connection is the cleaner route: the purchase order (ORDERS) goes out structured, the confirmation (ORDRSP) comes back structured, no parsing needed. Other suppliers send three different emails for what could have been one confirmation, simply because it grew that way.

So sometimes a step can disappear or be done smarter. That is a deliberate choice, not a reason to do nothing. Because for the suppliers that have no EDI and send no clean file, and in wholesale there are always some, no off-the-shelf package solves it fully. That is where the work sits.

The smarter solution: one ingestion layer for everything

What I build is a layer that sits in front of your ERP and handles every source. Concretely:

• Emptying three mailboxes. A workflow that watches the inbox(es), pulls out attachments and free text, and recognizes the right format per supplier. For PDFs and emails with loose formatting I use AI extraction that reads out the order lines, similar to what Whitevision and Virtual Workforce offer for order confirmations, but tuned to your set of suppliers.
• Reading out portals. For suppliers that only work through their portal, an automated step that logs in there and pulls the orders instead of an employee.
• Normalizing to your numbers. A translation table that converts the supplier's item number to yours. This is exactly the step a standard import does not take and that your situation does require.
• Matching and setting aside deviations. The confirmation is linked to the open purchase order. If quantity, price, and lead time match, the line goes through. If something deviates, the line lands in quarantine with an alert, so a human only looks at the exceptions. That deviation principle is common in the market (Scan Sys describes it this way).

The result is that the buyer no longer retypes lines, but decides on the few lines that actually matter. The rest is already correct in your ERP.

Build versus buy: where the line sits

Buy standard what is standard. If you have suppliers that deliver tidy EDI or a clean fixed format, use the connection or import that already exists. You build nothing there.

The line sits at your exceptions. A standard package covers the happy path: one format, your numbers, no deviations. It does not cover the ten formats, the supplier item numbers nobody has mapped, and the cost allocation you do specifically. That is the moat. The ingestion layer that knows your variants is not a product you buy off the shelf, it is something built on your operation.