Power Platform Integration with D365 F&O

How Finance uses Power Automate, Power Apps, and Power BI with D365 F&O data—the connection methods that work, the Finance-specific use cases that actually reduce manual effort, the governance model that keeps the Power Platform from becoming uncontrolled shadow IT, and the mistakes that turn a productivity tool into a liability.

The Three Tools—What Each One Actually Does for Finance

Power Automate—Workflow Automation and Integration Flows

Power Automate builds automated workflows that respond to triggers (a form submission, an email arriving, a D365 record reaching a certain state) and execute a sequence of actions (send a notification, update a record, call an API, post to Teams). For Finance, it is most useful for automating repetitive approval routing and notification tasks that D365 workflows don’t handle natively, and for building lightweight integration flows between D365 and adjacent systems.

Power Automate connects to D365 F&O through the Finance and Operations connector (which uses OData entities) and through the Dataverse connector if the Dual-write or Virtual entity integration is configured. The connector supports reading D365 data, creating records, and triggering actions—subject to the same security roles as the service account used to authenticate the connection.

Invoice exception routing: When an AP invoice fails three-way match tolerance in D365, trigger a Power Automate flow that notifies the procurement contact and the AP manager with the match details, tracks the exception in a SharePoint list, and sends a reminder if not resolved within 48 hours
Expense report status notifications: Trigger a Teams or email notification to the employee when their expense report status changes in D365 (submitted, approved, rejected, paid)—a visibility gap D365 doesn’t fill natively
Journal import automation: On a schedule, pull a payroll file from a SharePoint folder or SFTP location, transform it to the D365 journal import format, and trigger the Data Management import job via the D365 OData API
Budget variance alert: On a weekly schedule, query D365 financial dimensions and budget data, calculate variance by department, and send a summary to department heads whose actual-to-budget variance exceeds a defined threshold
Vendor onboarding workflow: When a new vendor request form is submitted via a Power Apps form, route for Finance approval, create the vendor record in D365 via the Vendor entity when approved, and notify AP that the new vendor is available

Power Apps—Custom Forms and Mobile Interfaces on D365 Data

Power Apps builds lightweight canvas or model-driven applications that surface D365 data in custom interfaces—typically for use cases where the full D365 F&O client is too complex for occasional users, or where a mobile-friendly interface is needed for a field-based process. Finance uses Power Apps most effectively for data collection from non-Finance users that feeds into D365 workflows.

Power Apps connects to D365 F&O through the same OData and Dataverse mechanisms as Power Automate, and can read and write D365 data subject to the service account’s security role. Canvas apps are most common for Finance use cases: a form-based interface that non-technical users interact with on a tablet or phone, writing data to D365 or to a Dataverse table that D365 consumes.

Fixed asset disposal request form: Department managers submit asset disposal requests through a Power App on their phone. The app captures asset ID (scanned via QR code), disposal reason, and estimated value. The request routes through Power Automate for Finance approval, then creates the disposal transaction in D365 Fixed Assets when approved
Vendor request form for non-Finance staff: Procurement coordinators submit new vendor requests through a simple Power App form (vendor name, address, payment terms, tax ID, banking details) that routes for Finance review rather than giving them direct access to the D365 vendor master
Petty cash or small purchase capture: Field employees submit small expense reimbursements through a Power App with receipt photo capture. The app writes to a Dataverse table; a nightly Power Automate flow batches approved submissions into a D365 expense journal import
Audit confirmation tracker: During audit season, Finance uses a Power App to track confirmation responses from customers and vendors—logging receipt date, amount confirmed, and exceptions—surfacing the status to the audit team without requiring auditor access to D365

Power BI—Analytics and Reporting on D365 Financial Data

Power BI builds interactive reports and dashboards on D365 data, enabling Finance to analyze financial results beyond what Financial Reporter and standard D365 reports provide. Power BI connects to D365 F&O through DirectQuery or import mode via OData feeds, the D365 content packs available in the Power BI service, or through an Azure Data Lake or Dataverse export of D365 data for larger data volumes.

The distinction between Financial Reporter (the accounting-grade financial statement tool covered in Post 18) and Power BI is important: Financial Reporter is the tool for auditable, GAAP-formatted financial statements. Power BI is the tool for operational analytics, trend analysis, departmental dashboards, and the kind of slice-and-dice exploration that financial statements don’t support. Both have a role; neither replaces the other.

AP aging and payment analytics: Days payable outstanding trend, vendor payment timing by vendor category, early payment discount capture rate, AP liability aging by department and entity—analytics that the standard D365 AP aging report provides in snapshot but not in trend
AR collection performance dashboard: DSO trend, collection effectiveness index by collector and customer segment, aging bucket movement month over month, expected collections vs. actual collections—the kind of operational visibility that drives collections team performance
Budget vs. actual with drill-through: Consolidated budget variance by department with drill-through to individual GL transactions. Finance managers explore variances down to the transaction level without needing D365 access or knowing how to run a Financial Reporter report
Cash flow actual vs. forecast: Visualizing the actual bank position versus the weekly forecast for the trailing 12 weeks, with a breakdown of where forecast errors occurred (AR timing, payroll, vendor payment acceleration)
Fixed asset utilization and depreciation projection: Asset portfolio by category, age, and remaining useful life. Depreciation expense projection for budget planning. Fully depreciated but still-in-service assets flagged for retirement review

The Connection Methods—How Power Platform Reaches D365 Data

OData Entities (Finance and Operations Connector)

The primary connection method for Power Automate and Power Apps. D365 F&O exposes data through OData endpoints for each data entity. The Finance and Operations connector uses a service account with D365 security role access to read and write via these endpoints. Performance is acceptable for transactional flows and small data sets; OData is not suited for large-volume analytical queries.

Dataverse / Virtual Tables

D365 F&O data can be surfaced in Dataverse as virtual tables, enabling Power Platform tools to read D365 data through the Dataverse connector without a separate D365 security account per user. Virtual tables read live from D365 on query but don’t store data in Dataverse. Requires Dual-write or Finance and Operations virtual entity configuration.

Azure Data Lake / Synapse Link

For Power BI analytical workloads requiring large data volumes, D365 F&O can continuously export data to Azure Data Lake Storage via Synapse Link for Dataverse. Power BI connects to the Data Lake rather than querying D365 directly—dramatically better performance for large datasets. Requires Azure infrastructure but is the recommended architecture for enterprise-scale Power BI on D365 financial data.

D365 Power BI Content Packs

Microsoft publishes pre-built Power BI content packs for D365 F&O covering standard Finance scenarios: Financial Performance, CFO Overview, AP, AR, Fixed Assets. The content packs use OData connections to D365 entities and provide a starting point that Finance can customize. They are useful for rapid deployment of standard analytics but require adaptation to match the organization’s chart of accounts structure and reporting hierarchy.

Five Mistakes That Turn Power Platform into a Finance Control Problem

⚠️ A Power Automate Flow Automates Invoice Approval Without Finance Knowing It Exists

An AP clerk who attended a Power Platform training builds a Power Automate flow that auto-approves vendor invoices under $500—eliminating the approval workflow for small invoices to reduce the AP manager’s approval queue. The flow uses the AP clerk’s own D365 credentials via a personal connection. It has been running for eight months. During the annual internal audit, the auditor reviews the AP approval workflow and finds $284,000 of invoices that were approved without a human review step. The invoices were legitimate—but the control that was supposed to verify they were legitimate was bypassed by a tool that nobody in Finance management knew existed. The audit finding is a control gap: invoices were approved by an automated process without documented Finance authorization to run that process.

Fix: Power Platform solutions that affect financial workflows, financial data, or financial controls must be inventoried, reviewed, and formally approved by Finance management before they are deployed in production. The governance model: all Power Automate flows and Power Apps that connect to D365 financial data are registered in a solution inventory. Each solution has a named Finance owner (not just the person who built it). New solutions require Finance manager or controller approval before deployment. The service account or user connection used by each solution has a security role that is documented and reviewed in the quarterly user access review. “Someone built it and it was useful” is not a control approval. Treat every Power Platform financial solution like any other financial system change: change management, documentation, testing, and approval.

⚠️ The Power BI Report Uses Stale Data and Finance Presents It to the CFO as Current

Finance builds a Power BI budget vs. actual dashboard that connects to D365 via an OData import connection. The data refreshes on a scheduled basis—the refresh was set to weekly when the report was built to avoid hitting OData rate limits. Three months after the report is published, the refresh schedule slips: the scheduled refresh fails once without notification, the next refresh is skipped, and by the time Finance presents the dashboard in the monthly board meeting, the data is 23 days old. The budget variance numbers don’t match the Financial Reporter output that the CFO separately reviewed before the meeting. The CFO asks which number is correct. The answer is Financial Reporter—but the explanation of why the Power BI dashboard is wrong takes ten minutes of the board presentation.

Fix: Every Power BI report used for Finance decision-making must have a clearly visible data-as-of date displayed on the report itself—not buried in a tooltip or dataset properties. Configure Power BI alert notifications for refresh failures so Finance knows within hours when a scheduled refresh does not complete. For reports used in management or board presentations, confirm the data-as-of date is current before the meeting—not after. For analytical use cases where data freshness is critical, evaluate DirectQuery mode (reads D365 data live at query time) or the Synapse Link architecture instead of scheduled import. A stale-data disclosure after presenting to the board is an avoidable credibility problem.

⚠️ The Power Platform Solution’s Service Account Has System Administrator Access

When the Power Automate flow was built, the developer used a D365 service account to authenticate the Finance and Operations connector. For convenience during development, the service account was given system administrator access in D365—it made testing easy. At go-live, nobody removed the system administrator role from the service account. The flow runs with unrestricted D365 access. Any data the flow reads, any record it creates, any entity it calls is performed with system-level permissions. If the flow is misconfigured, compromised, or modified by someone with access to the Power Automate environment, it can create, modify, or read any financial record in any legal entity in D365 without restriction. From an audit perspective, every action taken by the flow is logged under a service account with administrator access—indistinguishable from an administrator performing the same actions manually.

Fix: The service account used by every Power Platform connection to D365 must have the minimum security role necessary to perform the specific actions the solution requires—exactly as any D365 user account would. A flow that reads AP invoice data needs read access to the AP invoice entity and nothing else. A flow that creates vendor records needs create access to the vendor entity. If the flow needs to read from multiple entities, define a custom role that grants exactly those permissions. Document the service account’s role assignment and include it in the quarterly user access review. System administrator access is never the right role for a service account running automated flows.

⚠️ Power BI Numbers Don’t Match Financial Reporter Numbers—Nobody Knows Which Source to Trust

The Finance team uses both Financial Reporter for formal financial statements and a Power BI dashboard for operational variance analysis. Both pull from D365 data, but the totals never quite match. The Power BI report shows Q3 revenue at $14.2M. Financial Reporter shows $14.4M. The $200,000 difference is never explained. Finance stops using the Power BI dashboard for anything that will be compared to Financial Reporter because “the numbers are different.” The investment in the Power BI dashboard is effectively wasted; Finance reverts to Excel for any analysis that requires reconciling to the financial statements. The root cause: the Power BI data model uses a different account range filter than Financial Reporter’s row definition, excluding a revenue account added six months after the Power BI model was built.

Fix: Power BI Finance reports must be validated against Financial Reporter at each account category level before they are deployed for operational use, and revalidated whenever the D365 chart of accounts changes. The validation process: run the Financial Reporter income statement and the Power BI report for the same period. Compare totals at the revenue, COGS, gross margin, and operating expense levels. Any difference requires root cause identification before the Power BI report is used. When a Power BI report is validated as reconciling to Financial Reporter, document the validation and the account mapping logic used. When accounts are added to the chart of accounts, the Power BI data model must be updated. Include Power BI model updates in the chart-of-accounts change management process—not as an afterthought.

⚠️ The Power Platform Solution Owner Leaves the Organization—Nobody Knows How It Works

A Finance analyst builds a Power Automate flow over four months that automates the weekly cash forecast update: pulling AR aging from D365, pulling bank balances from the bank’s API, layering in the payroll amounts from SharePoint, and producing a formatted cash position summary in Teams. It is genuinely useful. The analyst is promoted and moves to a different department. Six months later the flow begins failing—the bank’s API updated its authentication method. Nobody in Finance knows how the flow works well enough to fix it. The service account password has expired. The Teams channel where outputs were posted was archived. The cash forecast process reverts to the manual Excel model for three months while IT investigates the flow. The “automation” created a single point of failure that was more fragile than the manual process it replaced.

Fix: Every Power Platform solution used in Finance must have technical documentation that is maintained independently of the person who built it—stored in a shared location (SharePoint, Confluence, or similar) accessible to Finance management. The documentation covers: what the solution does, what triggers it, what D365 entities it reads or writes, what external systems it connects to, what service account or credentials it uses, and what the expected output looks like when it works correctly. Solutions must have a backup owner—a second person who understands how the solution works and is capable of diagnosing failures. When the primary owner leaves, the backup owner takes over before the solution runs unattended. The same offboarding checklist that covers D365 user access should cover ownership of any Power Platform solutions the departing employee owned.

Do This / Don’t Do This

Do This

Inventory every Power Platform solution that touches D365 financial data or automates a Finance process—named owner, purpose, service account role documented
Apply minimum-necessary security roles to every service account used by Power Platform connections to D365
Validate Power BI Finance reports against Financial Reporter at each account category level before deployment
Display a data-as-of date on every Power BI Finance report and configure refresh failure alerts
Require Finance manager or controller approval before any Power Platform solution that affects a financial control is deployed
Document every Power Platform Finance solution technically, stored independently of the builder
Include Power Platform solution ownership in the employee offboarding checklist
Revalidate Power BI data models whenever the D365 chart of accounts changes

Don’t Do This

Allow Power Automate flows to automate financial approval steps without Finance management authorization and documentation
Give service accounts system administrator access in D365 for convenience during Power Platform development
Present Power BI financial data in management meetings without confirming the refresh is current
Tolerate a known discrepancy between Power BI and Financial Reporter without a documented root cause and resolution timeline
Allow Power Platform Finance solutions to exist without a named backup owner who understands how they work
Build Power Automate flows using personal user credentials rather than a dedicated service account
Treat low-code solutions as outside the financial control environment—they are not

Up Next:

Planning Optimization and Master Planning in D365 F&O—what Planning Optimization actually does versus the deprecated built-in master planning engine, how supply and demand planning decisions ripple into inventory valuation, purchase commitment accounting, and working capital, and the Finance visibility into planned order recommendations that keeps supply planning from becoming a black box with unpredictable financial consequences.

— Bobbi

D365 Functional Architect · Recovering Controller