Purchase Order Re-approval in Dynamics 365 Finance and Operations

 

PURCHASE ORDER RE-APPROVAL IN DYNAMICS 365 FINANCE AND OPERATIONS

This article provides detailed information about purchase order re-approval process in Dynamics 365 Finance and Operations. Re-approval logic triggers additional approval process in case changing selected field values on the purchase orders.

Let's get started.

CONTENT Introduction Solution components Demo Conclusion

INTRODUCTION

The purchase order (PO) workflow is a widely used IT Application Control (ITAC) in Dynamics 365 Finance & Operations (D365FO), especially for SOX-compliant organizations. Its primary purpose is to ensure internal approval before processing purchase orders. 

This article examines whether purchase orders must go through workflow approval when created under specific scenarios, such as:

• Firming a planned purchase order
• Releasing an approved purchase requisition (PR)

The answer is no. If the purchase orders are already required, additional approval is unnecessary.

Planned purchase orders are system-generated based on demand signals, reviewed, and approved before being converted into actual POs. If no further procurement team approval is needed after PO is created, then the firming process should be designed accordingly.

Purchase requisitions (PRs) must go through a workflow approval process, typically starting with a department manager and continuing through additional levels based on total cost and signing limits. If the resulting POs do not require additional approval, the PR approval process should be configured with this in mind.

However, if a created PO is touched and changed, it should be subject to a re-approval process. This article explains how to configure the system to bypass PO approval when originating from PRs or planned orders while ensuring re-approval when modifications occur.

SOLUTION COMPONENTS

Change management activation: Enable change management for POs by setting the Activate change management option on the Procurement and sourcing parameters. When change management is enabled, POs must go through an approval workflow after they've been completed.

Navigate to Procurement and sourcing >> Setup >> Procurement and sourcing parameters.

Activate the change management.

When change management is enabled, POs move through six approval statuses, from Draft to Finalized. After an order has been approved, users who want to modify it must use the Request change action. In this case, the approval status is changed back to Draft, and PO can be modified. After changes are done, PO can be submitted for re-approval. The field changes subject to re-approval is configured using a Re-approval rule for purchase orders policy on the Purchasing policies.

Purchasing policy setup: The re-approval rule within purchasing policies is an optional rule that defines the criteria for requiring re-approval when a purchase order is changed. The selected fields are evaluated in the purchase order workflow when the "Requires purchase order re-approval" condition is set up in the workflow.

Navigate to Procurement and sourcing >> Setup >> Policies >> Purchasing policies.

Select the policy and click on it.

Select 'Reapproval rule for purchase orders' under the policy rules.

Then select the most recent policy on the right side of the screen.

The next screen is the most important one. This is where re-approval triggers are configured. The example below shows that when the total amount of any line is changed, the order will be routed to the approval process.

Workflow configuration: The final and crucial step in the purchase order re-approval process is configuring the workflow itself. To ensure that re-approval is triggered when necessary, the workflow must include a conditional decision to evaluate whether changes require additional approval.

Navigate to Procurement and sourcing >> Setup >> Procurement and sourcing workflows.

You can see a very basic workflow configuration for re-approval as below.

This workflow says that:

If re-approval is not needed (reapproval = no), follow the left path. In this case, the workflow is automatically approved upon submission.

If re-approval is needed, follow the right path. This triggers the actual approval process that the system follows.

The final step in the workflow configuration is to set this workflow as the default for purchase orders.

With the necessary solution components in place, the next step is to see how these configurations work in action. In the following demo, we will walk through the purchase order re-approval process in Dynamics 365 Finance and Operations, demonstrating how change management, purchasing policies, and workflow configurations come together to enforce re-approval when necessary.

DEMO

Scenario 1: Firming a Planned Purchase Order

• Firm a planned purchase order and confirm that no additional approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

Scenario 2: Converting an Approved Purchase Requisition to a Purchase Order

• Convert an approved purchase requisition (PR) into a purchase order and confirm that no additional approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

Scenario 3: Creating a Purchase Order Directly

• Create a purchase order manually and confirm that approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

This articles demonstrates Scenario 2 and Scenario 3.

Scenario 2: Converting an Approved Purchase Requisition to a Purchase Order

Navigate to Procurement and sourcing >> Purchase requisitions >> Approved purchase requisition processing >> Release approved purchase requisitions.

Select the PR line that will be converted to PO.

Note that PR price is $900.

Convert PR to PO.

Note that created PO is in Approved status that doesn't require PO approval.

The second part of the scenario is making a change on the order that doesn't impact pricing.

Unlock the PO by requesting a change.

Assign a warehouse to the PO header.

Submit the order for workflow approval.

Note that order is automatically approved since the requested change doesn't impact the pricing.

The workflow approval history of the order is as below:

The workflow assesses "no need for re-approval" as 'True' and completes the process automatically.

Scenario 3: Creating a Purchase Order Directly

A brand new purchase order is created and click Submit to initiate the workflow approval process.

The system evaluates the "No need for re-approval" condition. Since this is a new PO, the system determines it as 'False', meaning the approval process must be completed.

The PO routes through the designated approval hierarchy. Once all approval steps are completed, the PO status updates to "Approved.

Open the approved purchase order.

Click Request Change to modify the document.

Add a new line.

Re-submit the PO to workflow.

The workflow is triggered again and routes the PO for approval.

The PO arrives in my approval queue for review.

Upon approval, the PO status updates to "Approved" again.

Let's make a small change that doesn't impact pricing.

Since this change does not affect the item price, quantity, or financial impact, the workflow automatically completes without requiring additional approval.

Let's also change the warehouse on the PO from 11 to 12.

Since this change does not affect the item price, quantity, or financial impact, the workflow automatically completes without requiring additional approval.

CONCLUSION

In conclusion, the purchase order change workflow is a key control for SOX compliance in Dynamics 365 Finance and Operations. Properly configuring change management, purchasing policies, and workflow conditions ensures that modifications to approved POs are subject to re-approval when they impact financial or operational integrity. This structured approach helps enforce accountability, prevent unauthorized changes, and maintain an auditable procurement process while aligning with compliance requirements.

Audit Workbench in Dynamics 365 Finance and Operations

AUDIT WORKBENCH IN DYNAMICS 365 FINANCE AND OPERATIONS

In the previous article, I provided an introduction to the audit features available in Dynamics 365 Finance and Operations, highlighting tools such as the Audit Trail and Audit Workbench, which are designed to support compliance and transactional accuracy. 

This article delves deeper into the Audit Workbench module, a detective tool that enhances audit processes by automating the detection, tracking, and resolution of transactional discrepancies, ensuring compliance and operational efficiency.

Let's get started.

CONTENT The logic Query (Audit) types Sample scenarios Demo - Case creation Demo - Audit Conclusion

THE LOGIC

The logic of the Audit Workbench module in D365FO involves the following steps:

• Creates Policies: Establishes audit policies and rules to define criteria for identifying discrepancies or irregular transactions.
• Monitors Transactions: Continuously scans transactional data to detect deviations from the defined policies.
• Identifies Exceptions: Flags transactions that violate policies as exceptions for further review.
• Conducts Audits: Facilitates a detailed examination of flagged exceptions to analyze potential issues or risks.
• Tracks Resolutions: Enables tracking and documentation of resolutions for each flagged transaction, ensuring accountability and compliance.
• Provides Insights: Generates reports and insights to support decision-making and improve future processes.

This article demonstrates all of the above steps through realistic end-to-end business scenarios.

This feature enables the auditing of expense reports, vendor invoices, and purchase orders in various ways. The essential configuration required is the Audit Policy, which allows you to specify the document type to be audited and select the desired audit type.

QUERY (AUDIT) TYPES

When you set up an audit policy rule, the first thing you do is pick a rule type. This also decides the kind of audit the rule will use. The query looks at the source document the rule will evaluate and figures out details like which legal entity and date to use when selecting documents for auditing. The type of query also affects what fields show up by default when you're working in the query page or the Audit policy rule page.

Query type	Purpose
Conditional	It is used to evaluate records against a set of conditions and take action when those conditions are met. For example, you can configure a rule to flag expense reports if they exceed $1,000 and do not include an approval signature. This type of rule ensures compliance by checking for specific combinations of criteria in your data.
Aggregate	It is used to flag transactions or records that exceed certain thresholds or limits when grouped together. For example, you can use it to audit total expenses submitted by an employee over a month, or total payments to a vendor in a specific period, and flag cases where the amounts exceed a predefined limit. This helps identify unusual or risky trends for further review.
Sampling	It is used to pick a small, representative set of records from a larger dataset to review for compliance, accuracy, or irregularities. For example, you can configure a rule to randomly select 5% of all vendor invoices from a specific period for audit, ensuring a fair and manageable review process without checking every single transaction.
Duplicate	It is used to flag records that may have been entered multiple times by mistake, such as duplicate vendor invoices, expense reports, or purchase orders. For example, you can configure it to detect invoices with the same vendor, invoice number, and amount, helping to prevent overpayments or fraud. It’s a tool to ensure data accuracy and avoid redundancy.
List search	It is used to create audit policies that focus on identifying specific values or patterns within a list of data (e.g., transactions, vendor records, or employee expenses). These rules are ideal for catching anomalies, policy violations, or data points that require further investigation.
Keyword search	It is used to identify records that might need attention based on certain words or terms. For example, you can use it to find expense reports, vendor invoices, or other documents that include keywords like "gift" or "bonus".

SAMPLE SCENARIOS

The next step is to explore how these queries can be applied in real-world scenarios. By using these query types, you can create targeted rules to monitor and flag specific document types. Below are practical examples for each query type, demonstrating how they can be configured to identify anomalies, ensure compliance, and improve data accuracy in Dynamics 365 Finance and Operations.

List Search Policy Rule

• Scenario 1: Identify all purchase orders where the requested delivery date is in the past, ensuring timely communication with vendors.
• Scenario 2: Flag vendor invoices with payment terms longer than 90 days to ensure compliance with organizational policies.
• Scenario 3: Highlight expense reports submitted with amounts exceeding $5,000 for further managerial review.

Keyword Search Policy Rule

• Scenario 1: Search for the word "urgent" in vendor invoice descriptions, which may indicate rushed or unusual transactions.
• Scenario 2: Identify expense reports containing the keyword "gift," as these may require special approval or policy checks.
• Scenario 3: Flag purchase orders with descriptions containing "custom" to ensure they align with approved procurement guidelines.

Duplicate Policy Rule

• Scenario 1: Detect duplicate vendor invoices submitted with the same invoice number, amount, and vendor, avoiding overpayments.
• Scenario 2: Identify duplicate purchase orders with the same vendor, total amount, and delivery date, which could indicate data entry errors.
• Scenario 3: Flag duplicate expense reports submitted by the same employee for the same trip or purpose to prevent duplicate reimbursements.

Sampling Policy Rule

• Scenario 1: Randomly select 5% of purchase orders from the last month for auditing to ensure compliance with procurement policies.
• Scenario 2: Sample 10% of vendor invoices over $50,000 for auditing to confirm they have proper supporting documentation.
• Scenario 3: Select a random set of expense reports from a specific department for a compliance check.

Aggregate Policy Rule

• Scenario 1: Flag vendor invoices where the total payments to a single vendor in a month exceed $1,000,000, signaling a need for further review.
• Scenario 2: Identify purchase orders where the total value of orders placed with a single vendor in a quarter exceeds $2,000,000, ensuring compliance with procurement limits.
• Scenario 3: Monitor expense reports where the total amount submitted by an employee in a month exceeds $10,000, ensuring adherence to travel and expense policies.

Conditional Policy Rule

• Scenario 1: Flag expense reports where the total amount exceeds $5,000 and no manager approval has been recorded.
• Scenario 2: Identify vendor invoices where the due date is overdue and no payment has been scheduled yet, to ensure timely follow-up.
• Scenario 3: Flag purchase orders where the total value exceeds $100,000 and the order has not been approved by a senior manager.

DEMO - CASE CREATION

Let's delve into 'Duplicate Policy Rule's 'Scenario 1'.

Navigate to Audit workbench >> Setup >> Policy rule type.

The following line indicates that vendor invoices will be subjected to a duplicate invoice check. The batch job's date range will be based on the invoice date.

Let's now configure the system to display invoices with the same amount that belong to the same vendor within a specific time range.

Navigate to Audit workbench >> Setup >> Audit policies.

Create an audit policy named Duplicate invoices.

Create a policy rule  at the bottom of the screen and click on it.

Click Filter.

Switch to Group by tab.

We want to see all invoices belong to same vendor with same amount within a specific time frame.

Configure the screen as shown below:

Click OK.

Click Test.

Specify a date range for the test.

⭕ Note that the batch job's date range will be based on the invoice date.

Let's run the test now.

Click Run test.

Results are shown as below.

The last step is to configure a batch job to automate the process and capture anomalies. 

Navigate to Audit workbench >> Setup >> Audit policies

Select the policy and click Additional options. 

Enter the date range and click Batch.

 

Enter the batch job parameters.

Click OK.

 

Note that batch job is added to the queue. Upon batch job completion, system creates audit cases under Audit workbench >> Audit cases.

DEMO - AUDIT

Audit cases represent exceptions flagged during periodic reviews conducted to ensure adherence to SOX compliance and internal control policies. The following steps outline the process for managing and resolving these cases effectively:

1 - Initiating case review

Access the periodic audit cases from the Audit Workbench by navigating to Audit workbench >> Audit cases.

Each case is a part of the periodic Audit. 

Select the specific case flagged for review and drill down into its details to begin the investigation.

Update the case status to "In Progress" to signify the start of the auditing process.

2 - Assigning ownership

Assign the case to a responsible auditor or investigator. This ensures accountability and a clear delegation of responsibility for addressing the identified anomaly. 

3 - Analyzing case details

The responsible individual reviews the case content.

The Associations fast tab within the audit case displays all linked documents contributing to the flagged anomaly. 

The ID column provides hyperlinks for direct navigation to master data or the source documents, enabling a comprehensive examination of the transactions.

4 - Analysis

Examine the flagged transactions and complete the review.

5 - Document findings

Record the investigation outcomes in the case log to maintain a detailed audit trail.

6 - Providing supporting evidence

In case the identified finding requires further clarification, attach a knowledge article as supporting evidence to substantiate its accuracy. For example, while the system may flag a potential anomaly, it enforces controls that prevent users from recording the same invoice number more than once, ensuring compliance.

Attach a knowledge article to justify the finding if necessary as shown below:

Click Yes.  

7 - Closing the case

Once the review is complete and the necessary actions have been taken, update the case status to "Closed." This final step confirms that the anomaly has been resolved, and the audit process is complete.

CONCLUSION

Audit Workbench in Dynamics 365 Finance and Operations offers a practical and efficient way to manage the audit process by streamlining the identification, review, and resolution of irregular transactions. With its ability to automate key tasks such as flagging anomalies, assigning cases, and tracking resolutions, it helps teams focus on addressing critical issues without getting bogged down in manual processes. Its flexibility in configuring policies and queries ensures that audits are tailored to the organization’s specific needs, enabling a more targeted and effective approach. By leveraging these capabilities, businesses can maintain better control over their operations, improve compliance, and ensure transparency in their financial and operational processes.