In August 2025, Microsoft finished deprecating the Power BI connector for QuickBooks Online. Dashboards that had been refreshing automatically for years stopped. There is no replacement, and Microsoft has indicated none is coming.

Worth understanding why, because the reason is more instructive than the event.

Power Query Desktop authenticated to online services using a component of Internet Explorer 11. QuickBooks Online dropped support for Internet Explorer 11. The authentication path broke. Microsoft could have rebuilt the connector to a modern standard, and chose to retire it instead.

Nobody did anything unreasonable. Intuit dropped a browser that should have been dropped. Microsoft declined to invest in rebuilding a connector that had spent its entire life in Beta and never been promoted to general availability. Each decision was defensible in isolation.

And the integration died anyway, because it was a side project for both of them.

That’s the structural point of this page. A native connector isn’t owned by anyone the way a product is owned. It’s a feature at the edge of two roadmaps, and when something upstream changes, fixing it competes against everything else either company could do instead.

What actually happened, and when

Documented in Microsoft’s own connector reference, which listed the release state as Beta, under deprecation:

DateWhat changed
May 2025Deprecation announced
June 2025Connector no longer shown in the Power BI Service
July 2025Entry removed from Power BI Desktop
August 2025Fully deprecated
View data
DateWhat changed
May 2025Deprecation announced
June 2025Connector no longer shown in the Power BI Service
July 2025Entry removed from Power BI Desktop
August 2025Fully deprecated

Microsoft’s guidance was to transition off existing connections and not use it for new ones. Scheduled refreshes in the Power BI Service stopped working for datasets using it.

The part practitioners found hardest was the silence. Many teams discovered the problem only when refreshes stopped and dashboards went stale — not because they’d missed an announcement, but because nothing in the tool told them the thing they depended on was on a retirement path.

The failure mode is silence, not an error

Teams discovered the problem when dashboards went stale, not when something told them. Nothing in the tool flagged that a dependency was on a retirement path. If you have client reporting built on a native connection, nothing will warn you either.

That’s worth sitting with if you have client reporting built on any native connection today.

Related: Getting QuickBooks data into Power BI and FP&A tools

Why native connectors underdeliver structurally

Four reasons, and none of them is incompetence.

The reason
What it means
Neither party owns it as a product.
A connector sits between two companies’ roadmaps. It generates no direct revenue for either. When it needs investment, it competes against features that do. The Power BI connector spent years in Beta because promoting it to general availability would have meant committing to support it — and nobody wanted to make that commitment.
Upstream changes break it without warning.
The failure here came from a browser deprecation, several layers away from anything either team was thinking about. Neither company was doing anything wrong. The integration simply had a dependency that neither of them was watching.
Scope stops at the obvious case.
Native integrations typically handle the primary object well and thin out fast at the edges — the second entity, the partial refund, the multi-currency transaction, the historical backfill. That’s rational engineering: build for the common case. It’s also exactly where accounting gets difficult.
There’s no escalation path.
When a paid third-party connector breaks, you have a vendor whose business depends on fixing it. When a free native connector breaks, both companies can reasonably point at the other, and there’s no contract on either side.

Where native is genuinely enough

The argument above is not that native connectors are bad. They’re free, they’re built by people with actual API access, and for a large share of situations they’re the right choice.

Native is usually sufficient when:

The condition
What that looks like
The data flow is one-directional and simple.
Pushing transactions in, or pulling a report out, with no reconciliation of state between the two systems.
Volume is modest.
Rate limits and batch behavior don’t bite until they do, and most small clients never get near them.
You need one object type, not a workflow.
Invoices only, or contacts only, rather than an order-to-cash chain.
The vendor’s core product depends on it.
A payments platform’s QuickBooks connector is materially more likely to be maintained than a BI tool’s, because reconciliation is central to what the payments company sells.

That last one is the most useful predictor in this whole piece. Ask whose business would suffer most if the connector stopped working. If the answer is neither party’s, that’s your risk assessment.

Ask whose business would suffer most if the connector stopped working. If the answer is neither party’s, that’s your risk assessment.

Six questions that predict whether it will hold

Before relying on any integration — native or paid — these are worth asking, and most can be answered in ten minutes.

  1. What’s its release state? Beta after several years is a signal, not a stage. The Power BI connector never left Beta and was deprecated from it.
  2. Whose revenue depends on it? If neither party’s, nobody’s roadmap protects it.
  3. Is the sync one-way or two-way? One-way is simpler and more robust; it’s also silently incomplete when changes are made on the other side.
  4. Does it post native accounting objects or journal entries? Journal-entry dumps are easier to build and they break native reporting. This one determines whether your reports still work afterwards.
  5. What happens on partial failure? If a batch stops halfway, what state are the books in, and does anything tell you?
  6. What’s the documented deprecation policy? For a paid connector there’s usually a contract. For a native one there’s a blog post, if you happen to read it.

Related: Nine questions to ask before buying any QuickBooks integration

If you’re on a native connector now

Not a reason to rip anything out. It is a reason to know where you stand.

  1. Inventory what you’re running. Per client, list every connection into QuickBooks, whether it’s native or third-party, and what breaks if it stops. Most firms have never written this down, and it takes an afternoon.
  2. Identify the single points of failure. A client whose month-end reporting depends entirely on one free connector with no contract behind it is carrying a risk nobody has priced.
  3. Know your export path. If the connector stopped today, could you get the data out another way, and how long would it take? For reporting integrations the answer is often “manual export to Excel”, which is survivable. For transactional integrations it’s usually worse.
  4. Watch the release notes for anything in Beta. It’s the least enjoyable advice on this page and the only one that would have given the Power BI users warning.
  5. Price the alternative before you need it. The replacement market for a deprecated connector fills quickly — several vendors had certified Power BI alternatives within weeks. But you’re choosing under time pressure, which is the worst condition for that decision.

The short version

  • Microsoft deprecated the Power BI QuickBooks connector in August 2025. No replacement is planned.
  • It broke because Power Query authenticated through Internet Explorer 11 and QuickBooks Online dropped support for it. Neither company did anything unreasonable.
  • The connector spent its entire life in Beta and was deprecated from it.
  • Native connectors underdeliver structurally because neither party owns them as a product, upstream changes break them without warning, scope stops at the common case, and there’s no escalation path.
  • Native is genuinely enough for simple one-directional flows, modest volume, single object types, and — most reliably — where the vendor’s own business depends on the connector working.
  • The best predictor: whose revenue suffers if this stops working? If neither party’s, that’s the risk.
  • If you’re on a native connector, inventory it, know your export path, and watch anything still labeled Beta.

Frequently asked questions

Is the Power BI QuickBooks connector deprecated?

Yes. Microsoft announced deprecation in May 2025, removed the connector from the Power BI Service in June 2025 and from Power BI Desktop in July 2025, and fully deprecated it in August 2025. Scheduled refreshes for datasets using it stopped working, and Microsoft has indicated no replacement is planned.

Why was the Power BI QuickBooks connector deprecated?

Power Query Desktop authenticated to online services using an Internet Explorer 11 component, and QuickBooks Online deprecated support for Internet Explorer 11. That broke the authentication path. Rather than rebuild the connector — which had remained in Beta throughout its life — Microsoft chose to retire it.

How do I get QuickBooks data into Power BI now?

The native path is gone. The available options are a third-party certified connector, an ODBC driver, replicating QuickBooks data into a database and pointing Power BI at that, or manual export and import. Several vendors released certified alternatives after the deprecation.

Are native QuickBooks integrations reliable?

For simple, one-directional, modest-volume flows they generally are. The structural risk is that a native connector is a side project for both companies, generates no direct revenue for either, and competes with revenue-generating work when it needs investment. The most useful test is whose business would suffer if it stopped working — if the answer is neither party's, nobody's roadmap protects it.

Should I use a native or third-party QuickBooks integration?

Native is usually right for a single object type, one-directional flow, modest volume, or where the vendor's core product depends on the connector working. Third-party becomes worth paying for when you need two-way sync, partial-failure handling, higher volume, or a contractual commitment that someone will fix it.

How do I know if a QuickBooks connector is going to be deprecated?

There's no reliable warning. The clearest signal is release state — a connector still labeled Beta after several years is not on a path to general availability. Beyond that, watch the vendor's release notes, and know your export path in advance so a deprecation is an inconvenience rather than an emergency.

About the author
Keval Padia
Founder & CEO

Founder of Nimblechapps Finance and CEO of Nimblechapps Pvt. Ltd. Eleven years building software and accounting operations for US and UK firms. EA/CPA in progress.

LinkedInLast reviewed: September 30, 2026