# How to Add AI to Sage 100 and Sage 300 On-Prem > Source: https://netray.co/erp-help/private-ai-layer-sage-100-300-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Sage 100 and Sage 300 differ underneath, so the access path differs. Sage 300 runs on SQL Server and offers a REST Web API and a views API. Sage 100 exposes ODBC and COM Business Object Interface, with SQL Server only in Advanced and Premium. Either way, extract to a read-only copy, run a local model, and write back only through supported APIs. ## Kind advanced ## System sage ## Erp Sage 100 and Sage 300 (on-prem) ## Module AI integration / Private architecture ## Query how to add AI to Sage 100 or Sage 300 on-premises ## Alternate Queries - Sage 100 AI integration without cloud - Sage 300 private LLM on-prem - chat with Sage 100 data ODBC - Sage 300 Web API AI assistant ## Applies To Sage 100 (Standard, Advanced, Premium) and Sage 300 on-premises. The Sage 300 Web API requires a release that includes it; check your product update level. ## Steps ### Add a private AI layer to Sage 100 or Sage 300 in seven steps **Items:** - Confirm the product and back end: Sage 100 Standard uses ProvideX files read through ODBC, while Sage 100 Advanced and Premium and Sage 300 use SQL Server. - Create a read-only data path: for Sage 300, a SQL Server secondary or replica; for Sage 100 Standard, a scheduled ODBC extract into a reporting database, run off hours. - Define a small set of views over the tables the assistant needs, with descriptions of each column in plain language. - For single-record lookups, use the Sage 300 Web API or Sage 100 Business Object Interface under a user whose rights match the asker. - Index documents and attachments, such as customer contracts, item data sheets and scanned supplier invoices, with their permissions. - Run an open-weight model on a local GPU with vLLM or Ollama and a gateway that logs everything. - Roll out read-only questions first, then drafts, then approved actions through the supported APIs. ## Sections ### Data access paths: Sage 100 versus Sage 300 **Body:** Sage 300 stores data in SQL Server with short module-prefixed table names: ARCUS (customers), APVEN (vendors), ICITEM (items), ICILOC (item by location), OEORDH and OEORDD (order headers and details), POPORH (purchase order headers). Sage 300 also ships a Web API: REST endpoints of the form /Sage300WebApi/v1.0/-/COMPANY/OE/OEOrders, and a views-based programmatic API for custom code. Sage 100 uses table names such as CI_Item, IM_ItemWarehouse, AR_Customer, SO_SalesOrderHeader, SO_SalesOrderDetail, PO_PurchaseOrderHeader and AP_Vendor. Sage 100 Standard keeps them in ProvideX files read through the SOTAMAS90 ODBC driver, which is slow for heavy queries and best used for scheduled extracts. Advanced and Premium use SQL Server. The Business Object Interface exposes COM objects such as SO_SalesOrder_bus for validated reads and writes. Both products have user-defined fields; include them in your view definitions and descriptions or the assistant will not know they exist. **Code:** - -- Sage 300 (SQL Server): open order lines, verify column names SELECT TOP 50 h.ORDNUMBER, h.CUSTOMER, d.ITEM, d.QTYORDERED FROM OEORDH h JOIN OEORDD d ON d.ORDUNIQ = h.ORDUNIQ WHERE h.CUSTOMER = '1200'; - -- Sage 100 via ODBC (SOTAMAS90): verify column names SELECT ItemCode, WarehouseCode, QuantityOnHand FROM IM_ItemWarehouse WHERE WarehouseCode = '000'; - GET /Sage300WebApi/v1.0/-/SAMINC/OE/OEOrders?$top=10 Authorization: Basic ### Reference architecture, including air-gapped **Body:** Keep the ERP server as the system of record and place a reporting database beside it. For Sage 300, a SQL Server readable secondary, log shipping or scheduled backup restore works. For Sage 100 Standard, a nightly or hourly ODBC extract into SQL Server or PostgreSQL is simpler than live ODBC queries from an assistant, because ProvideX file access does not scale to concurrent analytic load. The tool server offers named read tools over the reporting copy and a few record-level calls to the Web API or BOI. The model server runs vLLM or Ollama on local GPUs; retrieval runs over documents; the gateway writes the audit log. In an air-gapped site, deliver model weights and packages on media, keep the reporting database and index inside the enclave, and remove outbound routes. Both Sage products already run happily without internet. ### Permissions and write-back **Body:** Sage 300 uses security groups with per-module rights; Sage 100 uses roles with task-level permissions and optional restrictions by warehouse or division. On a reporting copy those rights are lost, so rebuild the important ones as filters: map the asking user to their role, and apply allowed warehouses, divisions or companies to every tool call. For writes, use the Sage 300 Web API or views, or the Sage 100 BOI, so validation, numbering and posting logic run. The assistant drafts a payload, shows it, and submits after a named approver confirms. Direct SQL or ODBC updates are not acceptable, since they bypass the application logic and can corrupt sub-ledgers. ### Sizing and phased rollout **Body:** Sage 100 and 300 sites are often smaller: 20 to 250 named users. One data center or workstation-class GPU can serve a 7B to 14B class model for that load, with a second for resilience if the assistant becomes business critical. Document indexes of a few thousand to tens of thousands of documents are small. Phase 1: read-only questions on customers, items, open orders and balances. Phase 2: drafts such as collection emails, reorder suggestions and quote text. Phase 3: approved actions through the Web API or BOI, limited to transactions with low risk and easy reversal. ### Honest limits **Body:** For small teams, built-in inquiry screens, Crystal or Sage reports and Excel with ODBC may answer most needs; add AI where questions cross tables or involve documents. Sage 100 Standard on ProvideX is the hardest case: concurrent heavy ODBC reads can slow the live system, so an extract is mandatory. Web API and BOI coverage varies by module and version. Heavily modified installations with custom tables or scripts need extra mapping, and numeric totals should come from SQL, not from model arithmetic. ## Pitfalls - Pointing an assistant at live ProvideX files over ODBC during business hours. - Forgetting user-defined fields, so the model cannot see custom data. - Losing role, warehouse and division restrictions when moving to a reporting copy. - Writing with direct SQL or ODBC updates instead of the Web API or BOI. - Mixing up Sage 100 and Sage 300 table names in prompts or descriptions. - Assuming the Web API exists on an older Sage 300 release without checking. ## Ai Angle ERPray can sit over a reporting copy of Sage data, show the query behind every answer, and run on your own hardware. Where a bespoke setup is needed, such as a Sage 100 extract pipeline or approval workflow, Netray builds it with your Sage partner. ## Faq ### Can I use AI with Sage 100 Standard? **Answer:** Yes, but schedule an ODBC extract into a reporting database instead of querying live ProvideX files. Then run the model and retrieval against the copy, and use the Business Object Interface only for approved writes. ### Does Sage 300 have an API for AI tools? **Answer:** Sage 300 provides a REST Web API in recent releases and a views-based programmatic API. For bulk reads, a SQL Server replica is still usually better. Check your release before you design around the Web API. ### Do I need a GPU for a small Sage site? **Answer:** For a 7B to 14B class model and 20 to 100 users, one modest data center or high-memory workstation GPU can be enough. Test with your own prompts, since context length drives memory use. ### How do I keep Sage permissions in the assistant? **Answer:** Map each user to their Sage role or security group and apply the allowed warehouses, divisions or companies as filters on every query. For record-level reads, call the API under their identity. ## Search terms Sage 100 AI integration, Sage 300 AI integration, Sage 300 Web API AI, Sage 100 ODBC AI assistant, Sage 100 BOI, chat with Sage 100 data, Sage 300 private LLM, Sage on-premises AI assistant --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json