Back to blog

Insights

Epicor Kinetic BAQ vs REST: when Excel exports stop being enough

How Epicor Kinetic BAQs, REST and OData, and Excel exports differ — when each path fits and how a trusted query becomes a shared live surface.

David CaldwellOctober 12, 20264 min read
LinkedInPost

Somebody already built the BAQ. It lives in the Kinetic client. A specialist runs it by hand, pastes the result into Excel, and emails the file. The data is shaped and validated — it just never became something that refreshes for everyone.

That is the gap this piece is about: when a Business Activity Query is enough, when Excel exports are still fine, and when Kinetic REST (OData) is the supported path to turn the same BAQ into a live dashboard, tablet view, or shared read, without giving every viewer a Kinetic client seat (the REST calls still run under a licensed Kinetic user).

If you are looking for the broader Kinetic picture (custom apps, MCP reads, integrations and the customization map), start with our Epicor Kinetic page.

You already have the query — it still ends in Excel#

Most Kinetic shops we talk to do not lack queries. They lack a last mile. BAQs sit in the client. Results get pasted into spreadsheets. Scheduling, quoting, and margin tracking then run off those files, and somebody keys decisions back into Kinetic.

The ERP stays the system of record. The business still runs as a system of exports. That is exactly the pattern we name on the Epicor page: BAQs nobody turned into anything, and people who still live in Excel.

The early answer: the BAQ already shaped the data. The work left is turning a hand-run query into a surface that updates for everyone who needs it.

What a BAQ is good for (and where it stops)#

A BAQ is data that has already been shaped and validated inside Kinetic. That is usually the right place to start — not a blank report, and not a direct SQL grab.

BAQs are a strong fit when:

  • One person (or a small set of specialists) opens Kinetic and runs the query on demand
  • The result is a one-off slice for analysis, not an operating loop
  • You still want Kinetic security and the BAQ definition as the single place the shape lives

They break down when:

  • The same export becomes the weekly operating view for scheduling, quoting, or margin
  • Multiple people argue over which emailed file is current
  • Decisions made in the spreadsheet get keyed back into Kinetic (re-key risk and dual truth)

A BAQ that only experts run is still useful. A BAQ that the plant depends on as a stale file is the failure mode.

REST / OData as the reuse path#

Kinetic’s REST API exposes OData v4 endpoints for business objects, processes, reports, BAQs, and Epicor Functions. That is the supported way to talk to Kinetic from outside the client — browse your instance’s own Swagger help first, and build against your configuration rather than a generic one.

In practice for reporting:

  1. Start from BAQs you already trust
  2. Expose the BAQ as a REST endpoint
  3. Publish one shared dashboard (wall screen, phone, tablet) that refreshes on its own

That is the same path we describe for live Epicor dashboards: take BAQs someone already wrote, expose them as REST endpoints, publish one dashboard everyone shares — no new client licenses, no Friday rebuild.

The same endpoints can also feed read-only assistants (for example we can build an MCP server over Kinetic REST and BAQs) so questions hit live records with the API Key plus user identity Kinetic already requires. Permissions stay inherited; they are not reinvented.

REST is not “replace the BAQ.” It is reuse the BAQ without pasting it into Excel every time.

When Excel exports are still fine#

Excel is not the enemy. It is the wrong system of work.

Exports are still fine for:

  • One-off analysis
  • An ad-hoc finance slice
  • A throwaway what-if that will not become the schedule

Name the failure mode honestly: dual truth and re-key risk when the file becomes how the team operates — backlog in one workbook, jobs in another, and Kinetic waiting for someone to type the decision back in. That is the same pattern we describe on our Epicor Kinetic page: people who still live in Excel while Kinetic holds the truth.

What we will not do#

Match the claims on the Epicor page. We will not:

  • Write directly into Epicor tables — writes go through the REST API or a Function so BPMs and validation still run
  • Bypass Epicor security — API Key plus user identity; what we build inherits that user’s permissions
  • Put heavy reporting load on the live database — heavy analysis comes off BAQs or a replica
  • Hold your data as a standing copy of production

We are independent builders, not an Epicor partner, reseller, or certified implementer — and we do not present ourselves as one.

Practical next step#

Start from the BAQs you already trust. List which ones are still hand-run exports that the business depends on. Those are the candidates for a live surface over REST/OData.

If you are not sure which ones qualify, our Epicor Kinetic page shows how we look at the BAQs, Excel and side systems around Kinetic. If you already know which BAQs deserve a live dashboard or app, book a 30-minute fit call and bring the export nobody trusts.

Want help implementing this in your business?

A 30-minute call. We'll tell you exactly what's possible.

Let's talk

Ready to build this in your business?

We'll look at your workflow and tell you exactly what's possible. No commitment.

Get in touch
LinkedInPost