McLeod to Power BI, done for you
Every McLeod Software Power BI dashboard starts with the extraction path, not the first visual: the Cloud IQ model inside the dedicated Power BI workspace McLeod provisions for you, the MPact.IQ templates over McLeod’s integrated data warehouse, or a read of the LoadMaster Enterprise SQL Server database through the on-premises gateway. Then revenue per mile, deadhead, cost per mile and profit per truck become measures with definitions you approve. Most builds ship in 3–5 business days.
Representative dashboard — sample data
Where McLeod reporting runs out
Carriers rarely arrive with a reporting problem. They arrive with an access problem. LoadMaster Enterprise has been recording every order, movement, stop, settlement and invoice for years, McLeod’s own analytics layer prints a respectable set of standard reports on top of it, and somewhere between those two facts sits the question nobody can answer this week: which power units actually earned money after fuel, maintenance and the empty miles that positioned them.
The reason is structural rather than anyone’s fault. McLeod’s analytics products — Cloud IQ and the MPact.IQ templates — are built around a model McLeod maintains, hosted where McLeod hosts it, answering the questions the template set was designed around. That is genuinely useful, and for many carriers it is enough. It stops being enough the moment you want your own definition of a billable mile, your fuel card and maintenance data sitting beside the freight, or five years of history retained on your terms.
So the first hour of this build is not modelling. It is establishing which door is actually open to you — the dedicated Power BI workspace, the warehouse behind the templates, or the SQL Server database underneath LoadMaster — because that decision sets refresh cadence, cost and what the report can honestly claim. If you want the metric definitions themselves rather than the plumbing, those live on our Power BI for trucking companies page.
Reports we build from McLeod data
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 these is settled in the scope estimate, in writing, before an hour is spent.
Cloud IQ workspace, MPact.IQ warehouse or the LoadMaster SQL Server database — the three routes carry different refresh cadence, different cost and different ceilings. We confirm which ones your deployment and your McLeod agreement actually permit before a report is designed around one.
What a customer bought and what the fleet ran are separate records, and one order can be covered by more than one movement once a relay, a repower or a drop is involved. Collapse them into a single row and revenue per load quietly stops reconciling.
Billed miles, routed miles and the miles the tractor actually turned are three different figures on the same load. We fix one per measure with you, label it on the report face, and keep the others in the model so a gap can be explained instead of argued about.
LoadMaster costs a truck; PowerBroker buys capacity. Averaged together, cost per mile describes neither. We model them as separate facts over shared customer, lane and date dimensions so the group number survives without hiding either business.
Fuel cards, ELD and telematics, maintenance software and the accounting ledger are where half the cost per mile lives. Joining them to McLeod freight on truck, driver and date is the part no template set can do for you, because those vendors are your choice, not McLeod’s.
A terminal manager should open the same report as the CFO and see only their own units, drivers and customers. Row-level security is designed into the model at the start, not bolted on after someone forwards the wrong page to a broker.
Through one of three doors, and which of them is open to you depends on your deployment more than on your budget. Power BI ships no first-party McLeod connector, and McLeod’s published integration catalogue is a list of vetted partner integrations — load boards, ELD providers, fuel cards, mapping — rather than an open reporting API. So the realistic paths are McLeod’s own analytics layer, or the database underneath the application where your agreement allows a read.
McLeod’s business intelligence product page for truckload carriers (opens in new tab) describes the shape of that analytics layer: an integrated data warehouse with template sets for financial, revenue and operations reporting, and role-specific views driven by responsibility filtering. The hosted Cloud IQ version of McLeod IQ runs in Microsoft Azure and publishes a secure, private Power BI workspace per customer, with the Cloud IQ model reachable from Power BI, Excel or SQL Server Reporting Services and a standard template library covering subjects such as fuel analysis, lane analysis, customer scorecard, driver scorecard and revenue reporting.
| Route | What it is | What it gives you | When we choose it |
|---|---|---|---|
| Cloud IQ dedicated Power BI workspace | McLeod-hosted business intelligence running in Azure, with a private Power BI workspace provisioned per customer over the Cloud IQ model | A standard template library out of the box, reachable from Power BI, Excel or SSRS, with no database access to negotiate and no infrastructure to stand up | Fastest start, and the right base when the standard subjects already answer most of the question — we build alongside it rather than replacing it |
| MPact.IQ templates over the integrated data warehouse | McLeod’s reporting and analytics layer, with financial, revenue, operations and role-specific templates and responsibility filtering, fed from LoadMaster, PowerBroker or other source data | A curated warehouse and a template set maintained by the vendor, with the role filtering already thought through | When the warehouse is already in place and the gap is bespoke measures and non-McLeod sources rather than the underlying data |
| LoadMaster Enterprise SQL Server, read direct | A read-only login against the SQL Server database behind LoadMaster Enterprise, reached by Power BI through the on-premises data gateway | Full grain and full history: orders, movements, stops, settlements, invoices and equipment at the level the application records them | Where the deployment and your McLeod agreement permit it — the strongest route for profit-per-truck and lane-level work, and the one most likely to need permission first |
| A scheduled extract into a warehouse you own | A nightly copy of the entities the reports need, landed into Azure SQL, Microsoft Fabric or a database you already run | Isolation from the production TMS, retained history on your terms, and one place where McLeod, fuel, maintenance and the ledger finally meet | Multi-source builds, long history requirements, or any carrier whose database access is read-restricted during business hours |
| Scheduled report output as a fallback | Saved report exports from the McLeod analytics layer, delivered on a schedule to a folder or a SharePoint library | Whatever grain the report itself carries — usually summarised, rarely joinable, always slower to change | Only as a bridge while a durable route is approved, or where a single established figure lives nowhere else |
| An existing warehouse copy | McLeod data someone has already landed into a database, lakehouse or reporting replica | A source that is already governed, already joinable to accounting, and already refreshing | Always our first question — it is usually cheaper to model what exists than to build a second pipe beside it |
One thing we settle honestly in scoping rather than after: a direct database read is a permission question, not a technical one. Whether your LoadMaster Enterprise runs on your own servers or in McLeod’s hosting changes what is available, and so does the wording of your agreement. We ask, we wait for the answer, and we design the build around the route you actually have. The same discipline we apply to any database-backed build is described on our SQL Server Power BI dashboard page.
A carrier’s profit question is a join problem. Freight revenue sits in one place, the cost of turning the wheels sits in four others, and the truck is the only thing they all agree on. So the model is built around the power unit, the driver and the load, with everything else hanging off shared dimensions — the standard star schema guidance (opens in new tab) Microsoft publishes, applied to freight.
| Entity | Grain | What it answers once modelled |
|---|---|---|
| Orders | One row per order taken from a customer | Revenue by customer, commodity and lane; accessorial mix; what was sold rather than what was run |
| Movements | One row per movement executed against an order | Loaded and empty miles, deadhead percentage, relays and repowers, and the truck-level view of the work |
| Stops | One row per stop on a movement | Arrival and departure timing, detention exposure, on-time service by customer and facility |
| Driver settlements | One row per pay line per settlement | Driver pay per mile, pay mix between mileage, accessorial and bonus, and the driver-side cost of a load |
| Purchased transportation (PowerBroker) | One row per carrier pay line on a brokered load | Spread and margin percentage per load, customer and lane; carrier concentration; buy-versus-sell trend |
| Invoices and AR | One row per invoice, aged against terms | Billing lag from delivery to invoice, aged receivables by customer, revenue recognised against revenue billed |
| Power units, trailers and drivers | One row per asset or driver, with status history | The dimensions everything else is measured against — fleet, terminal, domicile, seated versus unseated trucks |
| Fuel, maintenance and the ledger | One row per fuel purchase, work order or journal line | Fuel cost per mile, maintenance cost per unit, and the fixed cost that turns revenue per truck into profit per truck |
The last row is the one that decides whether the build is worth doing. Fuel cards, telematics, maintenance software and the accounting ledger are outside McLeod entirely, and no vendor template set can join sources it does not own. That join — on truck, driver and date, with the mile count agreed — is what turns a revenue report into a profit report.
Usually because they are measuring different things and both are right. Three causes account for most of it, and all three are settled during the build rather than discovered in a board meeting.
The load spans the period. A movement dispatched Monday and delivered Thursday belongs partly to two weeks and sometimes to two accounting periods. Counted on a single date, revenue per truck spikes and collapses for reasons that have nothing to do with the operation. We agree the recognition date, then either allocate across the movement or expand to a daily truck-level fact table.
The mile is not the same mile. Billed miles, routed miles and ELD odometer miles disagree on every load, and dividing revenue by one while dividing cost by another produces a rate per mile nobody can reconcile.
Revenue is netted differently. Linehaul, fuel surcharge and accessorials behave differently in a rate comparison, and brokered revenue reported gross against asset revenue reported net will flatter one side of a mixed carrier permanently. Each gets its own measure, with the definition written down beside it.
The dataset is published into your own Power BI workspace, not ours. Where the route is a gateway connection to SQL Server, refresh is scheduled to your operating rhythm within Microsoft’s published data refresh limits (opens in new tab) — up to eight scheduled refreshes a day on Power BI Pro, more on higher capacities — and large fact tables use incremental refresh so a nightly run does not reload five years of movements. Row-level security maps terminals, fleets and customer groups to the people who should see them, so one report serves the CFO and the terminal manager without a second copy existing.
Handover is the point of the exercise. You get the semantic model, the queries, the measure definitions and documentation, all inside your tenant. We maintain it from your banked hours if you want us to, and the model keeps working if you do not. The modelling conventions we use are the ones set out on our data modeling and DAX page.
You buy 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). Hourly work starts from $100/hr. A first McLeod dashboard typically fits inside one block once the extraction route is settled, and most builds ship in 3–5 business days after the scope estimate is approved. There is no project minimum and no retainer.
Traditional Power BI firms charge $175–250/hr, set project minimums, want $10K+ to start, let unused hours expire, and don’t begin for 4–6 weeks. You send the request, we reply with a scope and hours estimate, and hours are deducted only for work you approve. Our affordable Power BI consulting page covers the pricing model in depth, and how prepaid Flex hours work walks through the mechanics.
Asset-based truckload and LTL carriers running LoadMaster Enterprise, freight brokerages running PowerBroker, and the mixed operations running both — typically at the point where the fleet has outgrown what a standard template set can answer, or where a CFO wants freight, fuel, maintenance and the ledger in one model. If you arrange freight rather than haul it, with job files, customs entries and trade lanes as the unit of profit, the CargoWise Power BI dashboard build covers that shape instead. If your equipment earns on rental rather than on miles, utilization and return on original equipment cost are covered on Power BI for equipment rental companies.
Two things we scope rather than imply. We do not resell, rebuild or copy McLeod’s own analytics content — where Cloud IQ or the MPact.IQ templates already answer a question well, we say so and build around them. And writing back to McLeod is out of scope entirely: every route we use is read-only, because a reporting project should never be able to change a dispatch record. Contact is form-only — send your request and we reply with a scope estimate.
business days, typical
only access to McLeod
own everything
A first McLeod dashboard usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
We establish which path your deployment and your McLeod agreement allow — the Cloud IQ workspace, the MPact.IQ warehouse or a read-only login against LoadMaster Enterprise — and in parallel agree the definitions: which mile each measure uses, how fuel surcharge and accessorials are treated, where the period boundary falls on a multi-day movement. You get a scope and hours estimate before work begins.
A senior US-based engineer builds the extraction, lands it where you can keep it, joins the fuel, telematics, maintenance and ledger sources to the McLeod freight on truck, driver and date, then builds the star schema and writes the DAX — reconciling every total against a McLeod report your team already trusts.
Published into your own Power BI workspace with scheduled or incremental refresh and row-level security by terminal, fleet and customer group. You keep the model, the queries and the documentation, we maintain it from your banked hours, and our access can be revoked without anything breaking.
Representative perspective
We had the standard reports and we had a spreadsheet somebody rebuilt every Monday, and the two never matched. Having one model where the mile count is written on the page ended a two-year argument about which number was real.Controller, regional truckload carrier
Representative perspective
The part we underestimated was fuel and maintenance. Freight data was never the problem — getting the cost side to line up against the same truck and the same week was, and that is what finally made profit per unit a number we could act on.Operations director, asset-based carrier with a brokerage arm
Tell us which McLeod products you run, how your deployment is hosted, and the reports you need. We’ll confirm the extraction route and the definitions, then tell you the hours before any work begins — drawn from prepaid Flex hours that never expire, with no project minimums and no obligation.
FAQ
Power BI ships no first-party McLeod connector, so the route is chosen rather than assumed. Three are realistic: the Cloud IQ model, which McLeod publishes into a private Power BI workspace it provisions for your company; the MPact.IQ templates over McLeod’s integrated data warehouse; or a read-only connection to the LoadMaster Enterprise SQL Server database through the on-premises data gateway.
Because Cloud IQ answers McLeod’s questions well and yours only if they happen to match. It ships a standard template set over a model McLeod controls, inside a workspace McLeod provisions. A custom build starts where that stops: your own definition of a billable mile, your fuel cards and maintenance data joined in, and history you keep.
Often, and it is the fastest route when it is open to you. LoadMaster Enterprise is a SQL Server application, so a read-only login plus the on-premises data gateway gives Power BI a refreshable source. Whether that access exists depends on your deployment and your agreement with McLeod, which is the first thing we confirm in scoping.
The cost side is a different shape. An asset fleet spends on drivers, fuel, equipment and maintenance per mile, so margin is built from cost per mile. A brokerage buys capacity, so margin is the spread between customer rate and purchased transportation on the same load. Same platform family, two different profit stories, modelled separately.
Yes, and mixed carriers usually need it. The mistake is averaging them together, which makes cost per mile meaningless for both. We model asset and brokered freight as separate fact tables over shared customer, lane and date dimensions, so each business is managed on its own terms and the group total still exists.
For most carriers, scheduled overnight refresh with an intraday top-up is the honest answer, and it is set by the route rather than by preference. A gateway connection to the LoadMaster database can refresh several times a day within Power BI’s published limits; a hosted model or an export route refreshes on the cadence that route allows.
No. We are an independent US-based Power BI consultancy with no McLeod partnership to claim and no connector to sell. We work with whatever access your company already holds, everything is published into your own Power BI workspace, and you can revoke our access at any time without the model breaking.
If the open question is which carrier metrics belong on the page at all — how operating ratio, cost per mile, seated trucks and driver turnover are defined and which of them a fleet should manage weekly — that ground is covered on Power BI for trucking companies, and this page is the source-system half of the same build. Forwarders, customs brokers and 3PLs working job files rather than power units should read the CargoWise Power BI dashboard page instead. Operations whose trailers, reefers or yellow iron earn on rental rather than on miles measure utilization and return on original equipment cost, covered on Power BI for equipment rental companies. And where the route in is a direct database read, the general approach to a gateway-backed build is on our SQL Server Power BI dashboard page. 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.