Sage 100 + private AI
AI for Sage 100, Grounded in Your MAS90/200 Data
Short answer
AI on Sage 100 works by reading the underlying MAS90/200 Btrieve or SQL data (via the Sage 100 ODBC driver, Business Object framework, or the Sage 100 API for SQL-based installs) and grounding a private LLM on that schema, so an operations or office manager can ask plain-language questions about jobs, work orders, and inventory instead of building a Crystal Report or a Visual Integrator import. Because most Sage 100 shops are small to mid-size manufacturers running the SQL edition on-site or in a hosted private environment, the AI layer can sit in the same network boundary and never touch a public API. The result is a copilot that speaks MAS90 terms, item codes, and work order numbers back to the person who already knows the business, without requiring them to learn the Business Framework or hire a VAR for every new report.
- ERP
- Sage 100, Sage 100cloud, Sage 100 Manufacturing (MRP/MRM)
- Industries
- Discrete Manufacturing, Electronics, Metal Fabrication, Distribution
- Written for
- Operations Manager
Sage 100 (the product long known as MAS90 and MAS200) runs a large share of small and mid-size discrete manufacturers, often alongside the Sage 100 Manufacturing add-on (Bill of Materials, Work Order, and MRP/MRM modules) for shops that outgrew pure distribution accounting but are not ready for a full MRP-heavy ERP. These are lean back offices: a controller who also does purchasing, an operations manager who also handles customer service, and a Sage reseller (VAR) on retainer for anything beyond standard reports.
That leanness is exactly where AI has the most obvious payoff and the most obvious risk. The payoff: a shop with no in-house report writer can ask 'which work orders are short components this week' or 'summarize open sales orders for customer X' in plain English instead of waiting for the VAR's next billable hour or fighting with Crystal Reports and the Sage 100 Business Insights Explorer. The risk: most generic AI add-ons for QuickBooks-adjacent SMB accounting products assume the data can go to a cloud API, and for a manufacturer with customer-owned tooling, government subcontract data, or simply a controller who does not want financials leaving the building, that assumption does not hold.
The MAS90/200 data model rewards a grounded approach over a generic chatbot. Item Code, Bill of Materials header/detail, Work Order Header and Material/Labor detail, Sales Order and Purchase Order Header/Line, and the AR/AP/GL modules are all well-documented tables reachable through the Sage 100 ODBC driver (for the SQL edition) or the Business Object interface. A model that has actually been grounded on that schema, plus your item master and customer list, gives answers with the underlying MAS90 query attached, so the controller can check the number before it goes in front of the owner.
The honest trade-off is scope: Sage 100 Work Order and MRP/MRM are lighter-weight than a full APS or MRP engine in Infor or Epicor, so AI on Sage 100 earns its keep mostly on lookup, drafting, and exception surfacing rather than on complex finite scheduling optimization. That is still a real win for a shop whose alternative is a spreadsheet rebuilt from a Crystal Report every Monday morning.
What usually gets in the way
The problems we hear most from operations manager teams running Sage 100.
Every new question needs a new Crystal Report
Answering 'what changed on this customer's orders this month' means building or modifying a Crystal Report or Business Insights Explorer view, work that only the VAR or a rare in-house power user can do quickly.
Work order component shortages surface too late
MRP/MRM output tells you what is short, but turning that into 'which jobs are actually at risk this week and why' still means someone manually cross-referencing work orders against PO due dates.
No one person knows the whole Sage 100 schema
Btrieve-era table names and the split between standard MAS90 tables and Manufacturing module tables are documented but obscure, so ad hoc SQL against the data is a VAR task, not a same-day one.
Owner and controller are the report writers
In shops this size, the people who most need fast answers about margin, backlog, and cash are also the people with the least time to build the report that would give it to them.
Customer and quote history lives in memory, not search
Recalling how a similar job was quoted or costed last time relies on someone remembering the customer or job number, since MAS90's search tools are not built for natural-language recall.
Where AI earns its place in Sage 100
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Work order shortage and risk triage
An agent cross-references open Work Order material requirements against on-hand inventory and outstanding purchase order due dates, and flags which jobs are genuinely at risk of missing their ship date this week.
Touches: Work Order Header/Material Detail, Bill of Materials, Item Code inventory, Purchase Order Line
Outcome: Turns a Monday-morning MRP review from an hour of cross-referencing into a short flagged list to confirm.
Natural-language order and job status
Customer service or an owner asks 'what is the status of order 10452' or 'which of customer ABC's orders are past due' and gets a Sage 100-grounded answer with the source records shown.
Touches: Sales Order Header/Line, AR Invoice History, Customer Master
Outcome: Answers a routine customer call in seconds instead of a hold while someone opens Sage 100 and searches.
Quote and job history recall
Estimators ask the assistant to find prior jobs for a similar part or customer, and it pulls the closest matching Bill of Materials, routing, and historical job cost from Work Order history.
Touches: Work Order Cost history, Bill of Materials, Sales Order quote history, Item Code
Outcome: Gives estimators a starting point grounded in actual past jobs instead of re-deriving a quote from scratch.
AP invoice and PO matching assistant
The assistant matches incoming vendor invoices against open Purchase Order receipts, flags quantity or price variances, and drafts the AP entry for the clerk to approve.
Touches: Accounts Payable module, Purchase Order Receipt of Goods/Invoice, Vendor Master
Outcome: Cuts routine three-way-match time for a controller who is also doing purchasing and payroll.
Inventory and reorder point copilot
A natural-language query like 'which items are below reorder point and have no open PO' pulls directly from Inventory Management and Purchase Order data instead of a manually filtered report.
Touches: Inventory Management Item Code, Purchase Order Header, MRP/MRM planning data
Outcome: Replaces a recurring manual export-and-filter task with a direct question, run on demand.
Margin and job cost variance explanation
When a completed Work Order's actual cost diverges from estimate, the assistant summarizes which labor or material lines drove the variance, grounded in Work Order Labor/Material detail.
Touches: Work Order Labor Ticket, Material Transactions, standard vs actual cost fields
Outcome: Gives the controller a first-pass explanation instead of manually diffing estimate against actual line by line.
Month-end close drafting
The assistant drafts the narrative behind GL variance explanations and AR aging commentary from the underlying General Ledger and Accounts Receivable data, for the controller to review and finalize.
Touches: General Ledger, Accounts Receivable Aging, standard Sage 100 financial reports
Outcome: Shortens close commentary drafting from an afternoon task to a review pass for a lean finance team.
Reference architecture
Sage 100 SQL-edition installs already sit on a SQL Server database most VARs can point to directly, which makes a private AI layer straightforward to bolt on beside the application without touching Sage 100 itself: read the data through supported paths, ground a model on it, and route any write-back through Sage 100's own Business Object or Visual Integrator import, never a direct table write.
- 1
Sage 100 connectors
Sage 100 ODBC driver and the underlying SQL Server database (for SQL editions) or the Business Object/Business Framework interface for Btrieve/Provider editions, plus Visual Integrator for any approved write-back.
- 2
Data and semantic layer
A read replica or scheduled extract maps Item Code, Bill of Materials, Work Order, Sales/Purchase Order, and GL/AR/AP tables into business terms so the model reasons in job and customer language, not raw MAS90 field names.
- 3
Model serving
An open-weight model (Llama, Qwen, Mistral, or gpt-oss class) served with vLLM or Ollama on a single on-site server or a private-cloud tenant, sized for the modest concurrency a shop this size actually needs.
- 4
Retrieval and agents
Retrieval-augmented question answering over the semantic layer, plus narrowly scoped agents (shortage triage, AP matching, close drafting) that draft actions for a human to approve rather than posting directly.
- 5
Governance and audit
Every AI-suggested change is logged with the Sage 100 record it touched and the user who approved it, and the AI's own database access respects the same role boundaries as Sage 100 user security.
Integration notes for your ERP team
- SQL editions of Sage 100 expose data via a documented ODBC driver against the live SQL Server database; Btrieve/Provider editions require going through the Business Object/Business Framework interface instead.
- Visual Integrator (VI) is the supported path for any AI-suggested write-back (new PO lines, AP entries) rather than writing to tables directly, preserving Sage 100's own validation and audit trail.
- Sage 100 Manufacturing's Work Order, Bill of Materials, and MRP/MRM tables are separate from the base MAS90 tables and need their own mapping in the semantic layer.
- Business Insights Explorer and Crystal Reports report definitions are a useful starting point for the semantic layer, since they already encode which joins the VAR trusts.
- Sage 100 user security roles should gate what the AI can read and suggest per user, mirroring the same permissions a human user has inside Sage 100.
- For shops also running Sage CRM or a third-party e-commerce connector, those data sources typically need their own connector rather than assuming everything routes through Sage 100.
Deployment options
On-site private server
Shops running Sage 100 on their own server room hardware who want the AI on the same LAN.
A single GPU-equipped or CPU-inference server sits beside the existing Sage 100/SQL Server box, with no data leaving the building.
Private cloud tenant
Shops already hosting Sage 100 with a partner or on a private VPC.
The AI layer runs in the same private cloud account as the hosted Sage 100 instance, under the customer's own access controls, not a shared multi-tenant AI service.
Hybrid with the VAR's hosted environment
Shops using a Sage-certified hosting partner for Sage 100 itself.
Data replication and the model run in infrastructure the hosting partner and customer jointly control, keeping the AI layer inside the same trust boundary as the hosted application.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
Data residency
Data extraction and model inference are scoped to run entirely within the customer's own network or private cloud tenant, avoiding a public model API call for any Sage 100 record.
PCI DSS (if card data touches AR)
The AI layer is scoped to avoid any field containing stored card data, and access to AR customer records follows the same role restrictions as Sage 100 itself.
Government subcontractor data handling
For manufacturers holding DoD or federal prime subcontracts inside Sage 100 job costing, the on-prem deployment keeps CUI-adjacent job data off any third-party API, aligned to NIST SP 800-171 expectations.
Internal financial controls
AI-drafted AP matches, close commentary, and job cost variance explanations are logged and require the same approval step as a manually entered transaction, preserving segregation of duties.
Where Netray fits
ERPray
Natural-language question answering and dashboards over Sage 100 order, work order, and financial data fit ERPray's read-only, permission-aware query model directly.
Custom build
Work order shortage triage, AP matching, and close-drafting agents are typically built as scoped custom agents tailored to a specific Sage 100 install's chart of accounts and job structure.
How an engagement runs
Phase 1 . 1-2 weeks
Discovery
- -Sage 100 edition and module inventory (Manufacturing, MRP/MRM, add-ons)
- -Data access path confirmed (ODBC vs Business Object)
- -Priority use case selected with the operations or controller stakeholder
Phase 2 . 4-6 weeks
Pilot
- -Semantic layer over core tables for the pilot use case
- -Model serving stood up on-site or in private cloud
- -Pilot use case (shortage triage or order Q&A) validated against real jobs
Phase 3 . 3-5 weeks
Production
- -Role-based access aligned to Sage 100 user security
- -Write-back path through Visual Integrator for any approved actions
- -Handoff runbook for the VAR or internal admin
Phase 4 . ongoing
Scale
- -Additional use cases (AP matching, close drafting) added incrementally
- -Usage and accuracy review each quarter
- -Extension to Sage CRM or e-commerce data sources if in scope
Questions to ask any vendor, including us
A short list that separates real Sage 100 AI work from a chatbot demo.
- Does this run against our own SQL Server database, or does it require sending Sage 100 data to a vendor's cloud?
- How does the tool handle the split between base MAS90 tables and Sage 100 Manufacturing (Work Order/MRP) tables?
- What write-back path does it use: Visual Integrator, the Business Object API, or direct table writes we would need to vet with our VAR?
- Can access be scoped per Sage 100 user role, or is it all-or-nothing?
- What happens when our Sage 100 version or module configuration changes at the next upgrade?
- Is there a working example against a Btrieve/Provider edition, or does this only work on the SQL edition?
- Who owns the model weights and the semantic mapping if we end the engagement?
Frequently asked questions
Can AI work with Sage 100's older Btrieve/Provider data engine, not just SQL?
Yes, but the path differs: SQL editions expose data through a standard ODBC driver against SQL Server, while Btrieve/Provider editions require going through the Sage 100 Business Object or Business Framework interface instead of direct database access. Both are workable, but the SQL edition is materially simpler to ground an AI layer on.
Does this replace our Sage VAR?
No. A VAR still handles Sage 100 configuration, module setup, and upgrades. The AI layer sits alongside Sage 100 for question answering and drafting, and any structural change to work orders, GL setup, or security should still go through the VAR or your certified partner.
Is Sage 100 Manufacturing's MRP good enough to base AI agents on?
MRP/MRM in Sage 100 Manufacturing is lighter than a dedicated APS engine, so AI adds the most value by triaging and explaining MRP output (which shortages are actually urgent) rather than replacing the planning logic itself. For shops needing true finite scheduling, that usually means a separate APS tool feeding back into Sage 100.
How is this different from Sage's own AI features?
Sage has been adding AI-assisted features to parts of its portfolio, generally tied to its own cloud services. This approach instead grounds a private model directly on your specific Sage 100 database and modules, running in infrastructure you control, which matters for manufacturers who cannot send job cost or customer data to a third-party cloud.
What does a pilot cost for a shop our size?
For a single-site Sage 100 Manufacturing shop, a focused pilot (one or two use cases, core tables only) typically runs as a matter of weeks of engineering time rather than a multi-quarter project, since the schema is well-documented and the data volumes are modest compared to a large ERP.
Can the AI write back to Sage 100, or is it read-only?
Default deployments are read-only: the assistant answers questions and drafts suggested entries. Any write-back (a new PO line, an AP entry) goes through Sage 100's own Visual Integrator import path with a human approving it first, not a direct database write.
Does this work if we also use Sage CRM or a separate e-commerce platform?
It can, but those systems need their own connector and mapping into the semantic layer; the core Sage 100 accounting and manufacturing tables do not automatically include CRM opportunity or e-commerce order data unless that integration is built in explicitly.
Related guides
Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English
See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
ERP AI Buyer GuideHow to Choose an ERP AI Implementation Partner
A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.
ERP AI Cost GuideWhat ERP AI Actually Costs: A CFO's Guide
A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.
PO follow-up that does not wait on a personAI Purchase Order Automation: Supplier Follow-Up and Expedite Without a Buyer Chasing Email
AI drafts routine PO confirmation and expedite messages from open ERP order data, with a buyer approving every message and change before it goes out.
QAD + on-prem AIAI for QAD Adaptive ERP in automotive and industrial manufacturing
Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.
Plan it with numbers
ERP AI Copilot ROI Calculator
Turn user count, query volume, and time saved per question into a monthly savings, license cost offset, and payback period for an ERP AI copilot.
Free ToolERP Master Data AI Cleanup Estimator
Turn record count, error rate, and per-record review time into the hours and dollars saved by using AI to accelerate master data cleanup versus a fully manual review.
Free ToolOn-Prem AI ROI Calculator
Turn hours saved per employee into annual net benefit, payback months, and 3-year ROI for an on-prem AI investment.
GuideNatural Language ERP Query Interface
Query your ERP using natural language. Transform plain English questions into SQL/API calls with LLM-powered interfaces that democratize ERP data access.
GuideAP Invoice Automation in ERP: The Complete Guide
AP invoice automation in ERP explained: touchless capture, 3-way matching, approval routing, and AI agents that cut invoice processing costs by up to 80%.
GuidePreparing ERP Data for AI: A Practical Guide
Prepare ERP data for AI use: extraction patterns, schema documentation, and the data quality checks that determine whether your copilot is trustworthy.
Talk it through with an engineer who knows Sage 100
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.