Choosing Order Automation That Fits Your ERP
You are not replacing the ERP. Here is how to tell whether an order automation tool will actually work with the one you have — and what to test before signing.
Every order automation evaluation runs into the same wall. The demo is impressive. The question nobody can answer is whether it will work with the ERP you already run, which you are not replacing, and which was configured by someone who left in 2019.
That question has a real answer, and you can get to it before signing anything.
"We integrate with your ERP" means four different things
This phrase appears on every vendor site in this market, including ours. It covers a wide range of realities. Find out which one you are being offered.
- A supported API integration. The vendor writes sales orders through a documented interface and has done it before on your ERP and your version.
- A staging table or file drop. Works, but something has to move the data the last step, and that something is now yours to maintain.
- A middleware connector. Fine, unless you are now buying and running the middleware too.
- Robotic process automation — software driving your ERP's screens as if it were a person. It demos well and breaks on your next upgrade.
All four can be legitimate. Only the first one is what most buyers think they are hearing.
The version question
"We support SAP" is not an answer. SAP is a family. So is Dynamics, so is Epicor. The question is your product, your version, your deployment — and whether it is cloud or on-premise, because those are different integration projects wearing the same product name.
Ask directly: have you written a sales order into this exact configuration before, and can I speak to whoever did it? A vendor who has will say so immediately. A vendor who has not will start talking about the flexibility of their platform.
Ask about the write failing, not the write working
Every vendor will show you an order flowing into an ERP. This proves almost nothing, because the happy path is the easy path.
What you need to see is a write that fails. The customer is on credit hold. The period is closed. The item is blocked. The account does not exist yet. In each case: where does the order go, who finds out, and what do they see?
If the answer involves a log file that someone checks, you have found the shape of your next problem.
Custom fields and the things your ERP was bent into doing
Your ERP has fields nobody planned. A delivery-run code in a text field. A route number stuffed into a reference field because there was nowhere else. A convention where a certain prefix means something to the warehouse.
These are load-bearing and they are not in any vendor's data model. Get them on the table in the first technical call, not the fourth. They are usually solvable and always expensive to discover late.
What to actually test
Do not evaluate this on a demo dataset. Ask to run twenty of your own real orders — the messy ones, not the clean ones — and check three things:
- Did the lines match to your item master, including the account-specific names your customers use?
- Did your rules apply — the account's price list, minimum, cutoff, warehouse?
- When it was unsure, did it say so, or did it guess?
The third one is the whole evaluation. A tool that guesses confidently is worse than no tool, because it has your ERP's authority behind its mistakes.
For the questions to ask about the vendor rather than the ERP fit, see What to ask an order automation vendor.
Every order automation evaluation runs into the same wall. The demo is impressive. The question nobody can answer is whether it will work with the ERP you already run, which you are not replacing, and which was configured by someone who left in 2019.
That question has a real answer, and you can get to it before signing anything.
"We integrate with your ERP" means four different things
This phrase appears on every vendor site in this market, including ours. It covers a wide range of realities. Find out which one you are being offered.
- A supported API integration. The vendor writes sales orders through a documented interface and has done it before on your ERP and your version.
- A staging table or file drop. Works, but something has to move the data the last step, and that something is now yours to maintain.
- A middleware connector. Fine, unless you are now buying and running the middleware too.
- Robotic process automation — software driving your ERP's screens as if it were a person. It demos well and breaks on your next upgrade.
All four can be legitimate. Only the first one is what most buyers think they are hearing.
The version question
"We support SAP" is not an answer. SAP is a family. So is Dynamics, so is Epicor. The question is your product, your version, your deployment — and whether it is cloud or on-premise, because those are different integration projects wearing the same product name.
Ask directly: have you written a sales order into this exact configuration before, and can I speak to whoever did it? A vendor who has will say so immediately. A vendor who has not will start talking about the flexibility of their platform.
Ask about the write failing, not the write working
Every vendor will show you an order flowing into an ERP. This proves almost nothing, because the happy path is the easy path.
What you need to see is a write that fails. The customer is on credit hold. The period is closed. The item is blocked. The account does not exist yet. In each case: where does the order go, who finds out, and what do they see?
If the answer involves a log file that someone checks, you have found the shape of your next problem.
Custom fields and the things your ERP was bent into doing
Your ERP has fields nobody planned. A delivery-run code in a text field. A route number stuffed into a reference field because there was nowhere else. A convention where a certain prefix means something to the warehouse.
These are load-bearing and they are not in any vendor's data model. Get them on the table in the first technical call, not the fourth. They are usually solvable and always expensive to discover late.
What to actually test
Do not evaluate this on a demo dataset. Ask to run twenty of your own real orders — the messy ones, not the clean ones — and check three things:
- Did the lines match to your item master, including the account-specific names your customers use?
- Did your rules apply — the account's price list, minimum, cutoff, warehouse?
- When it was unsure, did it say so, or did it guess?
The third one is the whole evaluation. A tool that guesses confidently is worse than no tool, because it has your ERP's authority behind its mistakes.
For the questions to ask about the vendor rather than the ERP fit, see What to ask an order automation vendor.