Disclosure: del.ai sells NetSuite-to-Odoo migrations and has a commercial interest in the agent-readiness argument in this piece. Treat it as something to verify on a call, not take on faith.
If you're evaluating ERP for manufacturing this year, most of the guides you'll find were written before AI agents were something a vendor had to answer for. They still walk you through production planning, cost accounting, and integration risk, and none of that has gone away. What's changed is that your board is now asking a question those older checklists never had to answer. Can an AI agent do anything useful and safe inside this system, or does the platform block it before it starts? This piece runs both lists, the five categories every serious ERP evaluation for a manufacturer still has to cover, and the sixth one most 2020s buying guides haven't caught up to yet.
ERP for manufacturing is the system that puts production planning, inventory, and financials on one system of record, instead of a shop-floor spreadsheet, a separate inventory tool, and an accounting package that reconcile to each other by hand at month-end. That's the plain definition, and it's held steady for two decades. What hasn't held steady is the checklist buyers use to evaluate it.
Most public buying guides for ERP systems for the manufacturing industry are still running a 2015-era checklist: does it handle bills of materials, does it do multi-entity consolidation, does it integrate with your existing tools. Those questions are still worth asking, and the next section walks through them properly. But a checklist written for a pre-AI decade has a blind spot a 2026 buyer can't afford: it never asks whether the system you're about to commit to for the next several years can be safely operated by an AI agent at all, let alone whether the platform is designed to handle what happens when one gets something wrong.
This piece covers both. The baseline five categories any competent ERP evaluation still has to check, because skipping them is how a migration goes sideways regardless of what AI story a vendor tells. Then a sixth criterion most 2020s guides haven't added yet: whether the platform's architecture lets an AI agent act on it safely, and what that requires from the vendor before you sign anything.
Evaluate an ERP system for the manufacturing industry against five established categories: production planning and MRP (bills of materials, work orders and routings on one ledger with inventory), cost accounting and work-in-process tracking, financial consolidation across entities, integration and data-migration risk, and the vendor's implementation track record. Each category has a specific failure mode. Weak MRP means production planning lives in spreadsheets next to the ERP instead of inside it. Weak costing means work-in-process valuation drifts and shows up as an unexplained variance two closes later. Weak consolidation means month-end takes days longer than it should once a second entity or currency enters the picture. A vendor's implementation history matters because manufacturing migrations carry more reconciliation surface than a simple distribution cutover. A sixth category belongs on the list now too: whether an AI agent can safely act on the system at all, which the next section covers directly.
Source: del.ai ERP evaluation methodology, synthesized from public NetSuite and Odoo documentation, 2026
| Category | What "good" looks like | Where the depth lives |
|---|---|---|
| Production planning / MRP | BOMs, work orders and routings on the same ledger as your stock | Production planning |
| Cost accounting & WIP | Production-run costing landing in the ledger and analytic accounts, including runs still open at period end | Manufacturing costing |
| Financial consolidation | Multi-entity, multi-currency close with no manual reconciliation layer bolted on | — |
| Integration & data-migration risk | Every downstream system inherits whatever data quality the migration itself achieved | — |
| Implementation track record | A vendor's history predicts how your specific cutover goes, not just what the demo shows | — |
On production planning, the promise worth checking is straightforward: bills of materials, work orders and routings on the same ledger as your stock, so a shop-floor change and an inventory count are never fighting two different sources of truth. What that promise leaves out matters just as much. Finite-capacity scheduling and advanced production-optimization sit outside it; if your evaluation depends on a system that automatically balances machine capacity against a production schedule, confirm that in writing with any vendor rather than assume MRP covers it.
On cost accounting, look for production-run costing: components, machine time and whatever else went into the run landing in the ledger and the analytic accounts, including for runs still open at period end. For the deeper mechanics of WIP and standard-versus-actual costing, the companion piece on manufacturing cost accounting covers that ground properly; this piece doesn't re-walk it.
Financial consolidation is usually where multi-entity manufacturers hit friction first. Check whether a second entity or currency adds a manual reconciliation step to every close, or whether the system absorbs it natively. Integration and data-migration risk decides how the first 90 days go, since every connected system inherits whatever data quality the migration achieved, so it deserves as much diligence as the feature list. Implementation track record is the hardest category to check because every vendor's reference calls are ones the vendor selected. Ask for the failure mode, not just the win, and ask what happens contractually when a checkpoint is missed.
If open-source ownership of the MRP logic itself, not just the feature list, is the specific question you're weighing, the deeper piece on that argument covers it in full. If you're comparing specifically against SAP on cost and depth, that comparison is the narrower resource.
Here's the criterion a 2015-era checklist never had reason to include. Your board is increasingly asking finance leaders to show AI return from the budget that already exists, not a new line item. That pressure lands squarely on whatever system of record the business runs on. That pressure doesn't stay abstract for long. A CFO who reports flat AI ROI to the board two quarters running gets asked why. "The system won't let the agent touch the data it needs" is a harder answer to give than a wrong number would be.
An AI agent can only do real work on a system it can safely read from and write to. That's true regardless of which model sits behind the agent or which vendor built it. A closed, rented system limits what any AI agent, from any vendor, can be given access to, because the vendor decides what the API surface exposes and what it hides.
This applies to any ERP evaluation, not just a decision about whether to leave NetSuite specifically. Whatever system you're comparing against, the same question belongs on the checklist. When an agent needs to read across production, inventory and the ledger at once to do something useful, does the platform's architecture let that happen? Or does it stop at whatever the vendor chose to surface through an API?
It's tempting to treat this as a generic AI-governance point any consulting firm could make, and mostly it is. What makes the mechanism specific rather than generic is this: any implementation partner can promise to build governance in at migration time, on any ERP, closed ones included. What they cannot promise is an owned, inspectable schema for an agent to act against, because that property comes from the substrate underneath the promise, not from the methodology layered on top of it. Real agent permissioning is only possible when the target schema is open and owned by the customer rather than rented from a closed vendor. That's the practical difference between migrating onto Odoo Community, licensed LGPLv3, and staying on a closed schema you don't control.
That's the deeper argument about who owns the logic that runs your operation, and it deserves more room than one section here. The full case for MRP ownership specifically makes it properly; this section only needed the one line connecting it to agent-readiness.
Ask an ERP vendor four concrete questions before trusting an AI agent to touch the system. First, does the platform expose a schema or API surface an agent can act on, or only a read-only reporting layer that blocks any real write? Second, are there permission tiers by action class, separating read, write, schema-modify and money-move, or is access all-or-nothing once an agent is connected? Third, is there an immutable audit trail with per-step rollback, so a bad agent action can be traced and undone rather than manually unwound? Fourth, who is accountable when an agent makes an error: is that answered in the contract before signing, or improvised after something breaks? A vendor with vague answers to these four questions is telling you governance was never designed in, whatever their sales deck claims about AI readiness.
Source: del.ai AI governance methodology, del.ai, 2026
| Question to ask | What the answer reveals |
|---|---|
| Does the system expose a schema or API surface an agent can act on, or only a reporting layer? | Whether an agent can do anything beyond summarizing what already happened |
| Are there permission tiers by action class (read / write / schema-modify / money-move)? | Whether one agent mistake can reach the general ledger, or is contained by design |
| Is there an immutable audit trail with rollback? | Whether a bad action can be traced and undone, or has to be manually unwound |
| Who is accountable when an agent errs? | Whether that answer sits in the contract, or gets improvised after something breaks |
On the migrations del.ai is built to run, these questions have a specific answer, stated here in the tense it deserves: this is design intent, not an installed base to point at yet. Action-class permission gates and an immutable audit trail are scoped in at migration time, for qualifying migrations within the signed scope document, rather than bolted on after go-live as a separate project. That's a commitment about how the engagement is structured, and like every other claim in this piece, it's one to verify on a call rather than take as delivered.
The number on a cloud ERP quote is rarely the number you actually pay over five years. That's true across vendors, but it's easiest to show with the stack most manufacturers on NetSuite are already carrying. License is one line among several: implementation and partner retainer, add-on modules and SuiteApps, BI and ETL tooling to get data out in usable form, and the internal headcount needed to administer all of it.
| Cost layer | Annual range |
|---|---|
| License | $30,000–$50,000 |
| Implementation partner retainer | $30,000–$100,000 |
| Add-on modules / SuiteApps | $20,000–$50,000 |
| BI / ETL tooling | $30,000–$80,000 |
| Internal admin headcount | $100,000–$400,000 |
Layered together, a mid-market NetSuite stack runs $210,000 to $680,000 a year. That's not the license fee alone. It's the license plus the four layers underneath it, all in the same year, each moving independently.
None of these ranges are meant to be summed into some new figure beyond what's already shown above; read each layer as a separate line that either applies to your stack or doesn't, and check it against your own contract rather than take any vendor's aggregate on faith. This section stays deliberately vendor-neutral. The point isn't that del.ai is cheaper than everything; it's that the sticker price was never the number worth comparing on in the first place.
If an ERP vendor's manufacturing roadmap stalls, or the vendor is acquired, sold or shut down, what protects you is decided before you sign, not after. Ask three questions during evaluation. Can you export your full dataset in a standard, non-proprietary format at any time, or does the contract leave that vague? What do the exit terms actually say about data access after termination, and is that written into the contract or only implied in a sales conversation? Is the platform's core open-source or closed? An open-source-licensed core, such as Odoo Community under LGPLv3, lets you self-host or move to a different provider regardless of what happens to any single vendor. A closed core ties your continuity to that vendor's survival instead. Then estimate what a forced switch would cost in dollars and months under each scenario, because that number is the real measure of the risk, not the vendor's roadmap slide.
Source: Odoo S.A., "Licenses," Odoo 18.0 documentation, 2026, Community LGPLv3, Enterprise proprietary and subscription-bound. ↗
Two fears usually asked separately are the same question pointed in opposite directions: what happens if you need to leave, and what happens if you need to change. Both come down to what you locked in at signing, not what a demo showed you.
Before signing anything, ask about data portability and export format, not after a renewal has already gone sideways. A standard, non-proprietary export format is the difference between switching providers in a matter of weeks and rebuilding your ERP from scratch. Ask what a forced vendor switch would cost in dollars and months, and get that answer in writing rather than trusting a sales estimate.
An open-source-licensed core changes the shape of this risk structurally rather than contractually. Odoo Community, licensed LGPLv3, means a customer can export and self-host, or move to a different Odoo provider, regardless of what happens to any single vendor's business. That's a property of the license itself, not a policy any vendor could quietly change later. Odoo Enterprise is a separate, proprietary tier and isn't part of what del.ai runs; the license property described here applies to the Community core specifically.
The forward-looking version of the same question: if you want to try something new in six months, a new workflow, a new integration, does that require a vendor statement of work, or can your own team ship it. That answer predicts the cost of every future change for the life of the contract, which is why it's worth asking before the first change, not after.
Route yourself from here based on what you're deciding. If open-source ownership of the MRP logic is the specific question, not just a line in a checklist, the deeper piece on that argument is the fuller read. If you're comparing specifically against SAP on cost and depth, that comparison is the narrower resource. If you're already deep in the mechanics of work-in-process and standard costing, the companion piece on manufacturing cost accounting covers that ground directly.
This checklist, all six categories, applies whatever ERP you're currently running, NetSuite or otherwise. The call below is not for everyone reading this. It's built for finance leaders currently on NetSuite spending $120,000 or more a year, at companies roughly 50 to 500 employees, who want this exact checklist walked against their own setup, not a generic pitch. If that isn't you, the six categories above still apply to whatever evaluation you're running; the call just isn't for you, and it's more useful to both of us if you self-select out here rather than on a call.
30 minutes, no pitch. We walk your actual production and cost setup against every criterion above, agent-readiness included, and tell you plainly where it holds up and where it doesn't.
Sources
1. Odoo S.A., "Licenses," Odoo 18.0 documentation, 2026, Community LGPLv3, Enterprise proprietary and subscription-bound. ↗