Integrating Acumatica to Microsoft Fabric is a more architecturally interesting problem than most mid-market ERP integrations, for a specific and documented reason: Acumatica's built-in SQL data provider does not yet support Entra ID authentication as of 2025 R1, and Microsoft Fabric's SQL endpoints require Entra ID. That single gap shapes every integration approach available. The good news is that Acumatica was designed from the ground up as an API-first cloud ERP - it exposes every business entity through OData and a contract-based REST API - which means there are well-supported paths to OneLake that don't require the SQL data provider at all. This guide covers every viable production path for Acumatica data integration with Microsoft Fabric, what the Entra ID constraint actually means in practice, and the API capabilities that make Acumatica one of the more analytically extensible mid-market ERPs despite the absence of a native Fabric connector.

This is written for data engineers, analytics managers, and solution architects evaluating how to land Acumatica financial, distribution, manufacturing, and CRM data in Microsoft Fabric for Power BI reporting, cross-system analytics, and AI-driven forecasting.

Why Integrate Acumatica with Microsoft Fabric

Acumatica covers a wide operational surface - financial management, distribution, manufacturing, project accounting, field services, and CRM - for mid-market businesses that have outgrown QuickBooks or Sage 50 but don't need SAP's complexity. That breadth is a significant analytical advantage when the data is in Fabric: a single semantic model can join Acumatica's GL transactions, inventory movements, sales orders, and project actuals without any of them requiring a separate pipeline or a separate storage account.

The most common driver for Acumatica to Microsoft Fabric integration is the reporting limit. Acumatica's built-in Generic Inquiry reporting is operationally useful - real-time, security-respecting, no-code - but it runs against the production ERP database, which means heavy analytical queries compete with live transaction processing. Landing Acumatica data in Fabric's Lakehouse removes that contention entirely: Power BI queries run against OneLake, the production Acumatica database is unaffected, and the analytical layer can be extended with data from other systems - a CRM, a marketing platform, a third-party logistics provider - without touching the ERP.

"Acumatica's Generic Inquiry OData interface is genuinely useful for operational Power BI. The moment you need historical trend data at scale, multi-system joins, or AI use cases, you need that data in Fabric - not live-queried from the ERP."

Acumatica's Integration Architecture: What's Available

Acumatica provides two primary API surfaces for data extraction, plus a SQL data provider for internal integrations. Understanding all three - and where each fits - determines the right Fabric integration architecture.

The Entra ID Gap: The Architectural Challenge Every Team Hits

The Entra ID authentication gap is the first obstacle every architect encounters when planning an Acumatica to Microsoft Fabric integration, and it's worth addressing directly before discussing solution paths. Microsoft Fabric's SQL endpoints - the Lakehouse SQL endpoint, Fabric Data Warehouse, and SQL Database in Fabric - support only Entra ID users, service principals, and groups. SQL authentication and Windows authentication are explicitly not supported in Fabric SQL. Acumatica's built-in SQL data provider, as of 2025 R1, does not support Entra ID logins. The two systems speak different authentication languages at the database connection level.

This matters because it eliminates the approach that seems most obvious - pointing Acumatica's SQL data provider at a Fabric SQL endpoint - and forces the integration to go through Acumatica's API layer instead. The community discussion on this topic (July 2025) identified three workarounds: using a middleware driver like CData that bridges Entra ID on behalf of Acumatica; setting up a SQL Managed Instance as a linked server that Acumatica can reach with SQL auth while the MI queries Fabric; or replicating Fabric data into a regular Azure SQL Database that Acumatica can connect to in both directions. For the Acumatica-to-Fabric direction (which is what this guide covers), the API-based paths below are the cleaner architectural choice that don't require the SQL data provider at all.

Path 1 - OData via Generic Inquiries into Fabric Data Factory

The Generic Inquiry OData path is the most accessible entry point for Acumatica to Microsoft Fabric integration - it requires no code in Acumatica, uses a standard OData connector in Fabric Data Factory, and respects all Acumatica security rules automatically. For organisations that already use GIs for operational reporting in Power BI, this is a natural extension.

Path 2 - Contract-Based REST API Pipeline

For organisations that need more control than GI OData provides - specific entity endpoints, large-volume extraction, deleted record tracking, or custom field inclusion - Acumatica's contract-based REST API via Fabric Data Factory's generic REST connector is the recommended path. The API is well-documented, actively maintained (course materials were updated to 2025 R2), and supports the full OData query parameter set for filtering and field selection.

Setting up OAuth 2.0 authentication

Register a connected application in Acumatica under Integrations > Connected Applications. Select the OAuth 2.0 flow, save the client, and copy the Client ID. Add a shared secret and copy the value. In Fabric Data Factory, configure a Web Activity to obtain an OAuth 2.0 bearer token using your client credentials. Store the client secret in Azure Key Vault. Use the bearer token in subsequent REST Copy Activity calls with the Authorization: Bearer {token} header.

Discovering endpoints and entities

Before building extraction pipelines, retrieve the metadata document for your Acumatica instance: GET /entity/Default/{version}/$metadata. This returns every entity, field, and relationship available through the API - it is the most reliable reference for what your specific Acumatica version and customisation layer exposes. Standard endpoints behave consistently across versions, but customisations can introduce entity extensions that only appear in the metadata document for your instance. Validate endpoint behaviour in your specific Acumatica version before building any pipeline against a non-standard entity.

Incremental loads and deleted record tracking

The REST API supports OData-style filtering - use $filter=LastModifiedDateTime gt {watermark} to extract only records changed since the last run. Acumatica also supports tracking deleted records via a dedicated deleted-records endpoint, which is important for maintaining referential integrity in your Lakehouse - a customer deleted in Acumatica should be soft-deleted or flagged in Fabric rather than silently left as an orphan in your dimension tables. Test deleted record behaviour for each entity before going to production.

Path 3 - CData Sync Continuous Replication to OneLake

CData Sync provides automated, continuous Acumatica ERP replication to OneLake in Microsoft Fabric - listed explicitly in CData's integration documentation as a supported source-destination pair. CData Sync connects to Acumatica through the OData and REST API surfaces, handles OAuth token management, schema discovery, incremental change detection, and delivery to OneLake without requiring custom pipeline engineering in Fabric Data Factory.

For the Acumatica to Microsoft Fabric integration specifically, CData Sync addresses the two most operationally burdensome aspects of the API-based paths: authentication management (token refresh, credential rotation) and schema change handling (new custom fields added to Acumatica entities are detected and propagated to OneLake automatically without pipeline updates). CData Sync also resolves the Entra ID authentication gap - CData's middleware handles Entra ID on behalf of the integration, meaning the connection to OneLake is authenticated correctly even though Acumatica's native SQL data provider can't manage it directly.

For mid-market organisations running Acumatica as their primary ERP and building a Fabric analytics estate that includes multiple other source systems, CData Sync eliminates the need to build and maintain individual API pipelines for each system. CData supports Acumatica alongside Sage Intacct, Zoho CRM, NetSuite, and 300+ other sources - making it a viable single integration layer for the full source system portfolio.

Acumatica API Reference for Fabric Data Engineers

Acumatica to Microsoft Fabric: Path Comparison

Power BI Reporting on Acumatica Data in Fabric

Acumatica's OData interface has a documented, native connection to Power BI - Acumatica's own documentation and blog posts describe this as the intended path for Power BI integration. For operational dashboards where data needs to be current to the minute, connecting Power BI Desktop directly to Acumatica's OData feed (via the OData connector in Power BI) against published Generic Inquiries is the standard approach and requires no Fabric involvement.

The value of the Acumatica to Microsoft Fabric path is everything beyond operational dashboards: historical trend analysis against multi-year GL data without impacting production, cross-system reporting joining Acumatica financial data with a CRM or marketing platform, DirectLake mode in Power BI against OneLake for large datasets without import latency, and AI-assisted analytics using Fabric notebooks against Acumatica data. The specific Power BI use cases that unlock once Acumatica is in Fabric include inventory turn analysis over rolling 24-month periods, margin waterfall analysis combining sales orders with actual production costs, customer profitability combining GL AR data with CRM activity history, and project budget variance tracking combining Acumatica project data with time-tracking or HR data.

For Power BI consulting teams building on Fabric, Acumatica's data model - with its clear dimensional structure of entities, branches, projects, and sub-accounts - translates cleanly into a star schema. The primary fact tables are GL transactions and AR/AP line items; the primary dimensions are customer, vendor, inventory item, project, employee, and account. Most Acumatica analytics programmes can build a complete financial semantic model from six to eight core entities.

Common Mistakes in Acumatica to Microsoft Fabric Integrations

Using GI OData for high-volume analytical extraction. Generic Inquiries run against Acumatica's production database. Large OData extractions - millions of rows of GL history - run during business hours compete with live transaction processing and degrade Acumatica's operational responsiveness for users. Schedule large extractions outside business hours, or switch to the DAC-based OData schema or REST API for high-volume workloads.

Attempting to use the Acumatica SQL data provider against Fabric SQL endpoints. This fails because Acumatica's SQL data provider as of 2025 R1 does not support Entra ID authentication, and Fabric SQL endpoints only accept Entra ID. The community workarounds (middleware, SQL MI linked server, Azure SQL replication) each have trade-offs - the API-based paths in this guide are cleaner for the Acumatica-to-Fabric direction.

Building integrations without checking the metadata document for your instance. Standard Acumatica endpoints behave consistently, but any customisation layer adds entities and fields that only appear in the metadata document for your specific instance. Teams that assume the standard schema and miss custom fields discover the gap when finance or operations asks why a key custom field is missing from the Fabric model.

Not testing GI field-level security before publishing OData feeds. Generic Inquiry OData feeds respect Acumatica's field-level access controls - but it is important to audit which fields each published GI exposes and who has access to the OData endpoint URLs. An overly permissive GI that includes payroll or compensation fields exposed via OData is a governance gap that bypasses the intention of Acumatica's role-based security.

Using named user credentials for the integration service account. If the named user's password changes or the account is disabled, the integration fails silently. Always create a dedicated Acumatica service account for the integration with the minimum required permissions, and manage its credentials through Azure Key Vault with a defined rotation policy.

Conclusion

Integrating Acumatica to Microsoft Fabric is well within reach for any organisation with data engineering capacity - Acumatica's open API architecture and its OData and REST API surfaces provide production-grade extraction paths that don't require the SQL data provider and don't hit the Entra ID authentication gap. The key architectural decision is which path fits your volume, latency, and engineering investment: OData via Generic Inquiries for moderate-volume Power BI integration without code; the REST API for high-volume, full-entity, full-control extraction; or CData Sync for continuous replication with automatic schema management and no pipeline engineering.

The outcome - Acumatica's financial, distribution, manufacturing, and project data in OneLake alongside the rest of your estate - unlocks the cross-system analytics and AI use cases that the ERP alone can't support. Numlytics specialises in Microsoft Fabric migration and data engineering for mid-market organisations. Speak with a certified Fabric consultant to scope the right Acumatica integration architecture for your estate.