Should you build your own order automation tool or buy an existing solution?
· Arno Heckel
Building in-house makes sense when your order flow is small and uniform, or when a strong technical team can look after the tool for the long term. In other cases, the cost is not the prototype, which today’s AI models make quick to put together, but everything that comes after: matching against the catalogue, edge cases, writing to the ERP, the review interface and keeping up with the models. To decide, compare both options on your hardest orders, not your easiest ones.
Why the question comes up now
A few years ago, automating purchase order reading was a heavy project. Today, a developer can send a PDF to a language model and get back, in an afternoon, a structured file with the customer, the item codes and the quantities. On ten hand-picked orders, the result is often impressive.
That is real progress, and it is natural for an IT department to wonder why it should pay a subscription for something that seems to fit in a few hundred lines of code. The honest answer is that sometimes it is right.
When building in-house makes sense
A small, very uniform flow. If most of your orders come from three or four large customers who always send the same Excel file, using your own item codes, you do not need AI. An import script, or even your ERP’s built-in import function, will do the job.
A team that already knows your data and will stay. If you have developers who have maintained your ERP integrations for years, who know your catalogue and your rules, and who will have time for this in the long run, the project is feasible.
Order taking that is part of your competitive edge. This is the case for some manufacturers whose orders are really custom technical configurations. The tool then becomes part of your core business, and keeping it in-house makes sense.
A prototype to learn. Even if you end up choosing an existing solution, a few weeks of prototyping help you understand your own flows and spell out your requirements. That is not wasted time, as long as nobody mistakes the prototype for a production tool.
What an in-house tool really costs
Reading an order is only the first step. Here is what you discover when you move from the ten orders in the demo to the hundreds of the following month.
The catalogue. Extracting “ref 4020 × 10” is easy. Knowing which item it is, much less so: the customer uses their own codes, an old reference, the manufacturer’s code, or just a description such as “grey 20 mm flexible conduit, 100 m coil”. You need cross-reference tables, and someone to keep them up to date whenever an item is created, replaced or discontinued. We go into this in our article on matching customer references to your catalogue.
Edge cases. They never stop. One customer orders by the carton when you sell by the unit (see unit of measure conversion). Another sends a “cancel and replace” without saying what has changed. A third splits an order across two emails, or sends the same one twice. There are negotiated prices that do not match the price list, site delivery addresses, requested delivery dates written at the bottom of the page, crooked scans, and orders typed in the email body between two signature blocks. Each case becomes a rule, then a test. And the person who knows these cases works in sales admin, not in development: the project lives on constant back-and-forth between the two.
The ERP connector. Creating an order properly is not a matter of inserting rows into a table. You need the right customer code, the right delivery address, the pricing conditions, the right document type, sometimes stock reservation and sending the acknowledgement. Integration options vary by ERP and version, an upgrade can break what used to work, and you have to decide what happens when the ERP rejects an order.
The review interface. For the team to trust the tool, they need to see what was read, what is questionable and why, correct a line and validate. You also need to know who validated what. That is a full application in its own right, and it is often left out of the initial estimate.
AI model changes. Model providers release new versions and retire old ones on their own schedule. A new version may read a quantity column or a date differently. So you need a set of real orders with their expected results, rerun it at every change, compare and fix. The cost per document changes too. This work does not stop once the tool is in production.
Monitoring and dependence on one person. An order that is not processed means a customer who is not delivered. You need to be alerted when something fails, even silently. And if the developer who built the tool leaves the company, what remains is often a black box nobody dares to touch.
Time. During the months of development, the sales admin team keeps entering everything by hand, and the IT team is not working on anything else.
A simple way to decide
Rather than comparing quotes, run a concrete test.
- Gather around fifty real orders, deliberately choosing the awkward ones: scans, badly formatted Excel files, customer references, orders in the email body.
- For each option, check how many are handled correctly end to end, up to the order created in the ERP, not just read.
- Then ask the long-term questions. Who updates the cross-references when the catalogue changes? Who is alerted when an order is not processed? Who retests when the model changes? What happens if the key person leaves?
If the answers hold up in-house, with names and time set aside, building may be the right choice. If not, the existing solution almost always wins. To run this test with Eledone, you can start with the online trial on one of your orders.
Buying does not stop you building around it
The two options are not mutually exclusive. With Eledone, the entry and control rules are defined with you during setup, and can be refined for each of your customers or products. Eledone has native connectors for Sage 100, Sage X3, Microsoft Dynamics 365 and Odoo, and also integrates with Cegid, Divalto, NetSuite, Sylob, Proginov, SAP, Infor M3, Exact Online and Oracle through a custom integration. The IT team keeps a key role: ERP access, company-specific rules, internal dashboards.
Data, often put forward as a reason to build in-house, also deserves a concrete look. At Eledone, each customer’s environment is independent and hosted in the European Union, you can choose the AI model used, and the knowledge system built from your data can be hosted on your own servers.
Frequently asked questions
Our business rules are very specific: can an existing tool follow them?
That is exactly what to check on your own orders. At Eledone, every project starts with an observation phase covering your teams, your ERP and your mailboxes, to work out the rules. Specific rules can then be added per customer or per product.
Can we start with an in-house prototype and switch approach later?
Yes, and the prototype is not wasted. It will have shown you where your real difficulties lie. Keep the test orders you gathered: they will be useful for evaluating any solution.
How long does it take to set up an existing solution?
It depends on the ERP and on how varied your orders are. As an example, MP Hygiène integrated Eledone in two weeks, and the tool was able to handle all the orders its customers sent by email.
What happens to our IT team?
They no longer have to maintain extraction, cross-references or AI model monitoring. They remain essential, however, for ERP access, security and company-specific rules.
Want to compare on your own orders, including the hardest ones?
Book a demo