Generic Inquiries out, a real model in
Exposing a Generic Inquiry as an OData feed is the easy half. Making it refresh reliably at volume — and turning a flat inquiry result into a model where the ledger, receivables, and inventory agree — is the project. A senior US-based engineer does both, then hands it over.
Representative dashboard — sample data
Where the native path runs out
Almost every Acumatica Power BI dashboard starts the same way: someone builds a Generic Inquiry, ticks the box that exposes it via OData, points Power BI's OData feed connector at it, and sees rows. That part genuinely works. What breaks is everything after it — the refresh that ran in ninety seconds against last month now runs against four years of ledger detail, the inquiry comes back a page at a time, and the report that was fine on Friday quietly returns a partial dataset on Monday.
So we start at the connection, not the canvas. We agree the access route with your Acumatica administrator, replace one wide inquiry with narrow purpose-built ones, land the records into a store you own, and refresh only what changed. Then the general ledger, receivables, and inventory get modeled into a star schema instead of five unrelated flat tables — which is the difference between a report that answers one question and a model that answers the next one too.
What we build from Acumatica
Buy a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. We scope each task and quote the hours before work starts, hours deduct only for work you approve, and your banked hours never expire.
Why these builds stall
None of them is a visual problem. All of them are extraction or modeling problems, and all of them produce a number that looks plausible and is wrong — which is worse than a report that obviously fails.
An OData feed is not a stored extract. Each refresh re-executes the Generic Inquiry on your ERP server, with its joins and conditions, and pages the result back to Power BI. Refresh cost is therefore paid in Acumatica CPU, and it competes with the people actually using the system.
Inquiries carry their own record limits, feeds are paged, and licence tiers cap concurrent API requests. Stack six of those into one scheduled refresh over several years of history and you meet Power BI's refresh time limit — or worse, a truncated result that nobody notices for a month.
A Generic Inquiry flattens joins into one denormalized grid. Build a report per inquiry and every measure gets rewritten in each file, filters cannot cross subject areas, and nobody can put receivables next to inventory. A star schema fixes that once for every future question.
Acumatica posts to financial periods on a calendar you control, including adjustment periods that carry no ordinary dates. Group a general ledger fact by a plain date column and your year-end will not tie to the statements finance signed off — a difference that only surfaces at close.
A Generic Inquiry is an editable artifact. Someone adds a column, renames one, or tightens a condition to fix their own screen, and the report bound to it breaks or silently narrows. We build reporting inquiries that are owned, named, and documented as reporting objects, not borrowed from an operational screen.
Through whichever route your deployment supports: Generic Inquiries exposed as OData feeds, the contract-based REST API for record-level reads, or a read-only replica of the SQL database where you host the instance yourself. We land the records into a store you own, model them, and refresh on a schedule — the report never queries your ERP live.
The Generic Inquiry route is the one most teams already know. You design the inquiry in Acumatica, expose it via OData, and Power BI reads it with the standard OData feed connector (opens in new tab) under a dedicated Acumatica user. It is supported, it respects your security, and for a few thousand rows it is genuinely the right answer. Its limits are structural rather than a defect: the feed is a live query, so the ERP does the work on every refresh, and one wide inquiry that joins orders to shipments to invoices to items is exactly the shape that turns a refresh into an outage risk.
The contract-based REST API is the better fit when you need specific records rather than an inquiry's grid — and because its endpoints are versioned, a build against a named endpoint version is not silently reshaped by an upgrade. Where you run Acumatica on your own infrastructure or a private cloud, a read-only database replica is usually available, and it is the cheapest route for long history: full SQL access, real incremental keys, and no pressure on the application layer. On multi-tenant SaaS that option normally does not exist, which is why the inquiry and API routes carry most of our Acumatica work.
Downstream, the pattern is the same whichever route we take. We land a copy, run it incrementally so each refresh moves only changed rows — Microsoft's incremental refresh reference (opens in new tab) explains how the partitioning works — and let Power BI query the modeled copy. That keeps every run inside the documented ceilings in Microsoft's data refresh reference (opens in new tab), which caps both how often a dataset may refresh and how long a single refresh may run. Where the source sits inside your own network, an on-premises data gateway (opens in new tab) carries the connection; we configure it, document it, and fix breakages out of your banked hours.
This is the honest comparison behind the scope estimate you approve before any hours are spent. We confirm the route with your Acumatica administrator first, because the wrong assumption here is what turns a five-day build into a five-week one.
| Route out of Acumatica | Best for | Tradeoff |
|---|---|---|
| Generic Inquiry exposed as an OData feed | Modest, well-scoped result sets; teams that already maintain reporting inquiries | Re-runs on the ERP each refresh; paged results and inquiry record limits bite as history grows |
| Contract-based REST API (versioned endpoint) | Record-level reads and anything that must survive an upgrade unchanged | More engineering than a feed; needs a service account and request pacing |
| Narrow inquiries plus incremental staging | SaaS tenants with years of ledger, invoice, or inventory history | Adds a staging store — which is what makes the refresh survivable |
| Read-only SQL replica | Private-cloud and on-premises instances; long history at low cost | Not offered on multi-tenant SaaS; needs DBA cooperation and a gateway |
| Landed copy modeled as a star schema | Every production build, on top of whichever route above applies | Adds a modeling layer — which is the point, not a cost |
Every view below maps to records your tenant already holds. The data access classes named are Acumatica's standard ones; your version, your modules, and any custom fields your team or VAR has added change the detail, so we confirm the mapping against your own instance before quoting the work.
| Dashboard area | Acumatica records it reads | Question it answers |
|---|---|---|
| General ledger & statements | Posted ledger transactions (GLTran) against the account and subaccount masters, keyed to the financial calendar |
What did each branch and subaccount actually post, period by period? |
| AR aging & collections | Customer documents and their detail (ARInvoice, ARTran) with the applications and adjustments that settle them |
What is genuinely open, how old is it, and who owns the oldest balances? |
| AP & cash commitments | Vendor bills, adjustments, and payment records against the vendor master | What is due in the next 30 days, and against which branch? |
| Inventory & stock valuation | Stock item master with per-warehouse quantities (InventoryItem, INSiteStatus) and inventory transaction history (INTran) |
What do we hold by warehouse, what is aging, and what is short against demand? |
| Sales orders & fulfillment | Sales order headers and lines (SOOrder, SOLine) with shipments and the resulting invoices |
What is on order, what shipped late, and where is revenue still sitting unbilled? |
| Item & customer margin | Invoiced revenue joined to item cost, respecting each item's valuation method | Which items and accounts are actually earning once cost is attached? |
The same handful, on nearly every engagement. None is exotic, and each one is cheap to handle at modeling time and expensive to discover after finance has quoted a number from the dashboard in a board meeting.
It turns several flat inquiry results into one governed semantic model: fact tables at a declared grain for ledger postings, receivable documents, inventory movements, and order lines, surrounded by conformed dimensions for financial period, branch, account and subaccount, customer, item, and warehouse.
That structure is what lets a single filter move across subject areas — pick a branch and a period, and revenue, receivables, and stock all respond together, because they share the same dimensions rather than each carrying their own copy of the date. It is also what makes the measures reusable: gross margin, days sales outstanding, and inventory turns get defined once and agree everywhere they appear. If you want the reasoning in full, our guide to star schema modeling in Power BI walks through why a wide table underperforms, and the broader discipline is described on our Power BI data modeling and DAX page.
Distributors, manufacturers, construction firms, and services businesses running Acumatica Cloud ERP — usually where a controller or operations leader is rebuilding the same workbook every month. You buy prepaid Flex hours that never expire: Starter 20 hours at $125/hour ($2,500), Growth 40 hours at $115/hour ($4,600), or Power 80 hours at $100/hour ($8,000), with rates from $100/hour on the largest block.
Because we scope each task and quote the hours before any work begins, you agree the cost of a build up front rather than watching a meter run. The usual pattern is a Growth or Power block: the extraction route, the model, and the first pages are front-loaded, and the remaining hours go to extra views, measure changes, and refresh care over the following months. Most individual tasks ship in 3–5 business days after approval; a first full ERP build is larger and gets a clear timeline up front. There is no project minimum and no retainer — the mechanics are on how prepaid Flex hours work. Distributors will recognise most of the reporting on our Power BI for wholesale distributors page, and teams comparing mid-market ERPs can see the equivalent build on NetSuite Power BI dashboards or, for an open-source stack where the extraction runs through the external API instead of Generic Inquiries, our Odoo Power BI dashboard page.
Everything. The Power BI file, the semantic model and DAX, the reporting inquiries and extraction logic, the staging store, the refresh schedule, and the service account all live in your tenant and your Acumatica instance. There is no black box, no licence to us, and no lock-in — if you never send another request, the dashboards keep running.
We publish to your workspace, document the access route and every record we pull, and walk your team through the model so someone internal can maintain it. Most clients then keep a few banked hours for what follows: a page for a newly opened branch, a measure that has to track a changed costing rule, or a refresh that broke when credentials rotated after an upgrade. That is post-launch support without a retainer — the same hours, spent when you need them. Contact is form-only: send your request and we reply with a scope estimate.
business days, typical
hours, never expire
own everything
Extraction, modeling, DAX and refresh care all draw from the same banked hours. See Flex pricing →
How it works
Tell us your Acumatica version, whether you run SaaS or host it yourself, how many branches and companies you report on, and the views you need first. We check what your administrator can actually open up, then reply with a scope and an hours estimate before any work begins.
A senior US-based engineer builds the reporting inquiries or API reads, lands the records incrementally, shapes the star schema on period, branch, account, customer, item and warehouse, and writes the DAX — then ties every total back to the Acumatica reports finance already trusts.
We publish to your workspace, configure the gateway and scheduled refresh, apply row-level security by branch or company where you need it, document everything, and hand it over. You own it outright; we keep the refresh healthy from your banked hours.
Representative perspective
Our inquiry-based report had been quietly returning short for weeks and nobody caught it. Landing the data first and refreshing incrementally was less glamorous than the redesign, and it was the entire fix.Controller, mid-market distributor
Representative perspective
Three branches, one shared customer list, and a consolidated margin number finance would not stand behind. Making branch a real key in the model mattered more than anything that ended up on the screen.Finance director, multi-entity services group
Tell us your deployment, your branch structure, and the views you need first. We'll confirm what your instance can give us, scope the task and quote the hours before any work begins — drawn from prepaid Flex hours that never expire, with no project minimums.
FAQ
Usually through Generic Inquiries you expose as OData feeds, which Power BI reads with its OData feed connector under a dedicated Acumatica user. Where record-level access suits the job better, we use the contract-based REST API instead. On private-cloud and on-premises instances, a read-only database replica is often available and is the cheapest route for long history.
Because an OData feed re-runs the Generic Inquiry on your ERP server every time Power BI asks for it. A wide inquiry over several years of ledger detail is paged back a chunk at a time, so the pull is slow, it competes with users, and it can hit both the inquiry's own record limits and Power BI's refresh time limit before it finishes.
Yes, and most of our Acumatica work is exactly that. Without a database we build narrow, purpose-shaped Generic Inquiries and REST reads instead of one wide inquiry, land the results into a staging store you own, and refresh incrementally so each run moves only changed rows rather than re-reading the whole history.
Yes, and they usually get better. Acumatica inquiries and dashboards are excellent for operational, in-context questions on live records. Power BI takes the same data further: trended history, general ledger next to inventory and receivables in one model, and cross-branch reporting that does not need someone to run six inquiries and reconcile them.
No. We are an independent, US-based Power BI practice and claim no Acumatica or Microsoft partnership. Our engineers are Microsoft-certified, and we build only with documented, supported tooling: the access route your Acumatica administrator approves, plus Power BI's published connectors, gateway, and incremental refresh features.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.