Performance

Why your Power BI report is slow, in order of likelihood

Almost nobody has a Power BI performance problem. What they have is a data model problem that Power BI is faithfully rendering slowly, and the two get treated the same way — with more capacity, more RAM, more patience — when only one of those is fixable with money.

A mid-size industrial distributor came to us with a familiar complaint. Their sales performance report — the one the regional managers open every Monday — took 22 seconds to load and another 8 to 10 seconds every time someone changed a filter. Nobody was accusing the report of being wrong. They were accusing it of being slow, and the working theory was that Power BI itself, or the company's Pro licenses, or the laptops in the field, were the bottleneck.

None of those were the problem. The report was built on a single query pulled straight out of the ERP: one table, 2.3 million rows, 42 columns, covering three years of order lines. Every visual on the page was scanning that whole table every time. That is not a licensing problem. That is a table that was never supposed to be a data model.

The order that actually explains most slow reports

We've looked at enough of these to know the causes cluster, and they cluster in a fairly stable order. Here is that order, roughly by how often each one turns out to be the culprit.

Look at where the weight sits. Three-quarters of slow reports trace back to how the data is shaped before a single visual is drawn. The thing people reach for last — more capacity — is the thing that actually explains the problem least often.

One flat table is the default, and it's the wrong one

Every export from an ERP or a CRM comes out as one wide table, because that's how the source system stores it. It's tempting to load that table straight into Power BI and start building, especially when the report is due Friday. It also works, at first, when the table has ten thousand rows.

It stops working once the table has real volume, because a single flat table forces every visual to scan every column of every row, every time. A slicer on region has to look across the whole 2.3 million rows to find the distinct values. A card showing total revenue has to sum the whole column. There is no smaller structure underneath for the engine to lean on.

The distributor's fix was not exotic. We split the one table into a fact table of order lines — quantity, price, cost, about 260,000 rows once duplicated header data was removed — and three dimension tables: product, customer, date. The fact table now holds only the numbers and the keys that point to the dimensions. Filtering by region means the engine touches a customer dimension with a few thousand rows, not a fact table with millions. Page load went from 22 seconds to under 2.

Calculated columns are the second most common tax

A calculated column gets computed once per row, for every row, and stored in the model — which sounds efficient until you realize it also gets recomputed on every refresh and adds real weight to the file, whether or not anyone ever uses it in a visual. A measure, by contrast, computes only what's needed for the specific combination of filters on screen, on demand.

The distributor's model had eleven calculated columns doing things like concatenating a "sales rep — region" label, or flagging whether a row was "large order" with a hardcoded threshold. Every one of those belonged in Power Query, computed once at refresh, or as a measure computed on demand — not baked into the model as a column recalculated across 2.3 million rows on every open.

What we actually check, in order

1. Look at the model before the visuals. Open the model view. Count the tables. If there's one table with forty-plus columns, that's very likely the whole answer, and no visual-level fix will matter until it's resolved.
2. Separate what's stored from what's computed. Every calculated column gets a hard look: does this need to exist as a column, or can it be a measure, or can it be pushed upstream into the query itself.
3. Count visuals per page and check cardinality. A table visual with a column that has 40,000 distinct values will be slow no matter how good the model underneath it is. Aggregate before you visualize, not after.
4. Confirm import versus DirectQuery is a deliberate choice, not a default. DirectQuery has real uses — near-real-time data, sources too large to import — but it means every interaction sends a live query to the source. If nothing forces that tradeoff, import mode is almost always faster.
5. Only then look at capacity. If the model is genuinely lean and the report is still slow, that's when a hardware or licensing conversation is the right next step — not the first one.

None of this requires rebuilding the report from scratch. It requires rebuilding what's underneath it, which the users never see and the report author usually never touches after the first draft. That's exactly why it accumulates — it's invisible until someone times it with a stopwatch.

Reporting

Reporting questions QuickBooks and Xero structurally cannot answer

Every so often a report request comes back as "we can't build that in QuickBooks." That's usually true, and it usually has nothing to do with how the file was set up.

Take a regional facilities maintenance contractor running five branches across three states, about $9.4 million a year in revenue, tracked in QuickBooks Online with each branch mapped to a location tag. The owner wants one thing: which branch is actually more profitable, North or South. It sounds like a five-minute report. It isn't answerable as asked, and the reason is structural, not a matter of better bookkeeping.

A location field holds one value. A business has several.

In QuickBooks and Xero, a class or location tag is a single attribute on a single transaction line. One line, one location. That works fine when every dollar of revenue and cost belongs cleanly to one branch and stays there.

It stops working the moment a crew crosses branch lines, which in this business happens most weeks. Crews get dispatched wherever there's capacity. Payroll codes a crew's hours to whichever branch was active on the pay period cutoff — not to the branch where the job was actually performed. Materials get billed to the ordering branch, not the consuming one. Every one of these is a correct entry by the accounting rules. None of them reflects where the work happened.

The ledger has no way to hold "this labor belongs 60% to North and 40% to South, on these three jobs." It wasn't built to. Classes and locations are tags bolted onto a flat transaction list, not a relational structure that can express one crew serving two branches in the same week.

What that gap looks like in numbers

Pull the location report for North and South and it looks decisive:

The location report says South is the better-run branch. Once labor and materials are reattributed to the job they actually served, using the field service dispatch records rather than the payroll coding shortcut, the answer flips. North is the stronger branch. South has been absorbing costs generated by North's overflow crews for over a year, and the location tags never had anywhere to record that.

This isn't an argument for tagging more carefully. Better tagging discipline helps at the margin, but the underlying structure — one tag, one value, per line — cannot represent a many-to-many relationship between crews, branches, and jobs no matter how conscientious the bookkeeper is. The fix has to happen outside the ledger, by joining it to the dispatch and job-costing system that already records which crew did which job where.

The other structural gap: no version of the past

The second limit shows up less often but does more damage when it does. QuickBooks and Xero keep one version of history. When a transaction gets edited — a reclass, a corrected bill, a cleanup entry six weeks after close — the system doesn't keep the old value alongside the new one. It just changes the past.

The board saw Q1 margin reported at 21%. Six weeks later, a bookkeeper reclassifies $40,000 of misfiled expense out of overhead and into a job cost, fixing a genuine error. Pull the Q1 report today and it shows 24%. Nobody decided Q1 improved. There is no record it was ever reported at 21%, because the ledger doesn't version anything — it only ever shows you the current state of all history, restated silently every time someone touches it.

For a single correction, this is harmless. Over a year of routine bookkeeping cleanup, the numbers a company reported at the time and the numbers that ledger shows today for the same period can diverge meaningfully, and nothing surfaces the drift. The audit log records that each edit happened, but nobody rebuilds a published report from it. If anyone ever needs to answer "what did we actually tell the bank in Q1," the ledger cannot answer that question. It was never designed to remember what it used to say.

What to do about it

1. Identify which dimension the ledger is missing. Usually it's the thing that moves across your tagging boundaries — crews across branches, projects across cost centers, subscriptions across product lines. The operational system that dispatches, schedules, or fulfills the work almost always already records the real relationship.
2. Build a bridge, not a better tag. A many-to-many join between crews and branches, or jobs and locations, lives outside QuickBooks in a small relational structure that can hold "this labor split 60/40." The ledger stays the system of record for cash and tax. The bridge becomes the system of record for allocation.
3. Snapshot before you let anyone edit. If a report goes to a bank, a board, or an owner, capture a copy of the numbers as reported, separate from the live ledger, before the next round of bookkeeping cleanup touches the period. That's the only way to answer "what did we say then" months later.
4. Recompute on a schedule, not on request. Once the bridge exists, rerunning the branch or crew allocation is a scheduled job, not a special project every time someone asks the question.

None of this replaces QuickBooks or Xero. Both are doing exactly what a general ledger is supposed to do. The questions that stall are the ones that need a relationship the ledger was never built to hold, or a memory of the past the ledger was never built to keep.

Reporting

Two reports disagree. Here's what's actually wrong.

Sales says the number is one thing. Finance says it's another. Twenty minutes of a leadership meeting disappears into which spreadsheet is right — and the honest answer is usually that both are.

Every business we walk into has a version of this. It's treated as a data quality problem, and people go looking for the bad number. That's rarely where it lives.

The problem is almost always that the same word means different things in different systems, and nobody ever wrote down which one is the company's answer.

One word, four legitimate meanings

Take "revenue." In a business with a CRM, an order system and an accounting package, that single word can honestly mean any of the following:

Four numbers. Four correct answers. They will never match, and no amount of reconciliation will make them, because they are measuring four different things.

Now add the smaller decisions nobody documented. Does revenue include shipping charged to the customer? Are refunds subtracted in the month of the sale or the month of the refund? Do intercompany transfers count? Is a discount a reduction in revenue or a cost? Each of those is a defensible choice, and each one is being made differently in two places right now.

Why it gets worse rather than better

The usual response is to have someone reconcile the two reports. That works once. It doesn't survive the next month, because the definitions still live in two people's heads and in the formulas of two spreadsheets.

Then a third report appears, built by someone who copied the second one and changed a filter. Then somebody leaves and takes the reasoning with them. Within a year the organization has several numbers for the same thing and a quiet, corrosive habit of not fully trusting any of them.

That last part is the real cost. It isn't the wasted meeting time. It's that people stop making decisions from the data and start making them from instinct, while still paying for the reporting.

How we go about fixing it

The fix is not a better dashboard. It's putting the definition somewhere that isn't a person or a spreadsheet.

In practice that means building a semantic layer between your source systems and every report — one model that holds the calculation for each metric, once. "Net revenue" is defined in a single place, in code, and every report that shows net revenue reads that definition rather than reimplementing it. When the definition changes, it changes everywhere, in one edit.

Getting there is usually less about technology than about a conversation. We sit with the people who own each number and force the ambiguity into the open: what exactly does this include, what does it exclude, and which team's version wins. That conversation is uncomfortable for about an hour and then it's done forever.

The technical part — modeling it properly, making it fast, and locking down who can see which rows — is the straightforward half.

What you can do before calling anyone

1. Take one disputed number and find every version of it. Not all your metrics — one. List every report that shows it and who built each. The list is usually longer than anyone expects, and the exercise alone often reveals the answer.
2. Write the definition down in a sentence. "Net revenue is invoiced amounts excluding shipping and tax, less credits issued in the same period." If two people can't agree on that sentence, no reporting tool will save you — that's the actual problem, and it's a business decision, not a technical one.
3. Decide who owns it. Every metric needs one person who gets to settle disputes about what it means. Without that, the definitions drift again within a quarter.

Do those three things and you'll have fixed most of it yourself. What's left is making the definition live in the system rather than in a document nobody opens — which is where we usually come in.

Operations

What a hand-built monthly report actually costs you

Somebody in your business spends the first few days of every month assembling the same report. It feels like a small annoyance. Written down as a number, it usually isn't.

You know the one. Export a few files, paste them into a workbook, match the columns, fix the ones that didn't match, rebuild the summary, notice something looks wrong, chase it down, send it out. Then do it again in four weeks.

Nobody has ever costed it, because the time is buried in a salary that's being paid anyway. So it survives for years.

The arithmetic

Here's a typical one — a monthly operations and margin pack, assembled by an office manager or a controller:

Eight hours a month is 96 hours a year — about two and a half working weeks. At a fully loaded cost of $45 an hour that's roughly $4,300 a year, every year, to produce a document that already existed last month in a slightly different form.

And that's the cheap part.

The cost nobody counts

A report built by hand in the first week of the month describes a month that ended a week ago. By the time anyone acts on it, the information is five or six weeks old on average.

So the real question isn't what the eight hours cost. It's what you'd have done differently if you'd known three weeks earlier — that a product started losing money, that a customer stopped ordering, that a job was running over. Most businesses can name a decision from the last year that would have gone differently with two weeks' notice, and the value of that one decision usually dwarfs the labor.

There's a third cost too, quieter than both. The person doing it is usually one of your more capable people, and this is the least valuable thing they do all month.

Why it never gets fixed

Not because it's hard. Because it belongs to nobody. It's not big enough to be a project, the person who builds it is too busy building it to automate it, and the software that would replace it looks like a bigger commitment than the annoyance justifies.

So it stays. We've seen the same report assembled by hand for nine years.

How we go about it

Usually in about a week, and usually starting with the exports that already exist rather than anything new.

The work is: connect directly to the systems the exports come from, rebuild the matching and cleaning steps as a pipeline that runs on a schedule instead of a human, model the numbers once so the definitions are fixed, and then deliver the result the way the audience already consumes it — a live dashboard for the people who want to explore, and a scheduled PDF or spreadsheet in the inbox for the people who genuinely just want the file on the first of the month.

That last point matters more than it sounds. Plenty of automation projects fail because they hand people a portal when what they wanted was the attachment they've always had, arriving without anyone having to make it.

Worth doing yourself first

1. Time it honestly for one cycle. Not an estimate — have whoever builds it note the actual hours, including the chasing and the fixing. It's almost always more than the estimate.
2. Ask who reads it, and what they do next. Occasionally the honest answer is nobody and nothing, and the right fix is to stop producing it. That's a free win and we'd rather you found it than paid us to.
3. Check whether the source systems have APIs. If the data can be pulled programmatically — most modern accounting, commerce and field systems can — automation is a week of work rather than a project.

Analytics

Why your P&L can't tell you which products make money

Your income statement is correct. It is also, by design, incapable of answering the question most owners actually want answered — and no amount of better reporting on top of it will change that.

Here is a situation we see constantly. A business is doing well. The P&L shows a healthy gross margin — say 67%. Revenue is growing. And yet cash is tighter than it should be, and nobody can say precisely why.

The instinct is to look harder at the reports. Usually that's the wrong move, because the answer isn't hiding in the reports. It's absent from them.

A chart of accounts has no product dimension

An income statement is organized by account — revenue, cost of goods sold, advertising, shipping, merchant fees. That structure is exactly right for tax filing and for understanding the business as a whole.

But notice what it doesn't have: any notion of which product caused which cost. Advertising is one line. Shipping is one line. Payment processing is one line. Each is a company-wide total sitting beneath the gross margin, and none of them is attached to the thing that generated it.

So when you ask "which products actually make money," the ledger can only answer with revenue minus cost of goods. Everything else is invisible at the product level — not because the bookkeeping is wrong, but because the structure has nowhere to put it.

What that gap looks like in numbers

Take a consumer goods business turning over about $815,000 a year across fourteen products. The P&L shows gross profit of $548,000 — a 67.3% margin. Genuinely healthy.

Now push the four company-wide cost lines down to the products that caused them:

Sixty-seven percent becomes thirty-eight. That's not an accounting error — it's the same money, just attributed rather than pooled. And the aggregate number isn't even the interesting part.

When those costs land on individual products, three of the fourteen turn out to be sold at a loss, together destroying about $14,000 a year. On the P&L all three show gross margins between 52% and 57%. They look like winners.

The reasons are specific and, once visible, obvious. A limited-edition item absorbs a disproportionate share of ad spend because it needs promotion to move. A bulky product costs more to ship than it earns in gross profit. A fragile one comes back on nearly one order in five, and the returned units can't be resold.

None of that is knowable from the ledger. All of it is knowable from the ledger joined to the operational systems that recorded it — the order platform, the payment processor, the ad account.

Why better reporting tools don't solve this

There is a healthy market of reporting products that connect to QuickBooks or Xero and produce polished dashboards. They're good at what they do. But almost all of them are ledger-in, report-out: they read the accounting system and nothing else.

Which means they inherit the ledger's structure, including the missing product dimension. A prettier rendering of an income statement is still an income statement. The moment the question becomes "margin by SKU after fees and ad spend" — or "profit per job after labor and materials," or "revenue per billable technician" — the ledger alone cannot answer it, and neither can anything reading only the ledger.

The answer requires joining data across systems that were never designed to talk to each other. That's an engineering problem, not a reporting one, and it's the reason this analysis is rare despite being valuable.

What to do about it

1. Pick one question that would change a decision. Not "show me everything" — one question. Which products lose money. Which jobs run over. Which customers cost more to serve than they pay. A narrow question is answerable in days; a broad one becomes a project.
2. Find the system that holds the missing dimension. Whatever your ledger can't see is usually recorded somewhere else already — the e-commerce platform knows SKUs, the field service system knows jobs, payroll knows hours. You rarely need new data collection. You need the join.
3. Allocate honestly, and write down how. Shipping by billable weight, fees at actual transaction cost rather than a blended rate, advertising by campaign where a campaign maps to a product. The method matters less than being explicit about it, because the first thing anyone will ask is how a number was arrived at.

Contribution margin isn't net profit — it excludes overhead, salaries and anything else that doesn't vary by product. It answers one question well: which parts of the business earn their keep. For most owners that turns out to be the question they were trying to ask all along.