# AI for Epicor Eclipse, Without Sending Distributor Data Off-Site > Source: https://netray.co/erp-ai/epicor-eclipse-ai-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Adding AI to Epicor Eclipse means grounding a private, on-prem model on your Eclipse SQL Server database (order entry, item master, rebates, warehouse) so counter staff, sales, and finance can ask questions in plain English and get answers with the underlying query shown. It works alongside your existing Eclipse reporting and EDI setup and runs on hardware you control, so pricing, rebate agreements, and customer data never leave your network. ## Kind platform ## Erp Family epicor ## Erp Products - Epicor Eclipse ## Industries - Distribution - Electrical - Plumbing - HVAC - PVF ## Region Global ## Persona Operations Manager ## Eyebrow Epicor Eclipse + private AI ## Intro Epicor Eclipse runs the back office for thousands of electrical, plumbing, HVAC, and PVF distributors, and it does the job well: order entry, purchasing, warehouse management, rebates and chargebacks, and counter sales all live in one system built around how distribution actually works. The gap is not functionality. It is that answering an ad hoc question, whether it is a will-call counter clerk checking a substitute item or a branch manager asking why margin dropped on a product line, still means someone navigating Eclipse screens or waiting on a report from IT. That gap gets worse as branch count grows. A regional distributor with a dozen locations has a handful of people who really know how to pull a rebate report, reconcile a vendor chargeback claim, or explain a price matrix override, and everyone else routes questions to them. When those people are out, the business slows down. Meanwhile counter and inside sales turnover means new hires spend months learning item cross-references and substitute logic that live only in tribal knowledge and Eclipse screens. A private AI layer on top of Eclipse changes that without changing Eclipse. It reads from your existing database (typically a read-only replica so it never competes with production transactions), understands your item master, price matrices, rebate agreements, and warehouse structure, and lets any authorized employee ask a question in plain English. The model shows the query it ran, so answers are checkable rather than a black box, and it respects the same role-based access your Eclipse users already have. This page covers what that looks like in practice: the specific pain points Eclipse shops run into, seven concrete use cases with the Eclipse objects they touch, the deployment architecture, and the honest trade-offs between running this on-prem, in a private cloud, or hybrid. ## Pain Points ### Rebate and chargeback reconciliation is a spreadsheet exercise **Detail:** Vendor rebate agreements and chargeback claims live partly in Eclipse and partly in spreadsheets. Reconciling actual purchase volumes against agreement tiers at quarter close is manual, slow, and error-prone, and the people who know how to do it correctly are few. ### Counter and will-call staff can't get a fast answer **Detail:** A customer on the phone asking about stock, a substitute item, or a customer-specific price forces counter staff to flip between item master, price matrix, and inventory screens. Every extra second on hold is a customer experience problem. ### Ad hoc reporting waits on IT or a consultant **Detail:** Eclipse Data Analytics and the report writer answer known, recurring questions well. A new question from a branch manager, such as slow-movers by category this quarter, usually means a ticket and a multi-day wait. ### New hires take months to learn item cross-references **Detail:** Electrical, plumbing, and PVF distributors carry tens of thousands of SKUs with vendor-specific part numbers, substitutes, and customer-specific pricing. Ramping a new counter or inside sales rep on that knowledge takes far longer than the business would like. ### EDI and vendor punch-out exceptions pile up **Detail:** Routine EDI mismatches (a PO acknowledgment that does not match, an ASN discrepancy) sit in a queue that only one or two power users know how to triage, so exception handling becomes a bottleneck rather than a routine task. ## Use Cases ### Natural-language order and inventory lookup for counter and inside sales **Description:** Counter and inside sales staff ask questions like which branches have a part in stock, what the customer's contract price is, or what the standard substitute is, and get an answer sourced directly from Eclipse. **Erp Objects:** Order entry, item master, warehouse/bin inventory, will-call queue, cross-reference tables **Outcome:** Counter staff resolve availability and substitute questions in seconds instead of putting a caller on hold to check three screens. ### Rebate and chargeback reconciliation copilot **Description:** An agent cross-references vendor rebate agreement terms against actual purchase volumes and chargeback claims, flagging discrepancies and drafting the reconciliation worksheet for review. **Erp Objects:** Vendor rebate agreements, purchase history, chargeback claims, vendor invoices **Outcome:** Cuts manual rebate-claim prep from days to hours each quarter close. ### Price matrix and contract pricing explainer **Description:** Sales reps and CSRs ask why a price landed where it did and get a plain-English breakdown of the matrix tier, contract override, or promotion that applied, with the underlying record shown. **Erp Objects:** Price matrices, customer contract pricing, cost book, promotions **Outcome:** Reps get an instant, auditable explanation instead of escalating pricing questions to a manager. ### EDI and vendor punch-out exception triage agent **Description:** Routine EDI order acknowledgment and ASN mismatches get summarized and, where the fix is standard, drafted for one-click approval rather than sitting untouched in a shared inbox. **Erp Objects:** EDI order/ASN/invoice transaction queues, vendor punch-out catalogs, PO matching records **Outcome:** Routine EDI mismatches get resolved same-day instead of aging in a queue only one person knows how to work. ### Warehouse and RF exception assistant **Description:** Warehouse staff get plain-English help resolving cycle count discrepancies, putaway exceptions, and short-pick situations without paging a supervisor for every mismatch. **Erp Objects:** Warehouse management, bin locations, cycle count records, pick/pack transactions **Outcome:** Faster exception handling on the floor with fewer supervisor interruptions. ### Branch performance and slow-mover reporting **Description:** Branch managers ask for a slow-mover list, an inventory turns comparison, or a margin trend by product line in plain English instead of waiting on a monthly report cycle. **Erp Objects:** Sales history, inventory turns, branch profitability extracts **Outcome:** Branch managers get answers on demand instead of waiting for the next scheduled report. ### New-hire onboarding assistant for item cross-references **Description:** New counter and inside sales staff ask the assistant questions about item cross-references, substitutes, and vendor part numbers while they learn the catalog, rather than interrupting a senior colleague. **Erp Objects:** Item master, cross-reference tables, vendor catalogs **Outcome:** Cuts ramp time for counter and inside sales hires learning thousands of SKUs and substitutes. ## Architecture **Overview:** The architecture sits beside Eclipse rather than inside it: a read-only data layer keeps production order entry untouched, a semantic layer translates Eclipse's database structure into business terms (rebate, price matrix, will-call), and the model itself runs on hardware inside your network, whether that is a server room at headquarters or a private cloud instance you control. **Layers:** #### Eclipse data connector **Detail:** Read-only connection to a replicated copy of the Eclipse SQL Server database, refreshed on a schedule that fits your reporting cadence, so nothing touches live order entry transactions. #### Semantic and data layer **Detail:** Maps Eclipse tables, item cross-references, rebate agreements, and warehouse structures into business terms so the model reasons about rebates and price matrices, not raw column names. #### Model serving **Detail:** An open-weight model (Llama, Qwen, Mistral, or gpt-oss class) served with vLLM or Ollama on GPU hardware you own or control, sized for your branch count and concurrent user load. #### Retrieval and agents **Detail:** Retrieval-augmented generation grounds every answer in current Eclipse data and, for the rebate and EDI use cases, agents draft a recommendation with a human review step before anything writes back. #### Governance and audit **Detail:** Access mirrors your Eclipse security groups so a counter clerk and a controller see different answers to the same question, and every query and response is logged for audit. ## Deployment Options ### Air-gapped on-prem **Fit:** Distributors whose IT already runs Eclipse on local SQL Server hardware and want the AI layer on the same footprint **Detail:** Model, retrieval layer, and data connector all run on servers in your own data center or server room, with no external network dependency for day-to-day use. ### Private or sovereign cloud **Fit:** Multi-branch distributors that already run Eclipse infrastructure in a private or hosted cloud environment **Detail:** The same architecture runs in a single-tenant cloud environment you control, useful when branches are geographically spread and a central private cloud is easier to operate than per-site hardware. ### Hybrid **Fit:** Distributors piloting AI at one branch or division before a company-wide rollout **Detail:** Start with a replicated data feed from one branch or division, prove the rebate reconciliation or counter lookup use case, then extend the same architecture to additional branches. ## Compliance ### Card payment data at the counter stays entirely outside the AI layer's scope; the connector reads order, item, and rebate data only, never payment card fields. **Framework:** PCI DSS ### Rebate terms are commercially sensitive; keeping the model and data on-prem or in a private cloud means those agreements never transit a third-party AI vendor. **Framework:** Vendor rebate agreement confidentiality ### The retrieval layer preserves the underlying Eclipse records behind every answer, so a tax audit can trace any AI-assisted summary back to source transactions. **Framework:** State and local sales tax audit trails ### AI access mirrors existing Eclipse security groups rather than introducing a separate permission model, so a rebate answer available to finance is not available to a counter clerk. **Framework:** Role-based access control ## Integration Notes Connects to a replicated, read-only copy of the Eclipse SQL Server database rather than the live transactional instance, so query load never competes with order entry. Rebate agreement terms and chargeback claim data are typically the messiest part of the integration; expect a data-mapping pass before the reconciliation use case is reliable. EDI exception triage reads from the EDI translator's transaction log or staging tables alongside Eclipse PO and ASN records to explain a mismatch in context. Item cross-reference and substitute logic often lives partly in Eclipse and partly in vendor catalogs or spreadsheets maintained outside the system; those sources get folded into the semantic layer. A service account with least-privilege, read-only access covers the great majority of use cases; only the rebate and EDI drafting agents need a narrowly scoped write path, and only with human approval. Warehouse and RF use cases benefit from a near-real-time feed (minutes, not overnight) since cycle count and pick exceptions are time-sensitive. Existing Eclipse Data Analytics dashboards are not replaced; the AI layer answers the ad hoc questions those dashboards were never built to cover. ## Product Fit ### ERPray **Why:** Fits the counter lookup, pricing explainer, and branch reporting use cases directly: grounded natural-language question answering over live Eclipse data, with the query shown. ### Custom build **Why:** The rebate reconciliation and EDI exception agents need purpose-built logic tied to your specific vendor agreements and EDI trading partner setup, which goes beyond a generic Q&A layer. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of Eclipse database structure, rebate agreement sources, and EDI queue setup - Prioritized use case list scored by branch impact and data readiness - Data access and replication plan that does not touch production Eclipse - Draft architecture sized to branch count and concurrent users ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working natural-language lookup over item master, inventory, and pricing at one or two branches - Rebate reconciliation copilot tested against a real quarter close - Access control mapped to existing Eclipse security groups - Usage and accuracy review with branch and finance staff ### Production **Duration:** 4-6 weeks **Deliverables:** - Company-wide rollout across all branches - EDI exception triage agent live with human approval step - Audit logging and query review process in place - Training materials for counter, inside sales, and finance staff ### Scale **Duration:** Ongoing **Deliverables:** - Additional agents for warehouse exceptions and slow-mover reporting - Expanded model coverage as new question types are observed - Quarterly review of rebate and EDI agent accuracy against manual audits - Capacity planning as branch count or user load grows ## Buyer Questions - Where does the model actually run, and does any distributor data leave our network at any point? - Does the AI layer read from a replica or the live production database, and what is the refresh cadence? - How are rebate agreement terms and chargeback claims kept confidential from a third-party AI vendor? - What happens when the model is wrong about a price or a rebate figure? Is the underlying Eclipse record always shown? - How does access control map to our existing Eclipse security groups, so a counter clerk cannot see finance-only data? - Can we pilot at one branch before committing to a company-wide rollout? - What is the total cost, including GPU hardware or private cloud, not just a software license? - Who owns the model and the integration code if we ever want to bring it in-house or switch vendors? ## Faq ### Can AI work with Epicor Eclipse without Epicor building it themselves? **Answer:** Yes. Eclipse's SQL Server database can be read on a replicated, read-only basis, which is enough to ground a private AI layer without needing a native Epicor AI feature. This approach works today, independent of Epicor's own product roadmap, and keeps the data and the model under your control. ### Does this replace Eclipse Data Analytics or the report writer? **Answer:** No. Eclipse Data Analytics and the report writer remain the right tools for recurring, scheduled reports. The AI layer covers the ad hoc questions those tools were never built to answer quickly, such as a one-off slow-mover list or a rebate reconciliation check. ### How does this help with vendor rebate reconciliation specifically? **Answer:** The agent cross-references rebate agreement tiers against actual purchase volumes pulled from Eclipse and flags discrepancies before quarter close, drafting a reconciliation worksheet for a human to review. It does not replace the finance team's judgment, but it removes the manual line-by-line matching that eats days at close. ### Is on-prem AI overkill for a mid-size distributor? **Answer:** It depends on branch count and data sensitivity. A single-branch distributor may find a lighter, hosted private-cloud setup sufficient, while a multi-branch regional distributor with meaningful vendor rebate and customer contract data usually finds the control and predictable running cost of on-prem or private cloud worth the investment. ### What does the pilot actually prove before we commit further? **Answer:** A well-run pilot demonstrates accurate natural-language answers over live item, inventory, and pricing data at one or two branches, and a working rebate reconciliation pass against a real quarter close, so you can judge accuracy and time savings with real numbers before a company-wide rollout. ### Can counter staff use this without IT involvement for every question? **Answer:** Yes, that is the point. Once deployed, counter and inside sales staff ask questions directly through a chat interface without filing a ticket. IT stays involved for new agent types, access control changes, and periodic accuracy review, not for every day-to-day question. ### How long before this pays for itself? **Answer:** Most distributors see the clearest early payback in rebate reconciliation time savings and reduced EDI exception handling, both measurable within the first full quarter close after go-live. Counter and onboarding time savings compound over a longer horizon as new hires ramp faster. ## Search terms Epicor Eclipse AI, Epicor Eclipse AI integration, on-prem AI for Epicor Eclipse, Epicor Eclipse copilot, Epicor Eclipse generative AI, AI for distribution ERP, Eclipse rebate automation AI, Eclipse EDI AI agent, Epicor Eclipse natural language query, private AI for distributors, Eclipse counter sales AI assistant, Epicor Eclipse chatbot, AI for electrical distributors ERP, Epicor Eclipse reporting AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json