Back to Blog

Fixing Power BI Errors When Importing Access Databases and Old Excel xls Files

October 7, 2026•7 min read•Michael Ridland

Every few months someone on a client site sends me a screenshot that looks roughly like this: "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine." They've been asked to build a Power BI report from an Access database that's been running the warehouse, the membership list, or the quoting process since about 2007. Or it's a folder of .xls files exported from a legacy system that's never heard of .xlsx.

This happens constantly in Australian businesses. There's a lot of Access out there. Mid-sized manufacturers, councils, clubs, professional services firms - the business logic of a surprising number of organisations lives in an .accdb file on a shared drive. And when someone finally wants dashboards on top of it, Power BI is the obvious tool, and this error is the first wall they hit.

The good news is the cause is almost always the same, and the fix is usually quick once you understand what's going on.

Why this error happens

Power BI Desktop doesn't read Access databases or legacy .xls files by itself. It relies on a separate component called the Microsoft Access Database Engine (often called the ACE provider). Modern .xlsx files are a different story, Power BI can read those natively, but the older binary formats go through ACE.

So when you see a "provider is not registered" error, Power BI is telling you one of two things:

  1. The Access Database Engine isn't installed on this machine at all.
  2. It is installed, but it's the wrong bitness.

The second one is the one that catches people out.

The 32-bit vs 64-bit problem

Power BI Desktop is 64-bit these days. The Access Database Engine comes in 32-bit and 64-bit versions, and a 64-bit application can only use the 64-bit provider. If the machine has the 32-bit engine, Power BI can't see it, and you get the "not registered" error even though, as far as the user is concerned, Access is clearly installed and works fine.

Where does the 32-bit engine come from? Usually Office. For years, the default Office install was 32-bit, and lots of organisations kept that because of old add-ins and VBA macros that didn't play well with 64-bit. If someone installed 32-bit Office (with Access), they got the 32-bit ACE provider along with it.

Then Microsoft's installer won't let you put the 64-bit Access Database Engine alongside 32-bit Office. You run the installer, and it tells you to remove the 32-bit Office products first. This is the bit that makes people want to throw their laptop.

The fixes, in the order I'd try them

1. Install the matching Access Database Engine

If there's no Office on the machine, or Office is already 64-bit, just install the 64-bit Microsoft Access Database Engine redistributable from Microsoft's download centre. Restart Power BI Desktop and try again. In my experience this fixes the majority of cases outright.

Check your Office bitness first. In any Office app, go to File, Account, About, and it'll say 32-bit or 64-bit right at the top. Thirty seconds of checking saves a lot of guesswork.

2. Move Office to 64-bit

If the machine has 32-bit Office, the cleanest long-term fix is to move to 64-bit Office. Microsoft has defaulted to 64-bit for new installs of Microsoft 365 for a while now, and most of the old reasons to stay on 32-bit have faded.

That said, check with whoever owns the machine fleet before you do this. Some organisations still have a crusty Excel add-in or an Access front-end with 32-bit API declarations in the VBA that will break. If that's the case, you need a plan for those before switching. I've seen a finance team lose a full day because a 64-bit Office rollout broke their month-end macro, so this isn't a theoretical risk.

3. Convert the files

For legacy .xls files, honestly the simplest answer is often to stop using .xls. Open them in Excel, save as .xlsx, and Power BI reads them without ACE at all. If they're coming from a system export, see whether the system can export .xlsx or .csv instead. CSV in particular is boring and reliable.

For Access, you can't really "convert" it in the same way, but you can ask a bigger question (see below).

4. The passive install workaround

You'll find forum posts telling you to run the 64-bit Access Database Engine installer from the command line with the /passive switch, which skips the check that blocks installation alongside 32-bit Office. It does often work.

I don't recommend it on anything other than a throwaway machine. Running mixed-bitness Office components side by side isn't a supported configuration, and we've seen it cause odd behaviour in Office afterwards, including Office repair prompts and broken Access installations. If you go this way, know you're on your own if it misbehaves.

Don't forget the gateway

Here's the part people miss. You fix the provider on your laptop, the report works in Desktop, you publish it, and then scheduled refresh fails in the Power BI service.

That's because refresh of an on-premises Access file or .xls goes through the on-premises data gateway, and the gateway machine also needs the 64-bit Access Database Engine installed. The gateway is 64-bit, so the same bitness rules apply. Your laptop being fixed doesn't help the server sitting in the comms room.

Also check that the gateway service account can actually reach the file path. A mapped drive letter like S:\Ops\Warehouse.accdb works on your machine because you're logged in and have the drive mapped. The gateway service doesn't. Use a UNC path (\\fileserver\ops\Warehouse.accdb) in your Power Query source, and make sure the service account has read access to it.

Those two issues, missing provider on the gateway and mapped drive paths, cause more failed refreshes on Access-based reports than anything else we see.

Other things that trip people up

The database is locked. If someone has the Access database open in exclusive mode, Power BI may not be able to read it. Same if a scheduled job is compacting it. Usually it's intermittent, which makes it confusing.

Password-protected databases. Access databases with a database password need the credentials supplied in Power BI. It's doable, but it's another thing to manage on the gateway.

Linked tables. If your Access database is just a front-end with linked tables pointing to SQL Server or another Access file, Power BI may struggle to follow those links. It's usually better to connect directly to whatever the linked tables point at.

File size and performance. Access has a 2 GB file limit and was never designed for analytical queries. If refresh is slow, that's partly just Access being Access.

The bigger question

Getting Power BI to read an Access database is solvable. But I'd encourage you to treat this moment as a prompt rather than just a fix.

If a business-critical process runs on an Access file on a shared drive, you've got some real exposure: one person who understands it, no proper backup strategy, no audit trail, limited concurrent users, and a 2 GB ceiling coming at you eventually. Reporting on it doesn't change any of that.

For a lot of our clients, the path that makes sense is moving the data into Azure SQL, Dataverse or a Fabric lakehouse, then rebuilding the front-end in something like Power Apps. Power BI then connects to a proper source, refreshes reliably in the cloud without a gateway, and the "provider not registered" error becomes a distant memory. Our Power Apps consultants have done quite a few of these Access migrations, and they're usually smaller projects than people expect.

If you just want the reporting sorted, that's fine too. Our Power BI consultants can get your Access or legacy Excel sources working reliably, including the gateway side. And if you're thinking about the broader data platform, our Microsoft Data Factory consultants can help move data out of these older sources on a schedule without needing anyone to touch the files.

Quick checklist

When the error shows up, run through this:

  • Is the Access Database Engine installed at all?
  • Is it 64-bit, matching Power BI Desktop?
  • Is Office 32-bit and blocking the 64-bit engine install?
  • Could the .xls files simply be saved as .xlsx or exported as CSV?
  • Does the gateway machine have the 64-bit engine too?
  • Is the source path a UNC path the gateway service account can read?

Nine times out of ten, one of those is your answer.

Reference: Troubleshoot importing Access and Excel .xls files in Power BI Desktop (Microsoft Learn)