Epicor Power BI Integration Services
Most plants running Epicor still answer the Monday questions — what shipped late, which jobs ran over, how much inventory is sitting still — by exporting a dashboard grid to Excel and reshaping it by hand. We connect Epicor to one Power BI model so those answers refresh on their own and agree across production, sales and finance.
Epicor Power BI integration services start with one decision: how the data leaves Epicor. Business Activity Queries (BAQs) are the native way to shape Epicor data, and the Kinetic REST API can publish a BAQ as an OData feed that Power BI reads directly. On-premises installations also have the SQL Server database underneath, and a warehouse can sit in between when history or a second system matters.
The route sets how fresh the numbers are, how far back a trend can reach, how well the reports survive the next Kinetic update, and how much you own afterwards. We settle it before any report is designed. If the question is still whether Power BI is worth it for your plant at all, start with Power BI for small manufacturers; for the general engagement, see Power BI consulting services.
How does Epicor data get into Power BI?
Three routes work. A Business Activity Query (BAQ) published through the Epicor Kinetic REST API can be read by Power BI as an OData feed. On-premises installations can also query the SQL Server database directly through a gateway. Or a warehouse lands Epicor data on a schedule and keeps the history the ERP does not.
The BAQ and OData route is usually the shortest path to a first report set, because the queries live in Epicor and use the access Epicor already controls. Calls to the REST API are authenticated, and an API key is set up in Epicor for the integration, so the connection belongs to a named service account rather than to one person's login.
Direct SQL is only an option where you host the database yourself, and it means writing queries against Epicor's internal tables. A warehouse — Azure SQL or Microsoft Fabric, for example — is the answer when you need month-end inventory snapshots, years of trend, or Epicor combined with another ERP, CRM or spreadsheet the business still runs on.
- BAQ via REST API / OData: native to Epicor, permission-aware, quickest to stand up
- Direct SQL Server: on-premises only, fast for large loads, tied to internal table names
- Warehouse intermediary: full history and multi-source models, more setup, scheduled loads
| Route | Best for | Trade-off |
|---|---|---|
| BAQ via Kinetic REST API (OData) | Operational reports on data Epicor already shapes and secures | Large history loads are slow to page through an API |
| Direct SQL Server query | On-premises installations with heavy history loads | Queries depend on internal table names and need re-checking after updates |
| Warehouse intermediary | Snapshots, years of trend, Epicor plus other systems | More setup and a scheduled load to maintain |
Why build the model on BAQs rather than raw tables?
A BAQ is a query defined and secured inside Epicor, so it respects company and user permissions and usually survives upgrades better than SQL written against internal table names. Raw tables are faster for large history loads, but every join has to be rebuilt by hand and re-checked after each Kinetic update.
In practice most models use both kinds of source: BAQs for the operational facts people check daily, and a scheduled extract for the heavy history that would be slow to page through an API. Each BAQ the model depends on is named, documented and kept in a short list, so whoever maintains Epicor knows which queries a report set relies on before changing one.
What do manufacturers and distributors report on first?
Usually the reports someone already rebuilds in Excel each week: on-time delivery, open orders and backlog, job cost against estimate, inventory value and turns, scrap and labor efficiency by work center. The first model rebuilds those from one set of Epicor facts, so production, sales and finance stop arguing about whose number is right.
The model is a star schema rather than a copy of a dashboard grid: sales order lines, shipments, job transactions, labor and part transactions as facts; parts, customers, suppliers, sites, work centers and a fiscal calendar as shared dimensions. Measures such as gross margin or on-time percentage are defined once, and every report uses that definition. For distribution-heavy businesses, the same pattern covers fill rate and slow-moving stock — see Power BI for wholesale distributors.
- On-time delivery and backlog by customer, part and promise date
- Job cost: estimated versus actual material, labor and burden, by job and part
- Inventory value, turns and slow movers by site and warehouse
- Labor efficiency and scrap by work center and shift
- Sales and margin by customer, product group and salesperson, with drill-through to the order
What does an Epicor Power BI project cost?
Epicor projects are quoted per engagement, after a scoping call. The price depends on the route, how many companies and sites are in the Epicor database, how much history you need, and how many existing BAQs and spreadsheets the model replaces. Those vary too much between manufacturers for a list price to be honest.
If you already have someone who maintains Epicor reports and want senior Power BI help in blocks rather than a fixed project, Power BI Flex Support starts at $2,500 for 20 hours, at $100–$125 per hour, in prepaid blocks whose hours do not expire.
Every engagement is run remotely by Edward Pinela, MBA, Principal Consultant at Lightray Solutions. The person who scopes the integration is the person who builds the model, so nothing is lost between the conversation with operations and the technical work. If your ERP is NetSuite rather than Epicor, the same approach is on NetSuite Power BI integration services.
Further reading: Microsoft Learn — the OData feed connector in Power Query.
Not sure if this is the right fit?
Book a free 30-minute call with Edward Pinela, MBA. If it is not the right fit, you will be told that on the call.
Frequently asked questions
Does Power BI have a native Epicor connector?
Power BI does not include a dedicated Epicor connector. The usual route is Power BI's built-in OData feed connector reading BAQs that the Epicor Kinetic REST API publishes. On-premises installations can also use the SQL Server connector through a gateway, and third-party drivers exist. We confirm what your Epicor version and hosting allow before recommending a route.
Does this work with Epicor Kinetic in the cloud?
Yes. A cloud-hosted Epicor tenant is reached through the REST API rather than the database, so the model is built on BAQs published as OData feeds, or on scheduled extracts landed in a warehouse. Direct SQL access is the one route that generally depends on hosting the database yourself.
Will a Kinetic update break the reports?
Reports built on BAQs are the least exposed, because the query is maintained inside Epicor and its output columns stay stable unless someone changes the BAQ. Reports written against raw tables are more likely to need attention after an update. Either way, we document which sources each report depends on so they can be checked after an upgrade.
Can we keep Epicor's own dashboards alongside Power BI?
Yes. Epicor dashboards stay useful for working lists inside the ERP, and nothing in the integration removes them. What moves into Power BI is recurring management reporting — the weekly operations review, job cost and inventory analysis — along with anything that needs data from outside Epicor in the same view.
Talk it through with a senior consultant
Book a free 30-minute call with Edward Pinela, MBA. No obligation and no sales pitch — just an honest read on whether this is the right fit.
Prefer to call? +1 (714) 872-9606