D365 Finance Invoice Capture: From Installation to Invoice Posting

Accounts payable teams usually spend a surprising amount of time on activities that do not add much business value. Supplier invoices arrive by email, shared mailbox, scanned PDF, file upload, or sometimes through different regional processes. Someone in AP has to open the document, read the supplier details, identify the legal entity, validate the invoice number and date, check the purchase order, match product receipts, enter lines, resolve exceptions, submit the invoice to workflow, and finally post it.

Microsoft Invoice Capture for Dynamics 365 Finance is designed to reduce that manual effort. It uses document recognition to extract invoice information from digital invoice images and then transfers that information into Dynamics 365 Finance for vendor invoice processing. Microsoft describes Invoice Capture as a solution that automatically creates vendor invoices from digital invoice images.

The important point is this: Invoice Capture is not just OCR. OCR is only the first step. A successful implementation depends on legal entity onboarding, vendor synchronization, field mapping, configuration groups, vendor invoice automation, product receipt matching, workflow, and posting controls.

This blog walks through the full journey from installation to invoice posting, with practical lessons that matter in a real D365 Finance implementation.

What Invoice Capture Actually Does

Invoice Capture sits at the front end of the vendor invoice process. It reads the supplier invoice document, extracts the relevant values, lets users review or correct the captured data, and then transfers the invoice into Dynamics 365 Finance.

A simple process flow looks like this:

Invoice document received → Invoice captured → Fields extracted → User review → Derivation and validation → Transfer to D365 Finance → Vendor invoice automation → Workflow → Posting

The captured invoice can include header details such as vendor, invoice number, invoice date, due date, currency, purchase order number, subtotal, tax, and invoice total. Depending on the configuration and invoice type, it can also support line level processing.

The workspace includes a side by side viewer where the raw invoice document and the extracted invoice fields are displayed together. Microsoft states that this viewer uses form recognition technology to extract information from the document and connect the captured fields back to the source invoice image.

This is useful because AP users do not need to jump between the PDF and D365 screens. They can review the invoice image and the extracted fields in the same workspace.

Installation of Invoice Capture

Invoice Capture is installed from Microsoft Marketplace into the Power Platform environment that is connected to Dynamics 365 Finance. Microsoft’s installation guidance states that administrators search for Invoice Capture for Dynamics 365 Finance in Marketplace, install the solution, and then complete setup activities such as managing legal entities and vendors after installation.

After installation, the solution appears in Power Apps. This is where some of the Invoice Capture administration is performed, while other setup activities are completed inside Dynamics 365 Finance.

This split is important. Many implementation issues happen because teams assume that installing the solution is enough. It is not. Installation only makes the application available. The actual business readiness comes from configuration.

The environment must know which legal entities can use Invoice Capture, which vendors should be synchronized, how invoices should be classified, how fields should be mapped, and how the transferred invoice should be processed inside D365 Finance.

Legal Entity Onboarding

One of the first setup activities is legal entity onboarding.

In D365 Finance, each company or legal entity has its own transactions, vendors, purchase orders, financial dimensions, number sequences, posting setup, and security access. Invoice Capture must be configured for the legal entities that will use the service.

If a legal entity is not onboarded, the invoice may be captured successfully but fail later during derivation, validation, or transfer. This is a common troubleshooting point. The document recognition may work perfectly, but the system cannot complete the business process because the target company was never enabled for Invoice Capture.

For example, assume your D365 environment has the following companies:

USMF
DEMF
GB01

If Invoice Capture is configured only for USMF, an invoice belonging to GB01 may fail with a message indicating that the legal entity has not been onboarded. In that case, the issue is not the invoice image, vendor, or PO. The issue is company level onboarding.

Microsoft’s configuration guidance specifically refers to the Invoice Capture setup page in Dynamics 365 Finance and includes legal entity and vendor synchronization activities.

From a consultant perspective, legal entity onboarding should always be treated as a mandatory checklist item. Every company expected to process invoices must be confirmed before end to end testing begins.

Vendor Synchronization

After legal entities are onboarded, vendor synchronization becomes the next critical step.

Invoice Capture has to identify which vendor the invoice belongs to. It does this by comparing captured supplier information against vendor records from Dynamics 365 Finance. If vendors are not synchronized, the invoice may remain in review, fail derivation, or require manual correction.

Vendor synchronization is not only about vendor name. The system may use information such as vendor account, tax registration, address, bank information, and other supplier identifiers depending on the available data and mapping rules.

Microsoft’s configuration documentation notes that an Accounts payable administrator can initiate vendor synchronization manually or enable real time synchronization from Accounts payable > Setup > Invoice capture.

This becomes especially important in multi entity environments. A vendor may exist in one legal entity but not another. A supplier invoice may be valid for DEMF, but if that vendor account is not available or synchronized for DEMF, the invoice will not derive correctly.

A good implementation approach is to test vendor synchronization with different supplier types:

• A standard PO vendor
• A non PO expense vendor
• A vendor shared across companies
• A vendor with similar names or duplicate records
• A vendor with tax registration details

This helps validate whether Invoice Capture can identify vendors reliably before the solution goes live.

Configuration Groups

Configuration groups are one of the most important concepts in Invoice Capture because they help control how invoices are validated, displayed, and transferred.

In practical terms, a configuration group defines how Invoice Capture should behave for a group of invoices. It can influence what fields appear in the side by side viewer, what validations are applied, and how the invoice is processed before transfer.

Microsoft explains that configuration groups determine validation logic, the fields shown in the side by side viewer, and, together with Dynamics 365 Finance setup, the recipient API that is called, such as pending vendor invoice or invoice journal.

This is where the solution starts becoming more than simple document extraction.

For example, one configuration group may be used for PO based invoices. Another may be used for non PO invoices. Another may be used for specific suppliers or specific document layouts.

The configuration group should match the business process. If your business expects PO invoices to bring lines from purchase orders and product receipts, the setup should support that path. If your business expects non PO invoices to be coded manually to procurement categories or ledger accounts, that needs a different design.

A common mistake is treating all invoices the same. In reality, a PO invoice and a non PO invoice follow different business logic inside D365 Finance.

Mapping Rules

Mapping rules help Invoice Capture derive the right values from the invoice and map them into D365 Finance.

A good example is legal entity mapping. If the invoice contains the company name, address, or tax registration number, mapping rules can help identify the correct legal entity. Microsoft’s documentation gives an example where the legal entity code is identified using company name, address, and tax registration number.

This matters because suppliers do not always print the legal entity code on the invoice. They may print the company name, VAT number, branch address, or billing address. Mapping rules allow the system to interpret that information.

The same thinking applies to vendor identification and other derived values. The more consistent the supplier invoices are, the easier it is for the system to derive accurate results. The more variation there is, the more important mapping rules become.

In a real implementation, mapping rules should be tested with actual supplier invoices, not only sample documents. Supplier invoices often contain unexpected formats, abbreviations, address variations, missing PO numbers, or different tax layouts.

Header Only Invoices

A header only invoice is an invoice where the system captures the main invoice header but does not create detailed invoice lines.

The header may include:

• Vendor
• Invoice number
• Invoice date
• Due date
• Currency
• Invoice amount
• Tax amount
• Purchase order number

But the line section may remain blank.

This behavior is not always wrong. Some businesses intentionally allow invoices to be imported without derived lines so AP users can complete coding manually. However, in an automation scenario, blank lines can also indicate that the system failed to derive the PO, product receipt, procurement category, or line details.

One parameter that affects this behavior is Allow invoice to be imported with no derived lines. When this is enabled, the invoice can be imported even if no lines were automatically derived. When disabled, the invoice is stopped earlier so the issue can be corrected before transfer.

This parameter is useful, but it should be used carefully. During testing, enabling it can make the process look successful because the invoice header is created. However, if your goal is full PO based automation, it may hide the real problem: the system did not derive the invoice lines.

A practical recommendation is to disable this during early PO invoice testing. That way, missing line derivation becomes visible immediately.

PO Based Invoices

PO based invoices are different. In this scenario, the supplier invoice should be connected to a purchase order in D365 Finance.

The ideal process is:

• Supplier sends invoice with PO reference.
• Invoice Capture reads the PO number.
• D365 Finance finds the purchase order.
• The system derives the PO lines.
• If product receipts exist, the invoice can be matched against received quantities.
• The invoice is validated, submitted to workflow, and posted.

This is where the real value of AP automation appears. The AP user does not need to manually type every line from the supplier invoice if the purchase order and product receipt already exist in D365.

For this to work, the invoice must be recognized as a PO based invoice. If the invoice is imported as a generic header only invoice or non PO invoice, product receipt matching will not apply.

A key troubleshooting message is:

Match product receipt to invoice line: Not applicable

This usually means the invoice line is not recognized as a PO linked line. In other words, D365 does not see the line as something that can be matched to a posted product receipt.

This can happen when:

• The PO number was not captured.
• The PO number was captured but not derived.
• The invoice was classified as non PO.
• The line was created as a generic category line.
• The product receipt does not exist.
• The vendor on the invoice does not match the PO vendor.
• The invoice line is not connected to the purchase order line.

The fix is not simply enabling product receipt matching. The invoice must first be correctly tied to the purchase order.

Product Receipt Matching

For many organizations, the goal is not to bring lines from the supplier invoice image. The goal is to bring lines from the product receipt.

This is a better control model for PO based invoices. The product receipt represents what the business has actually received. The supplier invoice should then be matched against those received quantities.

Microsoft’s vendor invoice automation setup includes parameters for automatically matching posted product receipt lines to pending vendor invoice lines. These settings are found on the Vendor invoice automation tab of Accounts payable parameters.

There is also Microsoft guidance explaining that imported vendor invoices can be submitted to workflow and that posted product receipt lines can be automatically matched to vendor invoices.

The important parameter here is usually described as Automatically match product receipts to invoice lines or similar depending on version.

When enabled, D365 Finance attempts to automatically match the invoice lines to posted product receipts. But it only works when the invoice is already PO based and the lines are eligible for receipt matching.

The required conditions are:

• The invoice must be linked to a purchase order.
• The product receipt must already be posted.
• The invoice vendor must match the purchase order vendor.
• The invoice line must be linked to the PO line.
• The matching policy must allow receipt matching.
• The received quantity must be available for invoicing.

If these conditions are not met, the automation may not run, or it may show as not applicable.

This is one of the most important design decisions in the full implementation. If the business wants product receipt based invoice creation, the test cases should include real purchase orders and real posted product receipts.

Vendor Invoice Automation Parameters

Invoice Capture transfers the invoice into Dynamics 365 Finance, but vendor invoice automation controls many of the downstream processing steps.

The key setup area is:

Accounts payable > Setup > Accounts payable parameters > Vendor invoice automation

Microsoft’s vendor invoice automation workspace documentation refers to this setup and specifically mentions enabling automatic workflow submission and automatic matching of product receipts to invoice lines.

Important parameters include:

Automatically submit imported invoices to workflow

This allows imported invoices to move into workflow automatically after successful import and validation. Without this, users may need to submit invoices manually.

Automatically match product receipts to invoice lines

This allows the system to match posted product receipts to pending vendor invoice lines. It is especially important for PO based invoice automation.

Allow invoice to be imported with no derived lines

This allows the invoice header to be imported even when the system cannot derive lines. It can be useful for manual AP completion, but it can also hide derivation issues during testing.

Background automation settings

Vendor invoice automation uses background processes. If an invoice appears stuck, batch jobs and automation history should be reviewed before assuming the invoice itself is wrong.

These parameters should not be configured blindly. They should be aligned with the customer’s AP operating model.

A customer that wants strict automation may prefer to stop invoices when lines cannot be derived. A customer that wants AP users to complete invoices manually may prefer to import incomplete invoices and correct them later.

Invoice Journals, Pending Vendor Invoices, and Posting Route

Another area that causes confusion is where the captured invoice goes after transfer.

In D365 Finance, vendor invoices can be processed through different pages and processes, including pending vendor invoices, invoice journals, invoice registers, and invoice approval journals. Microsoft’s vendor invoice overview explains that invoices can be entered or received electronically and then reviewed and approved using invoice approval journals or the Vendor invoice page, with invoice matching, policies, and workflow used to automate review.

Invoice Capture configuration groups and D365 setup influence the transfer route. Some implementations use pending vendor invoices. Others may use an invoice journal or invoice register style process depending on the configuration.

A journal name can also be misleading. For example, a journal called CRED does not automatically mean credit note. It may simply be a legacy name meaning creditor invoice recording journal. The journal name is a label. The real setup is controlled by the journal type, posting setup, and AP parameters.

If an invoice posts through an unexpected journal name, the first thing to check is not the name itself. The first thing to check is the journal name setup and the default parameters that selected it.

Workflow and Approval

Once the invoice has been transferred and validated, it may need to go through workflow.

Workflow is where the business applies approval rules. These rules may depend on vendor, amount, financial dimensions, procurement category, requester, purchase order, legal entity, or other criteria.

If automatic workflow submission is enabled, imported invoices can be submitted without the AP user manually clicking submit. If it is not enabled, invoices may wait for manual submission.

This is where users sometimes think Invoice Capture is stuck. In reality, the invoice may already be imported but waiting for workflow action.

A proper troubleshooting approach is to check:

• Invoice status
• Workflow status
• Automation history
• Validation messages
• Batch jobs
• Pending vendor invoice details
• Matching details

This gives a better picture than only looking at the capture result.

Posting the Vendor Invoice

Posting is the final stage, but it depends on all previous stages being correct.

Before posting, D365 Finance must have enough information to create valid accounting entries. That means the invoice must have a vendor, legal entity, invoice number, invoice date, currency, amount, lines, tax information, posting profile, financial dimensions, and valid matching results if it is PO based.

For PO based invoices, posting also depends on purchase order and product receipt matching. If the business uses three way matching, D365 checks the purchase order, receipt, and invoice before posting.

For non PO invoices, posting depends more on coding, financial dimensions, tax, workflow approval, and AP controls.

The posting process is where many hidden setup issues appear. An invoice may capture successfully and transfer successfully but still fail during posting because of a missing financial dimension, blocked vendor, invalid tax group, missing number sequence, workflow issue, or user security problem.

This is why end to end testing should always include final posting. A test that stops at capture is incomplete.

Common Issues During Implementation

The most common Invoice Capture issues are usually not OCR issues. They are configuration, master data, or process issues.

• User not found in Finance and Operations

This means the user exists in Microsoft Entra ID but does not exist as a user in D365 Finance, or does not have the required access. The fix is to import the user into D365 Finance and assign the required security roles and legal entity access.

• Legal entity not onboarded

This means the company is not enabled for Invoice Capture. The invoice may capture successfully but fail during derivation or transfer.

• Vendor not derived

This usually means the vendor was not synchronized, the vendor data does not match the invoice, or the supplier has duplicate or inconsistent records.

• Invoice imported with no lines

This can happen when no lines are derived and the system allows header only import. For PO automation, this usually means the PO or receipt matching path was not completed.

• Product receipt matching not applicable

This usually means the invoice is not recognized as a PO linked invoice line. The system cannot match receipts to a generic or non PO line.

• Invoice stuck in deriving or validating

This usually points to missing or incorrect master data, mapping rules, mandatory fields, vendor identification, legal entity identification, or validation rules. Microsoft’s workspace documentation describes statuses such as In review, Verified, and Transferring, and explains that invoices move through review and transfer stages in the workspace.

• Invoice stuck after transfer

This should be checked in D365 Finance automation history, workflow status, and batch jobs. The capture may be complete, but vendor invoice automation may be waiting or failing downstream.

• Wrong journal selected

This is often caused by AP parameter setup, journal name defaults, configuration group behavior, or legacy naming. Do not assume a journal called CRED means credit note.

When implementing Invoice Capture, do not start by focusing only on OCR accuracy. Start with the business process.

First, decide which invoice types are in scope. PO invoices and non PO invoices should be treated separately. Then decide whether invoices should be imported if no lines are derived. Then decide whether product receipts should be matched automatically. Then validate whether workflow should be submitted automatically.

Second, keep legal entity onboarding and vendor synchronization clean. Many failures come from missing company setup or unsynchronized vendors.

Third, use real supplier invoices during testing. Sample invoices are useful for early validation, but production invoices reveal real formatting and master data problems.

Fourth, test all the way to posting. A captured invoice is not a completed business process. The real test is whether the invoice posts correctly with the expected accounting, matching, tax, and workflow behavior.

Finally, make sure AP users understand the difference between capture errors, derivation errors, validation errors, transfer errors, workflow delays, and posting errors. These are different stages, and each one has a different troubleshooting path.

 

Adyen Payment Successful but Sales Order Not Created in Dynamics 365 Commerce

How to handle the 3DS flow issue in Dynamics 365 Commerce

In Dynamics 365 Commerce, one of the most sensitive areas in an online checkout process is the payment flow. A payment may appear successful in the payment provider portal, but the actual sales order may not always be created in Commerce if the final checkout response is not processed correctly.

This issue can become critical when customers are charged through Adyen, but the corresponding sales order is not created in Dynamics 365 Commerce. The customer sees a successful payment, but the retailer does not receive a confirmed order to fulfill.

A known Microsoft issue related to this behavior is available in Lifecycle Services:

https://fix.lcs.dynamics.com/Issue/Details?bugId=978743

This issue is related to the Adyen connector and the 3DS flow, where early payment authorization can happen before the Commerce checkout process has fully completed the order creation step.

The typical symptom

You may see the following behavior:

The customer completes checkout.

The payment is authorized or captured in Adyen.

The 3DS authentication is completed.

No order confirmation ID is generated in Dynamics 365 Commerce.

No sales order is created.

The payment exists in Adyen, but Commerce has no matching order.

This creates a payment and order mismatch, which is risky for customer service, finance reconciliation, and fulfillment teams.

Why this happens

In a 3DS payment flow, the customer may be redirected or challenged for authentication. After authentication is completed, the payment provider sends the final response back to the Commerce checkout flow.

If the payment is authorized but the final response is delayed, interrupted, or not processed correctly, Commerce may not complete the sales order creation step.

This is why the issue is not always visible in normal testing. It may occur more often in low network conditions, interrupted browser sessions, timeout scenarios, or specific 3DS redirect flows.

What to do if you face this issue

1. Confirm the payment status in Adyen

Start by checking the transaction in the Adyen portal.

Validate the following:

Payment status.

PSP reference.

Merchant reference.

Authorization result.

Capture status.

3DS result.

Do not assume the payment failed just because the sales order is missing in Commerce. First confirm whether Adyen successfully authorized or captured the payment.

2. Check whether the order confirmation ID was generated

In Dynamics 365 Commerce, review whether an order confirmation ID was generated for the checkout.

If the payment exists in Adyen but there is no order confirmation ID, the problem is likely between the final payment response and the Commerce order creation process.

This is the key point where the investigation should focus.

3. Review the Microsoft known issue in LCS

Search and review the following Microsoft known issue in Lifecycle Services:

https://fix.lcs.dynamics.com/Issue/Details?bugId=978743

This issue is relevant to the Adyen connector and the 3DS early authorization flow.

If your symptoms match this issue, you should use it as the reference point while reviewing your Commerce version, Adyen connector version, and available fixes.

4. Contact Adyen to confirm the 3DS flow setup

Work with Adyen to confirm that your 3DS configuration is correctly enabled and aligned with Dynamics 365 Commerce requirements.

Ask Adyen to validate:

Whether 3DS is enabled for your merchant account.

Whether the correct 3DS flow is active.

Whether the redirect and response URLs are configured correctly.

Whether the merchant account is using the expected payment method setup.

Whether the final response is being returned correctly after authentication.

Whether there are any failures, retries, or timeout events on Adyen’s side.

This step is important because the payment may be successful in Adyen, but Commerce still depends on the correct final response to complete the order.

5. Validate the Adyen connector version

Check the Adyen connector version being used in your Dynamics 365 Commerce environment.

If you are using an older connector version, review whether Microsoft or Adyen has recommended an update for the 3DS flow issue.

Make sure the connector version is compatible with your Commerce version and your payment configuration.

6. Enable Application Insights logging

Enable Application Insights for your Commerce environment so you can capture better telemetry around checkout failures.

This helps identify:

Failed checkout requests.

Missing final payment responses.

Exceptions during order creation.

Timeouts.

Cart completion issues.

Payment response handling errors.

Without telemetry, it is difficult to prove where the process failed. Application Insights gives visibility into the actual checkout flow instead of relying only on Adyen transaction status.

7. Test the scenario in UAT

Before applying any change in production, reproduce and validate the behavior in UAT.

Test the following scenarios:

Normal card payment.

3DS authenticated payment.

Low network condition.

Browser refresh during checkout.

Browser close after payment authorization.

Delayed response from the payment page.

Multiple retry attempts.

The goal is to confirm that payment authorization and order creation remain aligned.

8. Apply the recommended fix or configuration change

Based on the LCS issue, your Commerce version, and Adyen’s confirmation, apply the recommended fix or configuration changes.

This may include:

Updating the Adyen connector.

Applying a Microsoft hotfix or quality update.

Correcting 3DS configuration.

Updating payment method setup.

Adjusting response handling configuration.

Improving monitoring through Application Insights.

The exact correction depends on your environment version and payment setup, so it should be validated carefully before production rollout.

9. Validate end to end order creation

After applying the fix, perform full checkout testing.

Confirm that:

Payment is authorized in Adyen.

3DS authentication completes successfully.

Final response returns to Commerce.

Order confirmation ID is generated.

Sales order is created.

Payment reference is traceable.

The order can move forward to fulfillment.

The issue should only be considered resolved when both payment and order creation are completed successfully.

Key takeaway

If Adyen shows a successful payment but Dynamics 365 Commerce does not create the sales order,  Investigate the 3DS flow, final payment response, connector version, and Commerce order creation process.

The Microsoft LCS issue below should be reviewed when facing this behavior:

https://fix.lcs.dynamics.com/Issue/Details?bugId=978743

The most important correction path is to validate the 3DS setup with Adyen, review the applicable Microsoft fix, enable Application Insights, test the flow in UAT, and then apply the correction in production.

In Commerce payment processing, the transaction is only truly successful when both the payment and the sales order are created correctly.

Dynamics 365 Capabilities That Show the Real Business Value of AI Automation

For many organizations, ERP transformation is still treated as a system replacement exercise. New screens. New workflows. New reports. New integrations. But the real value of modern ERP is not just replacing legacy systems. The real value comes when the system starts reducing manual effort, predicting business risk, improving decision making, and helping users act faster.

This is where Dynamics 365 Finance and Operations, together with Dynamics 365 Supply Chain Management, Dynamics 365 Project Operations, Copilot, and AI agents, is becoming much more than a transactional platform. It is becoming an intelligent business operations platform.

The features below are not random AI concepts. These are practical Dynamics 365 capabilities that businesses can evaluate when they want to create measurable value from automation, finance modernization, and supply chain transformation.

1.       Invoice Automation and Invoice Capture

Accounts payable is one of the best starting points for automation because invoice processing is repetitive, document heavy, and often dependent on manual validation. Dynamics 365 Finance provides vendor invoice automation capabilities that help streamline vendor invoice processing, including imported invoices, workflow submission, product receipt matching, and touchless processing scenarios. Microsoft describes automated vendor invoice processing as a capability designed to improve the efficiency of vendor invoice handling, and it applies to vendor invoices rather than invoice journals or invoice register journals.

Invoice Capture takes this one step further by automatically creating vendor invoices from digital invoice images. Instead of manually keying invoice details, businesses can use intelligent capture to extract information from invoice documents and move it into the finance process.

The real value is not only faster invoice entry. The bigger benefit is controlled automation. Dynamics 365 Finance can support automatic submission of imported invoices to workflow, automatic matching of product receipts to invoice lines, and background processing for three way matching scenarios when the right setup is enabled.

For a business, this means fewer manual touchpoints, better control over invoice approvals, stronger matching discipline, and a more scalable AP process. Instead of AP teams spending time typing and chasing documents, they can focus on exceptions, vendor disputes, and cash planning.

Business value: Reduced manual AP effort, faster invoice cycle time, improved matching accuracy, and better visibility into liabilities.

Invoice capture solution overview - Finance | Dynamics 365 | Microsoft Learn

Automated vendor invoicing processes overview - Finance | Dynamics 365 | Microsoft Learn

2. Expense Agent (Production Ready Preview)

Expense management is another area where manual effort creates friction for employees, approvers, finance teams, and project managers. In Dynamics 365 Project Operations, the Expense Agent is designed to automate the end to end expense management process through intelligent workflows, including receipt processing, expense line creation, and expense report generation.

 

 

This matters because expenses are not just employee reimbursements. In project based organizations, expenses can directly affect project cost, billing accuracy, margin reporting, and customer invoicing. Microsoft’s release plan for agent led time, expense, and approvals explains that the solution is intended to reduce administrative burden, improve invoice accuracy, support faster invoicing, and reduce errors across project processes.

The Expense Agent is especially powerful when seen from a practical business lens. Employees want simple expense capture. Finance wants policy compliance. Project managers want accurate project costs. Customers want clean billing. AI automation helps bring these needs together by reducing the manual back and forth between the user, approver, and finance team.

Business value: Faster expense submission, improved policy validation, better project costing, reduced reimbursement delays, and cleaner billing data.

Expense Agent overview (Preview) | Microsoft Learn

3. Account Reconciliation Agent

Reconciliation is one of the most time consuming activities in finance, especially during month end close. Finance teams often spend hours comparing balances, investigating discrepancies, reviewing reports, and manually tracking exceptions. The Account Reconciliation Agent in Dynamics 365 Finance is intended to move reconciliation from a reactive process into a more proactive experience. Microsoft describes it as a step toward continuous financial close, replacing reliance on traditional reconciliation reports with a proactive agent based experience.

The Account reconciliation workspace in Dynamics 365 Finance gives users visibility into open exceptions, addressed exceptions, automatically reconciled transactions, and agent recommended actions. The workspace is integrated with the Copilot agent for account reconciliation.

This is important because reconciliation is not only an accounting task. It affects confidence in financial reporting. When reconciliation is late or manual, finance leaders lose time and trust in the numbers. With an AI supported reconciliation process, the system can help identify exceptions earlier and guide users toward resolution.

There is also a setup and activation consideration. Microsoft documentation notes that administrators must configure the Account Reconciliation Agent, and the Microsoft team must currently activate it until further improvements are released.

Business value: Faster close, earlier exception detection, better financial control, fewer manual reconciliations, and improved confidence in reported balances.

Account Reconciliation Agent (production ready preview) - Finance | Dynamics 365 | Microsoft Learn

4. Supplier Communication Agent

Procurement teams spend a significant amount of time following up with vendors, requesting order confirmations, checking delivery updates, and processing supplier responses. The Supplier Communications Agent in Dynamics 365 Supply Chain Management uses AI to automate many vendor communications so purchasers can focus on higher value tasks.

Microsoft’s Responsible AI FAQ describes two major capabilities of the Supplier Communications Agent. It can send follow up emails to vendors on purchase orders, and it can speed up purchase order updates based on incoming vendor emails.

This is a practical example of AI automation that sits directly inside daily business operations. It is not just answering questions. It is helping procurement teams reduce repetitive communication and convert supplier responses into useful operational updates.

From a transformation perspective, this is important because supplier communication is often hidden manual work. It does not always appear in process diagrams, but it consumes a lot of user time. Automating follow ups and helping process supplier responses can improve purchase order visibility, reduce delays, and help procurement teams manage exceptions more effectively.

Microsoft’s setup documentation also shows that the agent has clear prerequisites, including supported Dynamics 365 Supply Chain Management versions, Copilot components, and licensing considerations for premium tier connectors.

Business value: Reduced procurement follow up effort, improved supplier response handling, better purchase order visibility, and faster exception management.

Supplier Communications Agent overview (production ready preview) - Supply Chain Management | Dynamics 365 | Microsoft Learn

 

5. Demand Forecasting

Demand forecasting is one of the strongest examples of AI and analytics creating value in supply chain planning. Dynamics 365 Supply Chain Management uses demand forecasting to predict independent demand from sales orders and dependent demand at decoupling points for customer orders.

The business value of demand forecasting is straightforward. If businesses forecast poorly, they either carry too much inventory or fail to meet demand. Both outcomes are costly. Too much inventory ties up working capital. Too little inventory affects service levels, customer satisfaction, and revenue.

Dynamics 365 Supply Chain Management allows demand forecasts to be used in master planning so expected demand can influence supply planning. Forecasts can be manually created, imported, or generated by using demand forecasting functionality in the system.

For organizations using the newer Demand planning capabilities, Microsoft documentation also references forecasting algorithms such as auto ARIMA, ETS, Prophet, and XGBoost. This helps businesses move from spreadsheet based forecasting toward a more structured planning process that can incorporate statistical models and business review.

Demand forecasting should not be positioned as a magic prediction tool. It should be positioned as a planning discipline strengthened by system data, algorithms, review cycles, and business judgment.

Business value: Better inventory planning, improved service levels, reduced stockouts, reduced excess inventory, and stronger planning confidence.

Demand planning home page - Supply Chain Management | Dynamics 365 | Microsoft Learn

6. AI Enabled Cash Flow Forecasting

Cash flow is one of the most critical areas where finance teams need better forward visibility. A business can be profitable and still face liquidity pressure if it cannot forecast cash inflows and outflows effectively. Dynamics 365 Finance includes cash flow forecasting tools that help analyze upcoming cash flow and currency requirements so businesses can estimate future cash needs.

Finance insights extends this with cash flow forecasting capabilities that use machine learning to help businesses forecast cash flows more accurately. Microsoft explains that the feature helps companies monitor and manage cash balances and supports decisions that optimize opportunities based on the company’s current cash position.

The value here is practical. Finance leaders need to know whether they can pay suppliers, manage debt, invest in growth, or handle delayed customer payments. AI enabled forecasting gives them a stronger view of future liquidity and helps reduce reliance on disconnected Excel models.

Microsoft also provides setup guidance for enabling cash flow forecasting, including configuring liquidity accounts and connecting payment predictions into the cash flow process.

Business value: Better liquidity visibility, stronger treasury planning, improved working capital decisions, and reduced reliance on manual cash forecasts.

Cash forecast - Finance | Dynamics 365 | Microsoft Learn

7. Unified Pricing Management

Pricing is often one of the most underestimated transformation areas. Many businesses focus heavily on automation in finance and supply chain, but pricing errors and inconsistent discounting can quietly reduce margin every day.

Unified Pricing Management in Dynamics 365 Supply Chain Management and Dynamics 365 Commerce helps businesses manage modern pricing complexity. Microsoft describes it as a capability that supports attribute based pricing rules using data from customers, products, and order segments.

This is highly relevant for businesses moving toward omnichannel sales models. Pricing may differ by customer type, sales channel, geography, product attributes, order segment, promotion, and contractual conditions. Managing this through disconnected spreadsheets or custom logic can create margin leakage and governance issues.

Microsoft also explains that price groups provide a flexible way to manage pricing strategies across attributes such as sales channels, customer groups, order types, and delivery methods. Discounts can also be configured through Unified Pricing Management, supporting more structured pricing and promotional control.

From an AI and automation value perspective, Unified Pricing Management is not only about calculating a price. It is about creating disciplined pricing governance so businesses can scale complex pricing decisions without losing control.

Business value: Better pricing governance, reduced margin leakage, consistent omnichannel pricing, flexible discount management, and stronger commercial control.

Unified pricing management module overview - Supply Chain Management | Dynamics 365 | Microsoft Learn

 

ERP systems were once designed mainly to record what happened. Modern Dynamics 365 is moving toward a different role. It can help predict what may happen, automate what should not require manual effort, and guide users toward better decisions.

For businesses planning a transformation journey, these are the types of capabilities that should be discussed early. Not because they are trendy, but because they address real operational pain points across finance, procurement, supply chain, pricing, and collections.

The future of ERP is not just transactions. It is intelligent operations.

 

D365 Finance & Supply Chain: License Validation & Enforcement

I have seen this scenario many times in D365 Finance and Supply Chain projects.

A business user says:

“I only need this person to view a few screens.”

Then someone assigns a broad security role because it is faster.

A few months later, the license report shows that the user now needs a full Finance or Supply Chain license, even though they barely use the system.

That is exactly where D365 license validation becomes important.

The Security and Licensing Connection

In D365 Finance and Supply Chain, security is role based and pessimistic. This means users have no access until access is explicitly granted.

From a licensing point of view, the important thing is this:

D365 licenses are not based on actual usage. They are based on potential access.

So even if a user never opens a specific form or never performs a transaction, the license requirement is still calculated from the security roles assigned to them.

This is why over assigning security roles directly increases license cost.

How This Worked Before

In the older model, licensing was mostly driven by menu item access.

Each menu item had a view and maintain license parameter. The system looked across all assigned menu items and calculated the highest license required.

• Then in 2019, Microsoft introduced more granular licenses such as Finance, Supply Chain, Commerce, Project Operations, and Human Resources. The calculation shifted toward privileges.
• Now, from March 2025 onward, licensing is calculated at the object level outside D365 through a Microsoft hosted microservice.

This microservice becomes the single source of truth across PPAC, LCS, Microsoft 365, and D365.

That is important because previously, different platforms could show different numbers, which created confusion during license reviews.

What Objects Now Matter

The license calculation now considers more than just forms and menu items.

It includes:

• Menu items, including displays, outputs, and actions
• Service operations, such as API endpoints
• Data entities used for external integrations
• Data entity methods used for business processes on entities

The key rule is simple:

Read access defaults to Team Member.

Write access, such as create, update, or delete, is determined by the licensing entitlement table for that object.

Real World Example

Let’s say you create a custom role for a warehouse supervisor.

The supervisor only needs to view a few operational screens and update limited warehouse related information.

If you assign a large standard warehouse role, the user may require a higher Supply Chain license.

But if you duplicate the role, remove unnecessary duties, and keep only what is needed, the required license may reduce to Operations Activity or another lower tier.

This is why role design matters.

Security is no longer just a technical configuration. It directly impacts licensing cost.

Base and Attach License Model

For users who need enterprise level access, one license becomes the base license. This is usually the highest cost applicable license.

Additional licenses for other functional areas can be attached at a lower price.

For example, if a user needs both Finance and Supply Chain access, one may act as the base license and the other as an attach license, depending on the supported combination.

Microsoft has also added flexibility for licenses in the same pricing group, such as Finance and Supply Chain, to be swapped as base or attach.

If the combination is not supported, then two full base licenses may be required.

Enforcement Timeline

Microsoft began its enforcement journey on January 15, 2026.

This applies to organizations whose renewal or anniversary date falls on or after that date.

The timeline works like this:

• 90 days before renewal, license analysis begins
• 30 days before renewal, users start seeing in app notifications if they are underlicensed
• 15 days after renewal, hard enforcement begins
• Underlicensed users are blocked from logging into production

This enforcement applies only to Microsoft managed production environments.

Sandbox, development, and customer hosted environments are reporting only or excluded.

Important Clarifications

There are a few points every D365 customer should understand.

• B2B guest users need to be licensed like normal users.
• Custom objects, whether built internally or delivered through an ISV, require a Team Member license.
• The SysAdmin role does not require a license, and neither do around 50 plus Microsoft defined roles, as long as they are not modified.
• Service accounts do not need a license if they only use those non licensed roles and are not performing interactive business functions.
• Licenses are managed at tenant level, not environment level. So multiple production environments under the same tenant share the same license pool.
• Multiplexing rules still apply. If users access D365 data through an automated external system, they may still need to be licensed.
• Device licenses are not yet part of enforcement, but Microsoft has indicated they will be included in the future.

Where I Usually Check License Impact

In a practical project, I would not rely on only one report.

The current license reporting is based on the same Microsoft hosted microservice, so the results should be consistent across the main reporting areas.

Power Platform Admin Center

PPAC is useful for a high level view.

It shows licensed, underlicensed, and overlicensed users. You can export the data to CSV or Excel.

There is also a Summarize option that generates a text output, which can be reviewed further for recommendations

Lifecycle Services

LCS provides the User License Consumption Report.

This is useful for project teams and administrators who are already working from LCS during implementation, support, or environment management.

D365 User Security Governance

This is the most detailed place to analyze why a user needs a specific license.

It allows you to drill into the objects, roles, duties, and privileges driving the license requirement.

This must be enabled through Feature Management.

The older license reports inside D365, such as view permission reports and user license count reports, are being deprecated in favor of these new reporting areas.

Role Duplication for License Optimization

This is one of the most practical features for license optimization.

D365 now allows you to duplicate a security role and target a lower license tier.

For example, if a role currently requires a Finance license, but you want to bring it down to Operations Activity, the system can show which duties need to be removed.

The removed duties can be exported to Excel for review.

This gives functional consultants, security admins, and business owners a structured way to optimize roles without guessing.

Dataverse Capacity Changes

Another important update is the Dataverse capacity change from December 2025.

Operations and Dataverse storage capacities have been merged into a single pool.

This gives customers more storage capacity at no additional cost.

This is a welcome change because the earlier separation of storage capacity did not always fit the scale of Finance and Supply Chain deployments.

Handling Custom Objects

Microsoft has clarified an important point in its FAQ white paper:

All custom objects require a Team Member license.

This includes:

• Custom objects built by internal development teams
• Objects introduced by third party ISV solutions

This is simpler than many people expected.

You do not need to analyze custom objects the same way you analyze Microsoft standard objects. The license requirement for custom objects is flat.

They require Team Member.

What This Means Practically

If a user only accesses custom functionality, such as custom forms, custom processes, or custom integrations, then a Team Member license may be enough.

But the moment that same user also gets access to standard Microsoft objects that require Finance or Supply Chain, the higher license wins.

The license requirement is always determined by the highest license requirement across all assigned access.

The Risk With ISV Solutions

This is where organizations need to be careful.

When you install an ISV solution, it introduces new objects into the environment.

The custom ISV objects may only require Team Member.

But many ISV solutions also bundle or connect with standard Microsoft objects and roles.

Those standard objects may carry Finance, Supply Chain, Commerce, or other license requirements.

So even if the ISV objects themselves are low impact, the security roles delivered with the ISV may increase user license requirements.

Best practice is simple:

Run a license analysis before and after installing an ISV solution.

That gives you a clear view of what changed and whether new roles, privileges, or objects increased the license requirement.

Critical Warning on Microsoft Unlicensed Roles

Microsoft provides around 50 plus system roles that do not require a license.

But there is one major caution.

If you add even one custom object, duty, or privilege to one of those roles, the no license exemption is lost.

You can remove objects from those roles without penalty.

But adding anything breaks the exemption.

The same logic applies when building custom roles. If you want a role to remain at Team Member level, make sure it does not accidentally include standard Microsoft objects that require Finance, Supply Chain, or another higher license.

How I Would Handle This in a Real Project

In a real D365 project, I would usually follow this approach.

First, export the current license position from PPAC or LCS.

Then review the highest cost users and identify why they need those licenses.

Next, open User Security Governance in D365 and drill down into the roles, duties, privileges, and objects driving the license requirement.

After that, check whether the user really needs all assigned roles.

If a role is too broad, duplicate it and target a lower license tier.

Then remove unnecessary duties and validate what access is actually required.

For ISV solutions, I would run the same analysis before and after installation.

For custom roles, I would make sure standard Microsoft objects are not accidentally pushing users into a higher license.

For Microsoft unlicensed roles, I would avoid modifying them completely.

Finally, I would include license impact checks as part of every security change request.

Key Takeaways

1. Start the license review now, regardless of renewal date. Most organizations have more cleanup work than expected.
2. Build license checks into the change management process. One security role change can affect hundreds of users.
3. Do not modify Microsoft unlicensed system roles. Adding anything to those roles can trigger a license requirement.
4. Test security and role changes in non production before pushing them to production.
5. Monitor PPAC regularly because Microsoft microservice updates can change your compliance status even if you did not make changes inside D365.

Final Thought

D365 licensing is no longer something to review only during renewal.

It is now directly connected to security design, integrations, ISV installation, custom development, and day to day role management.

The practical rule is simple:

Do not give users more access than they need. Because in D365 Finance and Supply Chain, access is not just security.

Access is licensing.

Disclaimer: This post is based on my practical understanding of D365 Finance and Supply Chain licensing and Microsoft’s published guidance at the time of writing. 

Please validate final licensing decisions with your Microsoft partner, account team, or official Microsoft Learn documentation:Stay compliant with user licensing requirements - Finance & Operations | Dynamics 365 | Microsoft Learn