Saturday, June 7, 2025

Turning Document Routing Agent into a Compliance Enabler in Dynamics 365 Finance & Operations



TURNING DOCUMENT ROUTING AGENT INTO A COMPLIANCE ENABLER IN DYNAMICS 365 FINANCE & OPERATIONS

CONTENT

Introduction
Implement Printer Access Controls
Monitor and Log Print Jobs
Set Up Role-Based Document Routing Policies
Include DRA in Your ITGC Walkthroughs
Ensure DRA is Covered in Business Continuity and Disaster Recovery (BC/DR) Planning
Conclusion

INTRODUCTION

In most ERP implementations, the Document Routing Agent (DRA) is seen as a basic utility for printing documents from the D365FO cloud environment to on-premises printers. While its technical function is straightforward, DRA plays a far more critical role in compliance—especially in industries governed by internal controls and audit scrutiny.

When configured intentionally, DRA strengthens Segregation of Duties (SOD), enhances data confidentiality, and supports IT General Controls (ITGCs) by providing visibility into how and where sensitive documents are output. This article repositions DRA from a background tool to a frontline compliance enabler, supported by practical configuration guidance. 

IMPLEMENT PRINTER ACCESS CONTROLS

Compliance Concern

In financial systems, printers are often treated as generic hardware—but they are in fact data endpoints. Unrestricted printer access can result in payroll reports, AP checks, or tax filings being printed in unmonitored locations. This exposes sensitive information to unauthorized users and violates least privilege and data segregation principles. Without access controls, even users outside of finance may inadvertently (or maliciously) access confidential documents.

Configuration Guidance

  • In Print Management >> Document Type Setup, assign specific printers per legal entity, document type, and user group.
  • Use Entra Id (Azure Active Directory) (AAD) groups in the DRA setup to scope printer access by role.
  • Disable “default printer fallback” to prevent routing documents to unintended devices.

Example: Map payroll printers only to HR security groups and remove visibility from general business users.

MONITOR AND LOG PRINT JOBS

Compliance Concern

In the event of a dispute or audit inquiry, the inability to trace document output—who printed what, when, and where—can be viewed as a control failure. Unlike financial transactions, printing often occurs outside standard logging unless deliberately configured. For high-value outputs such as checks and invoices, this gap leaves organizations vulnerable to fraud, forgery, or data mishandling.

Configuration Guidance

  • Enable logging on the DRA server using Windows Event Viewer or custom PowerShell scripts.
  • Export and archive logs in a secure location tied to document IDs or journal references.
  • Consider Power BI dashboards or SIEM integration for ongoing monitoring and anomaly detection.

Example: Capture DRA logs related to payment batch ID 30992, noting user, timestamp, and destination printer.

SETUP ROLE-BASED DOCUMENT ROUTING POLICIES

Compliance Concern

If the same person can initiate, approve, and print a payment document, SOD policies are undermined. Often overlooked, printer access can provide the final control point for fraudulent activities. By failing to route documents based on role or business unit, organizations leave a back door open to financial manipulation.

Configuration Guidance

  • Align document routing rules with security roles and approval hierarchy.
  • Ensure that users responsible for initiating financial transactions are restricted from accessing print devices assigned to payment or reporting outputs.
  • Use conditional routing in Print Management to dynamically assign printers based on the user’s business unit or document type.

Example: Assign check printing rights exclusively to an “AP Supervisor” role with no posting rights, separating duty from execution.

INCLUDE DRA IN YOUR ITGC WALKTHROUGHS

Compliance Concern

Despite being critical to delivering physical financial outputs, DRA is often excluded from ITGC documentation and walkthroughs. Yet, its failure—whether due to expired certificates, misconfiguration, or access gaps—can delay audits, compromise controls, and disrupt compliance reporting. Regulators increasingly demand visibility into end-to-end control paths, including how documents move from system to paper.

Configuration Guidance

  • Document DRA setup, including machine location, service account, and certificate renewal process.
  • Retain screenshots of Print Management and DRA settings for audit folders.
  • Include DRA in quarterly IT control reviews and walkthrough narratives with auditors.

Tip: Demonstrate a full “initiate → approve → print” chain using real data during control testing.

ENSURE DRA IS COVERED IN BUSINESS CONTINUITY AND DISASTER RECOVERY (BC/DR) PLANNING

Compliance Concern

DRA outages—whether caused by server failure, software patches, or expired certificates—can halt printing of essential documents. In time-sensitive environments like payroll or tax, missing a print deadline may result in non-compliance, delayed payments, or regulatory fines. Yet DRA is often overlooked in BC/DR plans, leaving a critical gap in continuity readiness.

Configuration Guidance

  • Monitor DRA service uptime and certificate validity using scheduled tasks or Azure Monitor alerts.
  • Deploy redundant DRA instances on multiple machines to ensure high availability.
  • Define an alternate output channel (e.g., secure PDF delivery) and test it regularly as part of DR simulations.

BC Planning Tip: Document DRA failover procedures and simulate a test during quarter-end processing.

CONCLUSION

The Document Routing Agent in D365FO may appear to be a technical detail, but it plays a critical role in the secure and compliant delivery of financial documents. When overlooked, it can introduce control gaps—especially around data confidentiality and segregation of duties. When properly governed, however, DRA becomes a practical compliance enabler that reinforces ITGC, supports audit readiness, and ensures continuity for key financial outputs.

Organizations should treat DRA with the same discipline applied to financial workflows and security roles. By doing so, they not only strengthen their ERP control environment but also close a commonly missed gap in the end-to-end integrity of business operations.

Saturday, May 31, 2025

Excel (Add-in) Data Entity Identification for Security Purposes in Dynamics 365 Finance and Operations (D365FO)



EXCEL (ADD-IN) DATA ENTITY IDENTIFICATION FOR SECURITY PURPOSES IN DYNAMICS 365 FINANCE AND OPERATIONS (D365FO)

CONTENT

Introduction
Understanding the Two Types of Data Entities
Why You Need Excel Entity Names in Security Roles
How to Identify the Correct Excel Data Entity Name
Most Common Excel Add-in Data Entities
Conclusion

INTRODUCTION

In Dynamics 365 Finance and Operations (D365FO), Excel Add-in integrations are frequently used by business users to update journal data efficiently. However, granting access to Excel-based data entities requires precise identification of entity names, because they are different than data management entities. This article explains the distinction between standard data entities and Excel Add-in (Office integration) data entities, and provides a structured approach for identifying the correct entity names needed when configuring security roles.

UNDERSTANDING THE TWO TYPES OF DATA ENTITIES

There are two primary types of data entities in D365FO. Although they both enable access to system data, they are used in different contexts and have distinct characteristics:

1. Data Entity (Used in Data Management Projects)

  • Purpose: Primarily used for data import/export, data migration, system integrations, and data projects in the Data Management Workspace.
  • Accessed via: Data Management Framework (DMF) or Integration APIs.
  • Characteristics:
    • Supports staging tables and data validation.
    • Can handle large volumes of data.
    • Often includes all required fields for complete record creation.
    • Suitable for IT and system administrators.

2. Excel Data Entity (Used in Excel Add-in)

  • Purpose: Designed for end users (e.g., accountants, planners) to update or manage transactional data directly in Excel, like journal lines, forecast lines, budget register entries, etc.
  • Accessed via: “Open in Excel” button on D365FO forms or from Excel using the Excel Add-in.
  • Characteristics:
    • Easy-to-use interface with filtering and lookup capabilities.
    • Often shows only a subset of fields relevant to day-to-day operations.
    • Real-time read/write interaction with D365FO.
    • Security-aware (only shows what the user has permission to access).

⚠️ Note: Not every data entity is exposed for Excel; only entities designed for Office integration are surfaced in Excel Add-ins. That’s why they have different names.

Example for Comparison: The data entity used in Data Management is not the same as the one used for the journal line Excel Add-in. Confusing these can result in incomplete security configurations.

Functional Name: Purchase trade agreement journal lines

  • Data entity name: Open purchase price journal lines V2
  • Excel data entity name: PurchOpenPurchasePriceJournalLineV2Entity










WHY YOU NEED EXCEL ENTITY NAMES IN SECURITY ROLES

When assigning permissions, especially for users expected to use Excel integrations, identifying the correct Excel data entity name is critical. Without it, users may have access to the journal forms but will not see the "Open in Excel" button.

Common use cases that require Excel Add-in access:

  • General Ledger (GL) Journal Lines
  • Inventory Counting Journal Lines
  • Trade Agreement Journal Lines
  • Vendor Invoice Journal Lines

This method is widely used to update journal lines in bulk. However, if the security role doesn’t include the specific Excel entity, the integration features will be hidden or restricted.

HOW TO IDENTIFY THE CORRECT EXCEL DATA ENTITY NAME

In D365FO, identifying the correct Excel Add-in data entity is necessary when configuring security roles, especially if users rely on the “Open in Excel” feature. The entity name used for the Excel integration is not always obvious, and often differs from the one used in Data Management. This section outlines practical steps for identifying the exact data entity tied to the Excel Add-in, ensuring users are granted appropriate access without over-provisioning.

OPTION 1: The Excel Template Name

Most of the time, the downloaded Excel template's file name includes the entity name.







OPTION 2: The Excel Template Designer

In D365FO, navigate to Procurement and sourcing >> Prices and discounts >> Trade agreement journals.

Select a journal with Relation: Price (purch.) and click lines.

Click Open in Microsoft Office and choose the relevant data entity.








System downloads the excel template.

Open the downloaded template and click design in the Excel Add-in.














Click + Add table or + Add fields.














Select data entity source field will reveal the actual source data entity.













This field shows you the exact data entity name, not the excel data entity name.















This helps identify the standard entity used in the integration, which can then be translated to the Excel entity name. Once you know the data entity name, apply the following pattern:

[Module prefix] + [Entity name] + "Entity"

Module prefix: e.g., Invent, Purch, Sales, Ledger

Entity name: As retrieved from the template

Example: 

If the source entity is OpenPurchasePriceJournalLineV2 then

the Excel entity would be PurchOpenPurchasePriceJournalLineV2Entity as shown below











Special Case: Multiple Entities in One Template

In some cases, the Excel template contains multiple excel data entities. You may need to do some investigation to identify the name of the secondary entity—for example, in general ledger journal lines.

Navigate to General ledger >> Journal entries >> General journals.

Click Open in Microsoft Office and choose the relevant data entity.








System downloads the excel template.

Open the downloaded template and click design in the Excel Add-in.











Note that you are seeing two data entities, unlike the usual view. So both entities should be accessible by the same security role.

⚠️ Note: Another way to identify the presence of multiple data entities is by checking the downloaded Excel file name. If it ends with "Template," it indicates that multiple entities are included.

Click + Add table or + Add fields.












Select data entity source field will reveal the actual source data entity.












This field shows you the exact data entity name, not the excel data entity name.













Now you can apply the below formula and identify exact required excel data entity name for your security configuration.

[Module prefix] + [Entity name] + "Entity" = LedgerLedgerJournalLineEntity (No need to use 'Ledger' two times)

If you grant access to excel data entity LedgerJournalLineEntity, user can use export to excel add-in feature.










MOST COMMON EXCEL ADD-IN DATA ENTITIES

Here are the most frequently used Excel data entities, especially in journal-heavy environments:

  • General Ledger (GL) Journal Lines: Requires access to both header and line entities
  • Inventory Counting Journal Lines: Only one entity is required
  • Trade Agreement Journal Lines: Different entities may be activated depending on the price type
  • Vendor Invoice Journal Lines: Requires access to both header and line entities

CONCLUSION

Identifying the correct Excel Add-in data entity name is essential when configuring security roles in D365FO. Without it, even experienced users might be blocked from using the Excel integration features they rely on for daily operations. Use the methods outlined above—especially downloading templates and checking the entity structure—to accurately assign permissions. As always, keep in mind that Excel Add-in entities are security-aware, so careful role configuration ensures both usability and compliance with least privilege principles.

Thursday, May 22, 2025

Worker vs Vendor in Expense Management – Dynamics 365 Finance and Operations (D365FO)



WORKER VS VENDOR IN EXPENSE MANAGEMENT – DYNAMICS 365 FINANCE AND OPERATIONS (D365FO)

CONTENT

Introduction
Worker-Based Reimbursement
Vendor-Based Reimbursement
Process Flow Comparison
Expense Management Parameters
Multi-Legal Entity Considerations
Common Scenarios
Reporting and Auditing Considerations
Conclusion

Introduction

Expense Management in Dynamics 365 Finance and Operations (D365FO) enables organizations to track, process, and reimburse business-related expenses. Depending on who incurs the expense and how reimbursement is expected to occur, you may configure the system to reimburse either a worker (employee) or a vendor (third party). This article outlines the key differences between these two approaches and the practical implications for finance and compliance teams. This article intends to be an introductory knowledge based resource that provides a solution to initial expense management design discussions. 

Worker-Based Reimbursement

When to Use

  • This method is applicable when an employee has a business-related expense and submits an expense report for reimbursement. Common examples include travel, meals, lodging, or mileage expenses.

Configuration Requirements

  • The individual must exist as a worker in the Human Resources module and be associated with a legal entity.
  • A vendor account must be linked to the worker. This can be created automatically (if system parameters are configured accordingly) or linked manually via the Employee > Expense tab > Employee mapping and per diem rates.


  • Expense Management parameters must be set to reimburse through Accounts Payable using the linked vendor account.

Accounting Impact

  • When the expense report is posted, the expense is debited to the designated expense account (e.g., travel expense).
  • A liability is posted to the worker’s vendor account, which becomes eligible for payment through the standard AP payment process.

Note

  • The vendor account must have valid bank account details if electronic payments are used.
  • The system uses standard payment methods (such as checks or AC or WIRE) to pay the worker, just as it would for a regular vendor.

Vendor-Based Reimbursement

When to Use

This method is used when when the expense is incurred by a third-party vendor or when a company directly pays an external party for goods or services, such as hotel bookings made by a travel agency or outsourced consulting services.

Configuration Requirements

  • The external party must be created as a vendor record in the Accounts Payable module.
  • Expense categories can be configured to allow vendor selection when appropriate.
  • No linkage to a worker record is required.

Accounting Impact

  • The system posts the expense to the designated expense account.
  • The liability is posted directly to the vendor, and payment is processed through standard AP procedures.

Note

  • This configuration avoids involving employees in expense-related payments when the service or product is procured directly by the organization.
  • Ideal for scenarios where centralized procurement or travel teams handle bookings.

Process Flow Comparison

Worker Reimbursement Flow:

1. Worker creates an expense report via self-service or mobile app.

2. Report follows the approval hierarchy.

3. After final approval, a vendor transaction is created against the worker’s vendor account.

4. Payment is processed through Accounts Payable, based on standard payment proposal functionality.

Vendor Payment Flow:

1. An expense or invoice from a vendor is entered (e.g., from a travel agency or external consultant).

2. The document is reviewed and approved as required.

3. A vendor liability is created.

4. The payment is processed like any other vendor invoice..

Expense Management Parameters

Expense Management behavior can be configured in:

Expense Management > Setup > Expense Management parameters

Under the Reimbursement tab, there are key settings:

  • Reimburse through Accounts Payable: When selected, the system expects a vendor account to be associated with each worker.
  • Create vendor account automatically: If enabled, D365FO creates a vendor record for each worker, reducing manual setup.

⚠️ It’s recommended to review your number sequences and vendor groups before enabling automatic creation, as these will determine the structure and grouping of generated vendor accounts.

Multi-Legal Entity Considerations

In organizations operating across multiple legal entities, a single worker may be associated with more than one legal entity. In such cases:

  • A vendor account must be created for each legal entity where the worker is submitting expenses.
  • The system does not share vendor records across entities by default, as financial transactions and payments are managed independently per legal entity.

Failure to configure the appropriate vendor account for each entity may result in failed postings or blocked payments.

Common Scenarios

The table below outlines typical business cases and whether a worker-based or vendor-based configuration is appropriate. This helps clarify when each method should be used, based on who incurs the expense and how reimbursement or payment is expected to occur. Using the correct setup avoids confusion in AP processing and supports clean financial postings.



Reporting and Auditing Considerations

Accurate configuration of worker and vendor expense flows is critical for:

  • Maintaining audit trails: Clear identification of payee (worker vs. vendor) ensures traceability.
  • Simplifying month-end processes: Vendor liabilities are easier to reconcile when correctly segmented.
  • Internal control compliance: Separating employee reimbursements from vendor payments supports proper delegation of authority (DOA) enforcement and SOX compliance.
  • Financial dimension tracking: Both configurations allow for financial dimensions to be captured per line item (e.g., department, cost center), enabling accurate reporting.

Conclusion

D365FO offers flexible options to support different expense reimbursement scenarios through either worker-linked vendor accounts or standard vendor records. Selecting the appropriate configuration depends on who incurred the expense, how the payment will be processed, and the internal policies around employee reimbursements and vendor procurement.

Use worker-based configuration when employees pay out-of-pocket and expect to be reimbursed. Use vendor-based configuration when the organization pays third-party service providers directly. Properly configuring these options will result in clean accounting entries, better workflow control, and alignment with internal compliance frameworks.

Wednesday, April 30, 2025

Purchase Price Variance (PPV) Account Usage in Dynamics 365 Finance and Operations (D365FO)













PURCHASE PRICE VARIANCE (PPV) ACCOUNT USAGE IN DYNAMICS 365 FINANCE AND OPERATIONS (D365FO)

CONTENT

Introduction
What is purchase price variance (PPV)?
Why PPV matters for SOX compliance?
Control activities
Key setup for PPV accounting
Demo
How to reduce PPV account balance?
Conclusion

INTRODUCTION

In a SOX-compliant environment, accuracy in financial reporting is critical. One often-overlooked area that can introduce variances—and therefore risk—is the purchase price variance (PPV) accounting setup in Dynamics 365 Finance and Operations (D365FO). Although PPV is typically associated with manufacturing and procurement cost management, its impact extends into key financial control objectives around inventory valuation, cost of goods sold, and ultimately, financial statement accuracy. This article explains how PPV accounts are used in D365FO and highlights important considerations for SOX compliance.

WHAT IS PURCHASE PRICE VARIANCE (PPV)?

Purchase Price Variance represents the difference between the standard cost (or expected cost) of an item and the actual cost recorded when the vendor invoice is processed.

In D365FO, the variance is automatically posted to the PPV account when:

  • A product receipt is posted (if accrued based on receipt)
  • A vendor invoice is matched and posted at a different price than the product receipt or purchase order price

Without proper setup and monitoring, PPV balances can accumulate and distort both inventory valuation and cost recognition, leading to misstatements.

WHY PPV MATTERS FOR SOX COMPLIANCE

Let’s say you plan to buy a tool for $100 (that’s your standard price). But when you actually go to the store, it costs $102. That extra $2 difference is called a purchase price variance.

Big companies do the same thing — they expect to pay a certain price for materials or supplies, but the real price can be higher or lower. If they don’t keep track of these differences (the PPV), they might accidentally show the wrong numbers in their financial reports.

From a SOX perspective, improper handling of PPV can create material misstatements in key accounts such as:

  • Inventory
  • Accounts Payable
  • Cost of Goods Sold
  • Expense Accounts

Controls around PPV are often tested under Financial Close and Reporting and Inventory Management process areas.

CONTROL ACTIVITIES

To ensure PPV is managed appropriately, organizations should implement the following controls:

  • PPV Reconciliation: Perform monthly reconciliation of PPV balances, investigating significant fluctuations.
  • Standard Cost Governance: Establish a formal process to review and approve standard cost updates.
  • Three-Way Match Enforcement: Ensure three-way matching is mandatory for purchase order processing to minimize undetected variances. This works if there is a price difference between PO and Invoice.
  • Threshold Review: D365FO currently doesn’t offer this functionality, but an ideal control would allow you to set PPV tolerance thresholds that trigger a management review when exceeded. I’ve submitted this idea to Microsoft. Please support it by giving it a VOTE HERE

Failure to monitor and reconcile PPV accounts timely can result in audit findings related to inventory misstatement or inadequate expense recognition.

KEY SETUP FOR PPV ACCOUNTING

To manage PPV properly, D365FO requires the following configurations:

  • Item Model Group: Items must belong to an item model group using the Standard cost inventory model.

Below image shows that item's model group name is 'STD'.



The setup of item model group 'STD'  shows that inventory model is 'Standard cost'.



  • Inventory Posting ProfileWithin the inventory posting setup, a designated PPV account must be defined under the 'Standard cost variance' tab's 'Purchase price variance' field.

Below image shows that 'Purchase price variance' is defined as '510310'.


 

  • Three-Way Matching ConfigurationMatching between purchase order, product receipt, and vendor invoice ensures variances are systematically caught and recorded.
Accounts payable >> Inquiries and reports >> Invoice >> Invoice history and matching details.
 


Let's see that in action!

DEMO

Item's Inventory Model

Let's make sure that our demo item's inventory model is Standard cost.



Item's Cost

Let's take a look at demo item's standard cost.

The expected purchase cost aka standard cost is $100. The difference between $100 and any other values will be kept in the PPV account.


The expected purchase cost aka standard cost is $100. The difference between $100 and any other values will be kept in the PPV account.


Purchase Order and Product Receipt

Let's now create a purchase order and put unit price $102.


Fast forward, After product receipt posting, generated voucher would look like below

Please note that unexpected $2 is kept in PPV (Purchase price variance) account by the system automatically. Received but invoiced total amount is $102.

Vendor Invoice

Let's register the vendor invoice and see the posted entry's voucher.


Note that invoice voucher doesn't use the PPV account since the variance already was captured on the product receipt stage.


Let's take a look at the PPV account transactions to see if $2 difference is there.

Yes, the difference is in this account.


Should You Be Concerned?

Yes — a continuously growing PPV account balance is a red flag, especially in SOX-compliant environments. It signals that:

Your standard costs do not reflect reality,

You're accumulating unreviewed variances,

You may be misstating your inventory, COGS, or expense accounts.

Unaddressed, this could lead to audit findings or material financial misstatements.

HOW TO REDUCE THE PPV ACCOUNT BALANCE

1. Reclassify Old or Immaterial PPV Balances

Work with finance to post a manual journal entry to remove (or reclassify) the balance from the PPV account if they are deemed immaterial.

"Immaterial" in accounting means the amount is too small to influence decisions made by someone reading the financial statements.

Transfer them to an appropriate expense account after analysis.

2. Update Standard Costs

Review items with high PPV activity.

Update standard cost records (via Costing version) to align with recent actual purchase prices.

3. Correct Purchase Price Issues

Investigate frequently used vendors or items causing large variances.

Fix missing or incorrect purchase prices or trade agreements.

4. Enforce Invoice Matching & Tolerance Controls

Use three-way matching and enforce price variance tolerance thresholds.

This is useful when you have a price difference between PO and Invoice.

CONCLUSION

PPV might seem like a small detail in day-to-day operations, but it can have a real impact on your financial statements, especially if you're working in a SOX-regulated environment. In this article, we walked through how PPV works in D365FO, what setups are required, why it's important to monitor, and how variances show up in the system during receipt and invoicing. If the PPV account balance keeps growing, it’s worth to investigate since unreviewed variances could lead to bigger problems later.

Turning Document Routing Agent into a Compliance Enabler in Dynamics 365 Finance & Operations

TURNING DOCUMENT ROUTING AGENT INTO A COMPLIANCE ENABLER IN DYNAMICS 365 FINANCE & OPERATIONS CONTENT Introduction Implement Printer Acc...