Dynamics GP to Power BI, done for you
We connect Power BI straight to the Great Plains databases on your SQL Server, rebuild the ledger, sales, purchasing and AR/AP reporting you currently pull out of SmartList, and quote the whole build in hours before we start. Senior-led, US-based, most builds in 3–5 business days.
Representative dashboard — sample data
The usual situation
Great Plains has been running the business for years and the numbers in it are trusted. Getting them out is the problem: someone re-runs the same SmartList favourites each month, pastes them into a workbook, and the workbook becomes the report. It is accurate on the day it is built and stale by the time anyone acts on it.
Because GP is on-premises, the fix is unusually direct. Every posted transaction already sits in a SQL Server database you own, on hardware you control, with no API quota and no vendor sitting between you and your data. We read those tables, build a proper model on top of them, and let the report refresh itself.
Reports we build from GP
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. Hours are deducted only for work you've reviewed and approved, there's no project minimum, and your banked hours never expire.
Why teams pick us
You send the request; a senior engineer models your GP tables, validates the totals against the ledger, and keeps the refresh running.
No connector quota, no middleware, no nightly export job to babysit. A read-only login against your GP company databases and, where the report lives in the cloud, an on-premises data gateway. That is the whole data path.
GP's table names are cryptic and its documentation assumes you already know them. We work in GL, SOP, POP, RM and PM directly, including the open-versus-history split that trips up most first attempts at a GP report.
Every recurring SmartList that someone re-runs and re-pivots becomes a page that refreshes on a schedule. The logic moves out of one person's workbook and into a documented model your whole team can open.
GP puts each entity in its own database. We read all of them, stamp each row with the company it came from, and hand you a model that filters to one entity or consolidates the whole group.
You get a scope and an hour count before any work begins, drawn from prepaid Flex hours that never expire. No project minimum, no retainer, and a full refund inside the first 4 hours if you're unhappy.
It is a Power BI model built on your own Great Plains databases rather than a template you configure yourself. We map the ledger, sales, purchasing and AR/AP tables into a star schema, write and test the measures, publish the report, and maintain the refresh as your chart of accounts and companies change.
The distinctive part of a GP engagement is the source. Cloud ERPs make you negotiate with an API; GP hands you a relational database and gets out of the way. The cost of that openness is that nothing is pre-shaped for reporting — the physical tables are normalised for transaction processing, the column names are eight characters of history, and the same figure can be reached three different ways depending on whether a document has been moved to history. Getting that wrong is how a dashboard ends up disagreeing with the trial balance. Reconciling against your own ledger before handover is part of every build.
The ones your modules post to. General ledger detail comes from the open and history transaction tables, sales from SOP, purchasing from POP, and the subledgers from RM and PM, joined to the account, customer, vendor and item masters so every report shares the same dimensions.
| GP module | Core tables | What we build from them |
|---|---|---|
| General ledger | GL20000 (open year), GL30000 (history), GL00100 account master | P&L and balance sheet by account segment, 12–24 month trend, drill to journal line |
| Sales order processing | SOP30200 (posted headers), SOP30300 (posted lines) | Revenue, units and margin by customer, item and salesperson, with YoY comparison |
| Purchase order processing | POP30100 (PO history), POP30300 (receivings history) | Committed and received spend by vendor and item, receipt timing, price variance |
| Receivables | RM20101 (open), RM30101 (history), RM00101 customer master | AR aging buckets, DSO trend, per-customer collections worklist |
| Payables | PM20000 (open), PM30200 (history), PM00200 vendor master | AP aging, cash requirements by due date, vendor spend concentration |
| Inventory | IV00101 item master plus the module's quantity tables | On-hand by site, turns, slow-moving and aging stock |
Two practical notes. The open-versus-history split matters: a document sits in the open table until it is moved by a year-end or paid-transaction routine, so a report that reads only history quietly drops current activity. And the exact table set shifts a little by GP version and by whatever ISV modules you run, so we confirm the layer against your own databases during scoping rather than assuming a stock installation.
SmartList is a query and export tool, which means every report built on it depends on a person remembering to re-run it. We treat your existing favourites as a specification — they tell us exactly which columns people care about — and rebuild each one as a page that refreshes on a schedule.
| Export people re-run today | What it costs you | The Power BI replacement |
|---|---|---|
| Account transactions | Re-exported and re-pivoted every close | Live ledger model with drill from summary to the journal line |
| Sales line items | One file per rep, stitched together in Excel | One sales page, filtered by rep, customer, item or site |
| Receivables transactions | Aging rebuilt by hand before every collections meeting | Aging buckets, DSO trend and follow-up flags, refreshed overnight |
| Payables transactions | Cash planning off a snapshot that is already out of date | AP aging and cash requirements by due date, always current |
| Item quantities | Stale by the time the file is circulated | On-hand, turns and slow movers by site, on the same refresh |
| Custom SmartList Builder queries | Logic known to one person and documented nowhere | Named measures in a model your team owns and can read |
Financial statements are usually the last thing to move, because Management Reporter — and FRx before it — encodes years of accumulated layout logic in row, column and reporting tree definitions. We read those definitions, rebuild the same structure over the GL tables, and reconcile line by line before you retire anything.
The row definitions map to account ranges and segment filters, the column definitions become period and comparison logic, and reporting trees become the consolidation hierarchy in the model. Once that is in place the statements gain what the old stack could never offer: click a subtotal and see the journal lines behind it, put twenty-four months of the same statement side by side, or hand a department head their own filtered view instead of emailing a PDF. It also removes a separate server-side component from your estate, which matters more each year that the GP platform ages. If your close pack is the priority, our Power BI for finance teams page covers the wider month-end report set we build.
GP stores every company in a separate SQL database, with the system database holding the company list. That design is why group reporting in GP means exporting each entity and combining the files by hand. In Power BI the same design is an advantage: we read each company database and union the results into one model.
The engineering work is in the differences between entities. Charts of accounts drift apart over time, so we map each company's segments onto a shared structure and tell you where they genuinely cannot reconcile rather than papering over it. Intercompany balances are flagged so eliminations are visible rather than assumed. Where entities post in different currencies we agree a rate source and apply it consistently. The result is a single set of statements that filters to one company, a region, or the whole group — and adding an acquired entity later is a scoping conversation, not a rebuild.
With a direct connection to SQL Server. Power BI's SQL Server connector reads the GP company databases over the network, or an ODBC connection where your environment calls for one. A read-only login scoped to the databases we need is enough, and there is no cloud API anywhere in the path.
Microsoft documents the connector we use, its Import and DirectQuery modes, and the credentials it accepts in the SQL Server database connector reference (opens in new tab). Because your server sits on your own network, published reports reach it through the on-premises data gateway (opens in new tab) — we install or adopt it, then set the scheduled refresh (opens in new tab) to match your posting rhythm. Most GP builds run in Import mode, which keeps the report fast and takes the query load off a production server; where users genuinely need same-hour figures we discuss DirectQuery and what it costs in performance. Where the raw tables are awkward we add read-only views in a reporting schema rather than reshaping anything GP writes to. If your reporting reaches beyond GP into other databases on the same server, our SQL Server Power BI dashboard page covers that work in more depth. We are not affiliated with Microsoft and never imply a partnership; our engineers are Microsoft-certified and we use Microsoft's supported, documented tools.
Microsoft has announced that it will end Dynamics GP support on December 31, 2029 for product enhancements, regulatory updates and technical support, with security updates available until April 30, 2031, and encourages customers to move to a Dynamics 365 cloud product. That timeline changes how a reporting project should be scoped.
The announcement and the surrounding guidance are published on Microsoft's Dynamics GP documentation site (opens in new tab). The practical consequence for reporting is straightforward: a Power BI semantic model is a separate layer from the ERP, so the measures, statement structures and history you build now are not thrown away by an ERP decision later. When you do migrate, the model is repointed at the new source and the definitions of gross margin, DSO and departmental spend survive the move — which also gives you a like-for-like comparison across the cutover instead of a hole in the trend. Microsoft's own recommended destination is Business Central, and we build the same reporting there; see our Business Central Power BI dashboard page. If the group is heading toward the wider Dynamics 365 estate instead, our Dynamics 365 Power BI dashboard page covers those cloud sources. Teams that keep GP archived read-only after a migration usually keep the GP model alongside the new one so historic years stay queryable.
Work runs on prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), or Power 80 hours at $100/hr ($8,000). You approve a scope and an hour count before anything starts, so the price of the build is fixed before the first hour is used.
A first GP dashboard — say the P&L by segment, AR aging and a sales view for one company — commonly fits inside a single block. What moves the estimate is the state of the data rather than its volume: a clean single-company install with a consistent account framework scopes quickly, while several companies with divergent charts of accounts, heavy ISV customisation, or statement logic buried in years of Management Reporter definitions takes longer. We tell you which of those you have during scoping, before hours are committed. Traditional ERP reporting firms quote $175–250/hr with project minimums and a start date weeks out; you can compare the models on our affordable Power BI consulting page or read how prepaid Flex hours work.
Controllers and finance managers on GP whose close still runs through exported workbooks, and IT leads who own the SQL Server and a backlog of reporting requests they have no capacity to service. If you would rather hand off ongoing report work entirely, outsource Power BI development covers that arrangement.
The strongest fit is a company that has run GP for a decade or more, has real history worth analysing, and is now deciding what to do before support ends. It also suits multi-entity groups tired of consolidating by hand, and teams with an existing Power BI report against GP that is slow, wrong, or was built by someone who has since left. Contact is form-only — send your request through the form below and we'll reply with a scope estimate.
business days, typical
hours, never expire
own everything
A first GP build usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
Send the SmartList favourites and statements people actually rely on, plus your GP version and how many company databases there are. We confirm the table layer against your environment and reply with a scope and hour count before any work begins.
A senior US-based engineer connects read-only to SQL Server, builds the star schema and measures over the GL, SOP, POP, RM and PM tables, and reconciles every total against your ledger — most focused builds in 3–5 business days.
We configure the on-premises data gateway, set the refresh schedule, apply and test row-level security where entities need separating, and hand over the report, the model and the documentation. You own all of it.
Representative perspective
Close week used to start with four SmartList exports and a workbook nobody else could open. Now the statements and the aging refresh overnight and I spend the time reviewing numbers instead of assembling them.Controller, mid-sized manufacturer on Dynamics GP
Representative perspective
We run five companies in GP and consolidating them was two days of copy-paste every month. Having one model that reads every database and still lets each entity see only its own numbers was worth the engagement on its own.Finance director, multi-entity services group
Tell us your GP version, how many companies you run, and which exports you want to stop re-running. We'll scope the build and tell you the hours before any work begins — prepaid, never expiring, with no project minimum and no obligation.
FAQ
Through a direct SQL Server connection to the GP company databases, using Power BI's SQL Server connector or an ODBC connection where your environment requires one. GP is on-premises, so a read-only SQL login and an on-premises data gateway are usually all that is needed. There is no cloud API in the path.
Directly. SmartList is a query and export tool, so anything built on it depends on someone re-running it. We model the underlying physical tables — GL, SOP, POP, RM and PM — so the report refreshes itself. Your existing SmartList favourites are still useful as a specification for what people actually need.
Yes. GP keeps each company in its own SQL database, which is exactly why cross-company reporting is painful. We read every company database you nominate, stamp each row with its company, map the charts of accounts onto a shared structure, and give you one model that filters to a single entity or consolidates the group.
For most statement packs, yes. We rebuild the row, column and reporting tree logic as a Power BI model over the GL tables, so the P&L, balance sheet and departmental statements match what Management Reporter produced. We validate the rebuilt statements against your current output before anyone relies on them.
Microsoft has published an end of support date of December 31, 2029 for Dynamics GP, with security updates available until April 30, 2031. A Power BI model is a separate reporting layer, so your history and measures survive the ERP decision. When you migrate, we repoint the model rather than rebuild the reporting.
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.