Sage 300 CRE to Power BI, done for you
We get job cost, commitments, billing, AP and Property Management data out of the Sage 300 CRE data folder — through the SQL Replicator, ODBC or a scheduled extract — and into a Power BI dashboard that refreshes on a schedule. No more .DAT exports rebuilt in Excel every month-end.
Representative dashboard — sample data
Why these builds stall
Sage 300 Construction and Real Estate — still called Timberline by most of the people who use it — keeps company data in a Pervasive-engine folder of .DAT files, one per table, grouped by module. That design is why the accounting is reliable and why the reporting is painful: there is no database for Power BI to point at, so the report cycle usually ends up as somebody exporting the same job cost and AP inquiries every month and rebuilding a workbook around them.
So the hard part of this build is not the visuals. It is the extraction route, the module structures that have to be reassembled into a model, and the definitions — percent complete, cost at completion, what counts as committed — that finance and operations need to agree on before a WIP number means anything. Industry context for the metrics themselves lives on our Power BI for construction job costing page; this page is about getting Sage 300 CRE data to a place where those metrics can be calculated at all.
What we build from Sage 300 CRE
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.
What the build covers
Every one of them sits upstream of the first visual, and every one is where an in-house attempt tends to stop.
Before anything is modelled we settle how the data leaves: the Sage SQL Replicator into SQL Server, an ODBC connection, or a scheduled extract. That decision drives refresh speed, licensing and how much of the history you can keep.
Job, extra, cost code and cost type are separate structures in Sage. They become a conformed job hierarchy, so a cost code rolls to a phase, a phase to a job, and a job to a division without anyone re-keying the tree.
Original estimate, approved change orders and the revised budget are three different numbers, and a WIP built on the wrong one is wrong all year. We keep them as separate columns and let the report show the movement between them.
Retainage receivable in Contracts and Billing and retainage payable in AP are tracked separately from the invoice amounts, so cash forecasting and the WIP schedule stop disagreeing about what has actually been billed and paid.
Where the Property Management module is in use, leases, units, recurring charges and tenant receivables join the same calendar and entity dimensions as job cost — one report across the build and the stabilised asset.
An on-premises data gateway keeps the refresh running against a server that never leaves your network, and row-level security decides which project managers, divisions or properties each viewer can see.
Not with a connector, because there isn’t one. Sage 300 CRE stores each company as a folder of Pervasive-engine .DAT files — one file per table, prefixed by module, so Job Cost, Accounts Payable, Contracts, Billing, General Ledger, Payroll, Equipment Cost and Property Management each contribute their own master and transaction files. Power BI cannot read that folder, and neither can any other modern reporting tool without a translation layer in between. Choosing that layer is the first real decision of the project, and it is worth making deliberately, because changing it later means rebuilding every query.
Four routes are actually used in the field. In most cases we recommend the first, connect Power BI with the standard SQL Server connector (opens in new tab), and treat the rest as fallbacks for specific constraints.
| Route | What it gives you | When we use it |
|---|---|---|
| Sage SQL Replicator | A one-way, read-only copy of the Sage data folder inside a Microsoft SQL Server database, refreshed by a Sage service | The default. Reporting queries hit the replica rather than live accounting files, indexes make a multi-year cost history usable, and Power BI just sees SQL Server |
| Pervasive ODBC connection | Direct query access to the data folder through the ODBC driver Sage installs | Small datasets, or a proof of concept before the replicator is stood up. Watch the driver architecture — a 32-bit DSN is invisible to 64-bit Power BI Desktop, which is where most first attempts fail |
| Scheduled inquiry or report exports | Sage inquiries, report designs or Excel add-in queries written out to a folder on a schedule | Where IT will not open database access at all, or a field exists only inside an established report. Workable, but it is the export habit with a timer on it |
| An existing SQL or Fabric copy | Sage data already landed in SQL Server, Microsoft Fabric or a warehouse by an internal pipeline | Always our first question — it is faster to refresh, cheaper to model, and already joinable to whatever else you report on |
Two practical notes on the replicator route. It needs a SQL Server instance somewhere, and while SQL Server Express is free it caps a single database at 10 GB, which a contractor with a decade of cost transactions and payroll detail can reach; sizing that early avoids an unpleasant surprise in year two. And the replica is a copy, so the interesting question becomes how often it syncs and whether your refresh window sits after it, not before. If you already run SQL Server for other systems, our SQL Server Power BI dashboard page covers connecting Power BI to it directly, including when import beats DirectQuery (opens in new tab).
Only the ones your reporting questions need, but the WIP schedule alone reaches into four. Sage keeps each module’s masters and transactions in its own files, and the work of the build is reassembling them into a star schema — a small number of fact tables at consistent grain surrounded by shared dimensions — instead of a web of many-to-many joins that slows to a crawl the first time someone opens a two-year view.
| Sage 300 CRE source | What it carries | Role in the model |
|---|---|---|
| Job Cost masters | Job, extra, cost code and cost type structures with contract amount, estimate, status, project manager and job type | The job hierarchy dimension every other fact hangs from, flattened to levels and a path for roll-up and security |
| Job Cost transactions | Actual cost postings by job, cost code and cost type, with accounting date and source module | The cost fact — the denominator of percent complete and the basis of every burn and trend page |
| Estimates and change orders | Original estimate, approved changes and the resulting revised budget and revised contract | Budget fact at the same grain as cost, so variance is a subtraction rather than a lookup |
| Commitments | Subcontracts and purchase orders with committed amount, invoiced to date and retainage held | Commitment fact — what turns cost to complete from an estimate into a number with evidence behind it |
| Contracts and Billing | Contract items and progress billings, including AIA-style schedules of values and retainage receivable | Billing fact — the other half of the WIP schedule and the source of the over- and under-billing split |
| Accounts Payable | Vendors, invoices, retainage payable, due dates and compliance items such as insurance expiry | AP fact plus a vendor dimension, driving cash timing, subcontractor spend and compliance exception lists |
| General Ledger | Accounts, fiscal periods and posted balances by entity | The tie-out layer — how job-level reporting is proven back to the financial statements each period |
| Property Management | Properties, units, leases, tenants, recurring charges and tenant receivables | Lease and charge facts on the shared calendar and entity dimensions, for rent roll, occupancy and AR ageing |
The structure follows Microsoft’s star schema modeling guidance (opens in new tab), and the general craft is covered on our Power BI data modeling and DAX page. The detail that causes most rework here is the cost type and cost code standard. Most contractors have accumulated codes across decades, several mean the same thing to accounting, and one or two behave differently from how they read. We map them with your controller during scoping and keep the mapping as data, so next year’s additions are rows to add rather than queries to reopen.
Yes — that is usually the first thing built, and it is the measure set that justifies the project. Percentage of completion is calculated cost-to-cost: cost to date divided by estimated cost at completion. Earned revenue is the revised contract amount multiplied by that percentage. Compared with what has actually been billed, the difference falls into either a contract asset or a contract liability — the under- and over-billing columns your CPA works from under ASC 606.
| Measure | How it is defined | Why it is written this way |
|---|---|---|
| Percent complete | Cost to date over estimated cost at completion, by job and by phase | Cost-to-cost is what the WIP schedule is built on; a field-judgement percentage kept in a workbook cannot be audited |
| Cost at completion | Cost to date plus remaining commitment plus the forecast of uncommitted work still to come | Splitting committed from uncommitted shows how much of the forecast is contractual and how much is judgement |
| Earned revenue | Revised contract amount, including approved change orders, times percent complete | Using the revised rather than the original contract is the difference between a WIP that ties and one that argues with the ledger |
| Over-billing | Billings to date in excess of earned revenue, floored at zero and reported per job | A contract liability under ASC 606, and the number that tells you how much of your cash is borrowed from future work |
| Under-billing | Earned revenue in excess of billings to date, floored at zero and reported per job | A contract asset, and usually the earliest visible sign that billing has fallen behind production on a job |
| Gross profit fade | Estimated gross profit at completion this period against the original estimate, by job | Fade is gradual, so it only shows up as a trend — a single-period margin number hides it entirely |
| Remaining commitment | Committed amount on subcontracts and purchase orders less invoiced to date | Makes cost to complete defensible and flags a job where the commitment is exhausted before the work is |
| Retainage held and receivable | Retainage payable in AP and retainage receivable in Billing, tracked separately from invoice amounts | Retainage is the cash question owners ask most and the one the standard invoice reports answer least clearly |
| Backlog | Revised contract value less earned revenue, by job, division and expected completion period | Turns a pipeline conversation into a schedule, since backlog with no completion date attached is not a forecast |
The WIP is where the definitions get tested. Contractors reasonably disagree about whether unapproved change orders belong in the revised contract, whether committed-but-uninvoiced cost counts toward percent complete, and how to treat a job that is over-billed and behind schedule at the same time. We do not invent answers to those; we write down the one your controller and CPA already use, implement it as documented DAX, and validate every column against the WIP your team produced last quarter before anything is signed off.
Sage 300 CRE ships a genuine reporting layer — inquiries, report designs, and the Excel-based query add-ins many firms have layered on top — and for questions inside the platform, in Sage’s own shape of the data, it remains the right tool. The requests that reach us are the ones that cross a boundary: across modules, across several years, or onto a screen in front of people who do not have a Sage login and should not be given one.
| What you are trying to do | Reporting inside Sage 300 CRE | Custom Power BI model |
|---|---|---|
| Check a job cost inquiry today | Its core strength — live, in context, already secured | Possible, but not a reason to build a model |
| WIP across every open job, monthly | Assembled from several inquiries into a workbook by hand | One page, recalculated on refresh, with the same formula every period |
| Margin fade across two years of jobs | Hard — history is per job, not trended across the portfolio | Snapshotted estimates make period-over-period fade a chart rather than an archaeology project |
| Job cost beside property performance | Separate modules, separate reports | Shared calendar and entity dimensions put the build and the asset on one page |
| A pack for PMs and owners | Needs each viewer to hold a Sage login and know which inquiry to run | One published report, secured by job or division, in tools they already use |
| Where the logic lives | Inside report designs and workbooks on individual desktops | In a model file in your own tenant, documented and owned outright |
The honest answer is usually both. Keep Sage reporting for running the accounting, and build the model for the numbers that decide bonding capacity, staffing and which jobs to bid next.
Sage 300 CRE almost always runs on a server inside your network, so the Power BI service reaches it through the Microsoft on-premises data gateway (opens in new tab): installed on a machine that stays on, registered to your tenant, and given read-only credentials to the replicated SQL Server database. Nothing is exposed to the internet and no inbound firewall rule is opened. Our step-by-step Power BI gateway setup guide walks through the installation and the data source registration that trips people up.
Refresh cadence follows how the data actually moves. Job cost posts through the day, so a nightly refresh after the replicator sync suits most contractors, with an extra midday run during a heavy billing week — all inside Microsoft’s documented data refresh limits (opens in new tab). Where years of cost transactions have accumulated, we configure incremental refresh (opens in new tab) so each cycle re-reads only a recent window rather than the whole history.
Visibility is handled with row-level security in the Power BI service (opens in new tab), driven from a mapping of viewers to jobs, project managers, divisions or properties and evaluated against the flattened job hierarchy. A project manager sees their own jobs, a division lead sees their branch of the structure, and the controller sees everything. Payroll detail stays out of the shared model unless you specifically ask for it, since a job cost report and an employee pay register are not the same audience.
Prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), Power 80 hours at $100/hr ($8,000), with hourly work from $100/hour on the largest block. A first build covering job cost, committed cost and a WIP schedule from an existing SQL Replicator database usually fits a Starter block. Standing the extraction up from scratch, adding Property Management, or reconciling several years of historical estimates typically needs Growth, because agreeing the WIP definitions across the controller, the project managers and the CPA takes discussion as well as development.
Most tasks ship within 3–5 business days of scope approval, and you get a scope and hours estimate before anything starts. Our guide to Power BI dashboard development cost covers what moves the number, how prepaid Flex hours work explains the model in full, and custom Power BI dashboard development describes the wider service this build sits inside.
General contractors, specialty subcontractors and developers running Sage 300 CRE with enough job history to trend and no dedicated analytics engineer — typically the point where the WIP takes a week to assemble and two people quote different cost-to-complete figures in the same meeting. Controllers, CFOs and operations directors are the people who usually get in touch.
Writing back to Sage is out of scope: this is a read-only reporting build, and cost entry, billing and payroll processing stay where they are. Estimating detail that never leaves a takeoff tool is out of scope too, unless it is exported somewhere we can read on a schedule. If field production and RFIs matter more than the accounting, our Procore Power BI dashboard page covers that source system, and residential builders running jobs in Buildertrend should start with the Buildertrend Power BI dashboard build instead. Contact is form-only — send your request and we’ll reply with a scope estimate.
business days, typical
hours, never expire
own everything
A first Sage 300 CRE build usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
We check whether the SQL Replicator is already running, what SQL Server you have, and who owns access; meanwhile we agree percent-complete method, what belongs in the revised contract, how committed cost is treated and how far back usable history goes — then reply with a scope and hours estimate before any work begins.
A senior US-based engineer builds the queries against the replicated database, flattens the job hierarchy, reassembles Job Cost, Commitments, Billing, AP and Property Management into a star schema with a proper fiscal calendar, and writes the DAX — validating the WIP column by column against the schedule your team produced last quarter.
Published to your workspace with gateway-backed scheduled or incremental refresh, row-level security so each PM sees only their jobs, and documentation you keep. We maintain it from your banked hours.
Representative perspective
The WIP took most of a week to assemble every month, and by the time it was finished the jobs had moved on. Having it recalculate on refresh changed which meeting it belonged in.Controller, mid-market general contractor
Representative perspective
We had exports going into a workbook that only one person understood. The hard part was never the charts — it was getting the data out of Sage on a schedule anyone could rely on.CFO, commercial developer
Tell us which Sage 300 CRE modules you run, whether the SQL Replicator is already in place, and what your WIP process looks like today. We’ll confirm the extraction route, scope the task, and tell you the hours before anything starts — no project minimums, no obligation.
FAQ
Power BI ships no Sage 300 CRE connector, because the accounting data lives in a Pervasive-engine folder of .DAT files rather than a SQL database. The usual route is the Sage SQL Replicator, which copies that folder into a Microsoft SQL Server database Power BI reads with its native connector. ODBC and scheduled extracts are the alternatives.
It is the Sage-supplied tool that replicates your Sage 300 CRE data folder into a read-only Microsoft SQL Server copy, which reporting tools then query without touching live accounting files. You do not strictly need it, but it is the cleanest route: one refresh source, real indexes, and no query load on the production data folder.
Yes, and it is usually the reason people call. We build percentage of completion from cost to date over estimated cost at completion, earn revenue against the revised contract, compare it with billings, and split the result into contract assets and contract liabilities — the under- and over-billing columns your CPA already expects.
It does. Developers running both sides of Sage 300 CRE get one model where the job cost of a build and the rent roll, occupancy, recurring charges and tenant receivables of the finished asset share a calendar and an entity dimension, so construction spend and stabilised income can finally be read on the same page.
Through the Microsoft on-premises data gateway. It is installed on a machine that stays on, registered to your Power BI tenant, and given read credentials to the replicated SQL Server database. The Power BI service then refreshes on a schedule you choose without exposing that server to the internet.
No. We are an independent US-based Power BI consultancy with no Sage partnership to claim and no prebuilt connector to sell. We build against your own Sage 300 CRE data using read-only credentials your administrator controls, and everything we produce is published into your own Power BI workspace.
For the wider industry picture — which job costing metrics belong on a contractor’s dashboard and how margin fade is caught early — start with Power BI for construction. If your system of record is Vista rather than Sage, the Viewpoint Vista Power BI dashboard page covers that extraction in detail; field-side reporting from a project management platform is on the Procore Power BI dashboard page, and residential builders should read the Buildertrend Power BI dashboard build. Once Sage data is replicated, the connection itself is an ordinary SQL Server Power BI dashboard problem, with the gateway setup and development cost guides covering the two questions that come up next. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
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.