Build or buy: should you develop your own order entry agent?

The subject comes up more and more often in first meetings, and it comes from the prospect: they have built, are building or are considering building their own tool. Since spring 2026 it has become one of the first objections. The market is maturing, and the question is no longer “does it work?” but “can’t we do it ourselves?”.

What they built holds up. A manufacturer that develops all its internal tools connected a Microsoft model to its shared mailbox: it spots order PDFs and feeds them into the business system. A hardware manufacturer runs several agents on its own servers. A distributor processes its foreign subsidiary’s orders with Power Automate, and says it plainly: one sender, on a format it imposes.

All these cases have one thing in common: a flow known in advance. One format, one sender, a stable structure. That is exactly what can be automated in house. And it is exactly what email orders are not, as soon as the flow comes from dozens of different customers.

Trying AI on your own flows, training your teams on it, building small things: it has become essential, and no company should wait. But the choice of the first project matters more than the tool.

Three criteria for choosing it:

1. Tolerance for error. A wrong email draft gets reread. A wrong reference pushed into the ERP leaves on a truck. Start where an error costs a reread, not a delivery.
2. The need for stability. A language model does not answer exactly the same thing twice. A process that must give the same result every morning needs safeguards, tests and daily monitoring that nobody sets up on a first project.
3. Reversibility. If the tool stops on a Friday evening, the team must be able to take over by hand without anything being lost.

Good first projects: helping draft customer replies, sorting and labelling the mailbox, summarising meeting notes, searching your internal documents. They teach a lot, they cost little, and they are corrected by hand.

Order entry into the ERP ticks the three wrong boxes: an error is physical, the result must be stable, and a stop blocks shipments. It is built in house in one case only: one or two senders, a format you impose or that does not move, an IT team that will still be there, a stable volume. The distributor who automates its foreign subsidiary with Power Automate is exactly in that case, and says it plainly: easy to impose a format on colleagues, impossible to impose one on a key account with its own habits.

The work that costs is not reading, it is matching. On a clean document, extracting the text was solved long ago. What takes time is matching what the customer wrote to the right reference in your ERP: a commercial description, a dimension in the wrong order, an internal customer code you do not use. On the flows we process, we observe that the share of lines matched without intervention ranges from 60 to 90% depending on whether the customer writes your reference or their own description. The remaining 10 to 40% is where maintenance lives.

An in-house tool handles these cases with rules: a mapping table per customer, an exception for one format, a fix for one column that moved. Each new customer adds its own. Each ERP change at a customer breaks a few. And the day the person who wrote those rules changes jobs, nobody knows why line 212 exists any more.

A distribution group we met in spring 2026 had set up a flow of this kind with Microsoft tools. Its manager says so himself: they had “somewhat backed away from it”. Not because it did not work. Because it needed attention every day, on a subject that was not the core of his business.

The second cost is stability. A language model does not answer exactly the same thing twice, and an order process must give the same result every morning. So you need a draft mode, a confidence score per line, a validation queue for the team, tests that replay yesterday’s orders at every change, and a trace of who corrected what. Without that, a line pushed into the ERP without certainty puts the wrong product on the truck.

The third is learning. A tool that only sees your orders only learns your cases. A tool that sees thousands go by, from dozens of companies, meets every week formats, abbreviations and errors you will see once a year. That variety is what improves reading and matching, and no internal team has it.

The fourth is pace. Models change version every month, their answers move with them, and useful improvements arrive every week. Keeping an agent up to date is not a monthly task, it is a daily one, with someone who reads what comes out and measures it. It is a job, and it is rarely your IT team’s.

What the first three options have in common: you buy a reading capability, not an operating capability. And operating is what costs. An off-the-shelf order processing agent does not read any better, it carries what comes after: the matched item master, the customer who writes differently, the line waiting for validation, the correction that serves the next order.

Several of the companies mentioned above were in this situation: a flow in place, working on part of the orders, and asking for more than it gives back. The reflex is to defend the investment. The right calculation lies elsewhere.

Take stock of what the prototype revealed: the customers whose orders go through untouched, those who break everything, the formats encountered, the rules added and why. That list is your specification. An off-the-shelf agent is configured on it in days, not weeks, because the discovery work is done.

Keep what runs well, too. If your Power Automate flow processes the subsidiary without errors, there is no reason to unplug it. An order processing agent can take the rest: customers outside the format, scanned PDFs, orders in the body of the email. The two coexist, each on the flow where it is strongest.

1. How many different senders send orders? Fewer than five, in a format you choose: building holds. Dozens, each with their habits: buy.
2. Do your customers write your references or their own descriptions? Your references, in a structured file: building holds. Their words, in a PDF or an email: buy, matching is what costs.
3. Who will maintain the rules in eighteen months? An IT team in place, with time set aside for it: building holds. A contractor, an intern or nobody: buy.
4. How many new customers per month? None or almost none: building holds. Several, with their formats: buy, each customer is one more rule.
5. Is an ERP change planned, at your end or at your customers’? No: building holds. Yes, or you do not know: buy, an agent that matches by meaning survives a format change.
6. How many orders arrive outside the format each month? Fewer than two hundred: neither approach pays for itself quickly, measure first. Above four hundred, each order typed by hand costs ten minutes and the agent gives seven of them back: that is close to seventy hours of data entry a month, more than forty of them returned to the team. The question is no longer whether to automate, but how.
7. What happens when the result is wrong? A reread and a correction: building holds. A wrong product shipped, a wrong invoice, a customer delivered late: buy, and demand a draft mode, a confidence score and tests at every model change.

This grid can conclude “build”. A single-customer flow, stable, held by a team that stays, does not need an agent. It concludes “buy” as soon as customer variety becomes the problem, because no internal team exists to write one rule per customer, every month, on a subject that is not its job.

An order processing agent connects to the mailbox and to the ERP, by API or flat file, with no IT project. It reads, matches, proposes. The order desk validates what needs validating and corrects what needs correcting, and every correction serves the next orders. Your IT team, if you have one, keeps what matters to it: management rules, checks before writing to the ERP, dashboards.

This split has a virtue the binary choice lacks: it is reversible. The rules you write are yours. The list of your special cases is yours. If one day your team wants to take the engine back, it starts from a documented, measured flow, and two years of logged corrections. That is rarely the case with an in-house prototype.

If you are still hesitating, start by measuring. An export of your orders mailbox over two months tells you, within days, how many orders arrive outside the format, how many customers write their own descriptions, and how much time the team spends on them. The grid fills itself in.