OEE-to-Epicor integration succeeds when three things are true: the integration pattern matches your Epicor version (Kinetic vs ERP 10 vs older), the data flow is event-driven not poll-based, and the work order lifecycle is the integration spine (not the production schedule or the BOM). The most common failure mode is treating Epicor as a passive data source and the OEE platform as the active consumer; the platforms that succeed treat the work order as a shared object owned jointly. This guide walks through supported endpoints, three working data flow patterns, common pitfalls we see in field deployments, and a 6-week implementation plan executable with your existing IT team plus the OEE vendor's integration consultant.
This guide is part of a series covering the OEE plateau diagnosis, turning maintenance into a profit center, and competitor reviews of TrakSYS, FORCAM FORCE, and AVEVA.
Quick answer: Integrating OEE software with Epicor Kinetic ERP requires three connection points: (1) production order pull from Epicor into the OEE platform, (2) downtime + scrap + good-count push back into Epicor work-order labor and material reporting, (3) reason-code dictionary synced so Pareto charts in the OEE tool match Epicor variance reports. Fabrico's native Epicor connector covers all three with a 30-second sync; Zapier-based middleware introduces minute-level lag that destroys real-time supervisor workflows.
Related deep-dives: OEE + Infor integration · OEE software selection process · Closing the OEE-CMMS loop · OEE software hidden-cost checklist.
Epicor's two production-relevant product lines have meaningfully different integration surfaces. Epicor Kinetic (introduced in the 2021 refresh, dominant in new deployments) exposes a modern REST API surface plus Epicor Functions for event-driven workflows. Epicor ERP 10 (the legacy line, still in service at thousands of plants) exposes Business Objects via the older soap-style API plus BAQ exports and DMT-style imports. Each line requires a different integration approach; assuming "Epicor support" means the same thing for both is the most common scoping error.
For Kinetic: the JobEntry REST endpoint (work order create/update), the LaborDtl endpoint (operator time entry posting), the PartTran endpoint (production reporting), and the Epicor Function framework for custom event handlers. For ERP 10: JobEntry.JobEntryBO, LaborEntry.LaborEntryBO, and PartTran.PartTranBO as Business Objects accessed via SOAP. For both: a read-only feed from JobOper for current production-order operations.
The single most useful object in either Epicor version is the Job Head + Job Operations record. This is what the OEE platform attaches OEE measurements to. When the OEE platform measures a 15-minute unplanned stop on Line 3, the platform attributes that stop to the active JobOper running on Line 3 at the time. Without this attribution, OEE data is just numbers; with it, OEE data drives the work order analytics that the production planner already cares about.
Trying to integrate at the customer-order or sales-order level. The sales order is too abstract for OEE; OEE lives at the work order and operation level. Attempts to connect at the higher level produce confusing analytics that nobody trusts.
Attempting to mirror the BOM into the OEE platform. Some integration consultants suggest replicating Epicor's bill of materials into the OEE side for "complete context." This is over-scoping. The OEE platform needs the BOM at the product-line level (which it can fetch on demand), not as a replicated data store.
Trying to write back labor time to Epicor from the OEE platform. This sounds attractive (auto-log operator time from OEE machine running data) and is a regulatory minefield in plants subject to labor reporting requirements. Keep labor reporting in Epicor; let OEE report machine time separately.
Epicor REST API calls require API key authentication; Kinetic also supports OAuth 2.0 with Epicor IdP. The OEE platform should run under a dedicated service account with read access to Job, Operations, and Part tables, and write access only to the specific tables the integration designs writes to (typically nothing, in a clean architecture). Plants that hand the OEE platform admin-level Epicor credentials are creating an attack surface and a regulatory headache; resist the convenience temptation.
Before sizing the integration project, answer four questions in writing: (1) which Epicor version (Kinetic, ERP 10, or earlier) is in production? (2) how many Epicor company codes / sites need integration? (3) is the OEE platform a SaaS instance (which needs Epicor to be reachable from the internet via API gateway) or on-premise? (4) which integration pattern (event-driven Functions, REST polling fallback, file-based DMT) is acceptable to the Epicor admin? These four answers determine whether the integration is a 6-week project or a 14-week project.
Four working sessions: (1) Epicor admin walks the OEE vendor consultant through the active integration surfaces and limitations; (2) Plant operations sponsor confirms the work-order lifecycle and the operations data model; (3) IT security signs off on authentication approach and network paths; (4) the joint team selects one of the three data flow patterns based on Epicor version and IT constraints. End-of-week deliverable: a 2-page architecture document signed by Epicor admin, OEE vendor lead, and IT security.
Stand up a non-production Epicor company code or test environment. Configure the service account with read permissions to the scoped tables. Confirm the OEE vendor can reach Epicor REST endpoints from the integration host. Run a test "Job creation event → OEE acknowledgement" round-trip with mock data. By end of week 2, the integration plumbing is connected even if no real production data flows yet.
For Pattern 1: Epicor admin writes the Functions or Method Directives that fire on Job state transitions. For Pattern 2: OEE vendor writes the polling code with rate-limiting and circuit-breaker logic. For Pattern 3: OEE vendor builds the daily CSV export with DMT-compatible format. Week 3 is the largest chunk of vendor-side engineering effort regardless of pattern.
Pick a single production line, ideally the one with the cleanest work-order flow. Enable the integration only for that line's work center. Run live for 1 week alongside the existing OEE measurement method (Excel or whatever was in place). Compare results daily. By end of week 4, the integration is producing OEE-attributed-to-Epicor-work-order data on one line that matches expected results within tolerance.
Extend the integration scope from one line to all production lines in scope. Most issues at this stage are not integration logic — they are data hygiene (work orders missing operation routings, work centers not mapped consistently across plants, operators not signed in to Epicor). Spend most of week 5 in data hygiene, not in code. The integration logic that worked for line 1 will work for the rest, given clean data.
Switch over from the old measurement method to the integrated OEE platform. Configure monitoring on the integration: alert on broken events, dropped events, ambiguous bindings, and authentication failures. Hand the integration over to internal IT for ongoing care. Document the runbook for common operational scenarios (Epicor maintenance windows, OEE vendor SaaS downtime, network changes). Sign off the integration acceptance with both the Epicor admin and the plant operations sponsor.
Weeks 7-12 are the normal OEE measurement period during which the integration's value emerges. By week 12, the plant should have 4-6 weeks of OEE-attributed-to-work-order data that the production planner uses to schedule, the maintenance manager uses to plan PM windows, and the plant manager uses to brief the corporate team. This is the value the integration was set up to deliver, and it scales linearly with the cleanliness of the integration plumbing established in weeks 1-6.
Three failure modes. First, plants that try to scope the integration without an Epicor-side resource budgeted produce week-1 architecture documents that are aspirational rather than executable. Second, plants that try Pattern 1 without Functions experience (Kinetic specifically) end up reverting to Pattern 2 in week 3, costing 2 weeks of rework. Third, plants that skip the data hygiene work in week 5 find that the integration "works on line 1 but breaks on line 4" — a data problem, not a code problem, but expensive to discover at the wrong moment.
The work-order-driven event flow is the strongest pattern for OEE plus Epicor integration. The pattern: Epicor emits an event when a work order is started, paused, or completed; the OEE platform receives the event and binds incoming production data (machine state, units produced, micro-stops) to the active operation. When the work order closes, the OEE platform sends back a final summary record with: total units produced, OEE breakdown by component (availability, performance, quality), and the dominant loss categories during that operation.
In Kinetic, this is implemented via Epicor Functions that fire on Job state transitions. In ERP 10, it requires custom Method Directives on JobEntry.Update and JobEntry.MasterUpdate. Both are well-trodden Epicor patterns; any experienced Epicor admin can wire this in 2-3 days.
For plants that cannot enable Epicor Functions or Method Directives (often due to corporate IT restrictions), the fallback is a production-schedule-driven pull. The OEE platform reads the active JobOper records every 5 minutes via REST API, identifies which operation is running on which work center, and binds OEE measurements accordingly. The pattern works but produces 5-minute resolution rather than real-time, and creates load on the Epicor database.
Mitigate the load by limiting the pull to operations with status "In Process" or "Setup", not all operations. Most plants have 10-30 active operations at any time; pulling all 5,000 work orders every 5 minutes is a database stress signal that the Epicor DBA will flag.
For plants that cannot or will not enable Epicor-side integration at all, the OEE platform can run as a pure machine-side measurement system with periodic file-based reconciliation. The OEE platform reads PLC and CV data, computes OEE per machine, and exports a daily CSV that gets imported to Epicor via DMT. The work order context is established at month-end reconciliation, not in real time.
This pattern produces OEE measurement but does not unlock OEE-driven work order analytics. It is acceptable as a phase-1 deployment in plants with strict Epicor change-management policies, with the explicit roadmap to upgrade to Pattern 1 or 2 in phase 2.
Minimal viable fields: Job number, Job suffix (for split jobs), Operation number, Part number, Quantity ordered, Quantity completed, Operation status, Work center / resource, Start datetime, End datetime, Operator ID (if labor entry is connected). Most OEE platforms read these via a single JobOper view in 5-15 seconds; the integration overhead is small if scoped right.
If your architecture writes back: total parts produced (PartTran), labor minutes (LaborDtl), and OEE summary metrics (in a custom UD field on JobOper). If your architecture does not write back: OEE summary metrics are published to a Power BI or analytics view in a separate location, and Epicor users read them via the analytics portal rather than the Epicor UI.
Before go-live, run six tests: (1) Job creation event triggers OEE side acknowledgement; (2) Job state transition (Started → Paused → Started) preserves OEE measurement continuity; (3) Job closure sends back a summary record matching expected scope; (4) Bad-data scenarios (no JobOper found, ambiguous work center binding, network drop) fail gracefully with logged errors; (5) Multi-plant scenarios route to the correct OEE plant scope; (6) Permission failures fall back cleanly without locking Epicor up.
Most established enterprise OEE platforms have at least Pattern 2 (polling) integration capability for Epicor. TrakSYS by Parsec, FORCAM FORCE, and Fabrico CMMS + CV OEE all support Epicor integration via documented patterns. The depth and cleanliness of the integration varies; ask each vendor for a reference customer running their integration in production for at least 12 months.
Kinetic Cloud is the recommended target for new Epicor integration in 2026. The REST API surface is the same as on-premise Kinetic but accessed via Epicor's public cloud endpoint. Authentication uses OAuth 2.0 with Epicor's IdP. The OEE platform's integration host needs internet egress; if your OEE platform is also SaaS, the integration is cloud-to-cloud and easier to deploy than mixed cloud-on-premise architectures.
SAP PM uses OData and IDoc patterns; Microsoft Dynamics 365 uses Business Events and Common Data Service. The architectural principles in this guide (work-order-driven event flow, dedicated service account, event-driven over polling) apply to all three. The specific endpoints and authentication patterns differ, but a vendor that has integrated cleanly with Epicor typically has the engineering muscle to integrate cleanly with SAP PM and Dynamics 365 as well.
Epicor MES (the legacy shop-floor module) overlaps with what an OEE platform does, which creates a strategic decision: replace Epicor MES with the new OEE platform, or run both in parallel with clear scope boundaries. Plants that run both find the overlap confusing for operators and expensive to maintain; plants that replace Epicor MES typically migrate within 6 months of OEE platform go-live. The migration is a separate project from the initial integration.
Run a separate integration instance per company code, or use the Epicor cross-company reporting layer (if licensed). The first approach is simpler and faster; the second approach is preferable if corporate engineering wants centralised reporting. Either way, do not try to "consolidate" multiple company codes into a single OEE platform tenant without explicit per-plant scoping — the data hygiene burden becomes unmanageable.
For Pattern 1 (event-driven) on a single-company Kinetic environment, expect €30k-€80k in vendor integration fees plus 80-150 hours of internal Epicor admin time. Pattern 2 (polling) is somewhat cheaper, €20k-€60k vendor plus 50-100 hours internal. Pattern 3 (file-based) is the cheapest at €15k-€40k vendor plus 30-60 hours internal, but produces the weakest analytics. For multi-company or ERP 10, expect 1.5-2x these ranges.
OEE plus Epicor integration succeeds with the work-order-driven event flow pattern, Epicor admin involvement from week 1, and a clean architecture that treats the work order as a shared object. Implementation is a 6-week project with a dedicated Epicor-side resource, 10-14 weeks without. Scope honestly against your Epicor version, run a one-line pilot in week 4, spend week 5 on data hygiene, and hand over to internal IT in week 6. The value emerges in weeks 7-12 as OEE-attributed work order analytics start driving real production planning and maintenance decisions.
Login
Blog
