Monitoring Data Changes with Database Log in Dynamics 365 Finance and Operations

MONITORING DATA CHANGES WITH DATABASE LOG IN DYNAMICS 365 FINANCE AND OPERATIONS

CONTENT Introduction Why database log is critical for sox Key tables and fields for SOX logging Step-by-step: enabling SOX-aligned logging Tips for aligning with SOX controls What database log doesn't do Complementary tools Conclusion

INTRODUCTION 

In SOX-regulated environments, proving that key data is accurate, properly changed, and fully auditable is non-negotiable. Internal and external auditors expect more than high-level assurances—they want verifiable system-generated evidence that data-altering activities are monitored and controlled. This is especially critical for master data and configuration records that directly influence financial reporting.

Microsoft Dynamics 365 Finance & Operations (D365FO) provides a built-in tool—the Database Log—that supports these objectives. When used strategically, it becomes a reliable method to capture evidence for IT General Controls (ITGCs) and automated key controls, allowing organizations to meet SOX compliance requirements directly from within the application.

This article outlines how to configure and use the Database Log in a SOX-compliant manner, what fields and tables are typically in scope, and how to review the logs during audit cycles.

WHY DATABASE LOG IS CRITICAL FOR SOX

The Database Log supports the first and second lines of defense in a SOX environment:

The table below explains how Database Log features map to specific SOX control expectations. 

On the left, you can find the control capability the Database Log provides; on the right, you can find how this helps your organization meet SOX compliance requirements.

Control Capability (What Database Log Enables)	SOX Compliance Justification (Why It Matters)
Tracks changes to master and configuration data	Supports ITGC – Program Change Management by ensuring that changes to critical configuration are logged and reviewable
Captures timestamp, user ID, old/new values	Satisfies Control Evidence Requirements under SOX Section 404 – logs prove that data changes were authorized and monitored
Provides system-generated, immutable logs	Enables auditability of key system controls, which auditors require for walkthroughs and control testing
Detects unauthorized or unapproved updates	Helps mitigate financial misstatement risks by identifying configuration tampering or fraud
Complements workflow approvals with field-level logging	Supports control operating effectiveness by ensuring the final values match what was approved, not just that a workflow was completed

Auditors routinely ask for evidence that configuration values (e.g., posting profiles, bank accounts, tax parameters) have not changed unexpectedly. The Database Log gives you a timestamped, user-specific record of those changes—including the before/after values.

Without it, organizations often scramble to piece together email threads or screenshots—none of which meet the bar for system-generated audit evidence.

KEY TABLES AND FIELDS FOR SOX LOGGING

This section advises which specific tables and fields in D365FO should be monitored via Database Log in a SOX-compliant environment. It directly answers the question:

"What parts of the system should I enable Database Log on to satisfy SOX auditors?"

You're essentially curating a SOX logging scope—focused only on the configuration and master data elements that impact financial reporting and compliance.

Here are common objects that should be considered for Database Log configuration in a SOX-compliant implementation:

Table	Fields to Log	Why It Matters
VendBankAccount	Bank account number, Routing number	Fraud prevention & payment redirection risk
LedgerPostingSetup	Posting profiles, Main accounts	Impact on financial statements
MainAccount	Posting type, Account category	GL reporting structure
Ledger	Fiscal calendar, Reporting currency	Disclosure and period-end reporting
InventModelGroup	Inventory valuation method	COGS calculation

You're not logging everything—only SOX-sensitive fields that can impact the financials or introduce fraud risk.

This sample list helps define your logging scope, often maintained as part of your SOX control matrix.

Every field listed should map to a SOX control objective (e.g., “Changes to posting configuration must be logged and reviewed”).

STEP-BY-STEP: ENABLING SOX-ALIGNED LOGGING

In this guide, we will enable change tracking functionality for vendor bank accounts.

Navigate to database log setup. System administration > Setup > Database log > Database log setup. 

Click + New.

Click Next.

Select tables and fields.

Vendor bank account table is under General Ledger.

Expand the note and select the fields that need to be tracked.

Limit field selection to SOX-relevant configuration items only. Avoid enabling it for operational or high-volume transactional tables.

According to our scenario, we will track the following fields.

• Account num
• BankIBAN
• Modified by
• Modified date and time
• Vendor account

Choose the logged events. Enable Insert, Update, and/or Delete based on your SOX control narrative.

Click Next.

System doesn't allow you to continue before deleting existing database log.

Delete it first.

Note that Finish button is now enabled.

Click Finish to complete the wizard and enable logging.

Note that you now see all tracked fields on the database log setup screen.

Making changes on the vendor's bank account screen.

Navigate to Accounts payable > Vendors > All vendors.

Select a vendor and click Bank accounts.

Vendor bank account form is now opened.

Click Edit button.

Add '9' at the end of the bank account number field value.

Save the screen, close the form.

EVIDENCE GENERATION FOR SOX AUDITS

Once enabled, logs become available under:

System administration > Inquiries > Database > Database log.

You can export logs to Excel, filter by user/date/table, and review changes in detail.

Note that you now see all the required values.

They also serve as evidence for ITGC testing, especially for configuration change control.

Logged Attribute	SOX Value
Timestamp	Validates when a change occurred
Changed by	Identifies the responsible user
Old value	Ensures no unauthorized configuration overwrite
New value	Shows what the system is using now

TIPS FOR ALIGNING WITH SOX CONTROLS

• Separate duties: Only IT control owners or system admins should configure or disable logging.
• Control design mapping: Tie each logged field to a documented SOX control ID.
• Alerting: Consider combining Database Log with Alerts to notify compliance teams of sensitive updates.
• Change control alignment: Ensure all changes logged were also approved via Change Request or IT ticket.

WHAT DATABASE LOG DOESN'T DO

Database Log is not a silver bullet. It doesn’t:

• Track who approved a change (use workflows for that)
• Cover external systems (e.g., CRM, payroll)
• Replace robust SOD enforcement or Fastpath analysis

It does not log changes made via SQL, which is why production databases should restrict direct write access under SOX principles.

COMPLEMENTARY TOOLS

Purpose	Tool
Cross-app user access review	Fastpath Assure
Data loss prevention and export alerts	Microsoft Purview
Workflow approvals	D365FO native workflows
Full audit across Power Platform	Microsoft Dataverse Audit Log

Use Database Log for configuration integrity, and combine it with these tools for a full compliance coverage model.

CONCLUSION

Database Log is a first-party feature designed for compliance. When configured properly, it satisfies critical SOX control objectives such as:

• Evidence of configuration control
• Traceability of key data changes
• Accountability of users with elevated privileges

For internal auditors, external auditors, and control owners, the value lies in having a system-generated, non-editable, filterable trail—available directly in the ERP system, with no external tools or integrations required.

This makes the Database Log an essential tool in your D365FO SOX compliance toolbox—especially for automated ITGC evidence.

Designing Approval Workflows in Dynamics 365 Finance with a SOX-Compliance Lens

DESIGNING APPROVAL WORKFLOWS IN DYNAMICS 365 FINANCE WITH A SOX-COMPLIANCE LENS

CONTENT Introduction Why Every SOX Control Framework Must Include Robust Approval Workflows How D365FO Workflow Maps to SOX Control Objectives Control Design Choices That Auditors Will Question Test of Design (TOD) - Configuring a SOX-ready Purchase Order Approval Test of Effectiveness (TOE) - Executing a Sample Purchase Order Workflow Extra: Workflow Escalation: Ensuring Control Continuity Conclusion

INTRODUCTION 

In today’s regulatory landscape, internal controls are no longer optional—they are an operational necessity. For organizations subject to the Sarbanes-Oxley Act (SOX), especially Section 404, demonstrating that transactions are properly authorized, reviewed, and traceable is critical to passing an external audit. Dynamics 365 Finance and Operations (D365FO) offers built-in workflow capabilities that, when thoughtfully configured, can enforce these control requirements directly within the system. This article explores how to design and implement approval workflows in D365FO that satisfy SOX compliance expectations, with a focus on practical configuration guidance, control alignment, and audit-readiness.

WHY EVERY SOX CONTROL FRAMEWORK MUST INCLUDE ROBUST APPROVAL WORKFLOWS

Section 404 of the Sarbanes-Oxley Act (SOX) requires management to assert—and external auditors to attest—that the company maintains effective internal control over financial reporting. In practice that means every financially significant transaction must be:

1. Authorized by the right people,

2. Executed in line with documented policies, and

3. Evidenced so that an auditor can reconstruct who approved what, when, and why.

Dynamics 365 Finance & Operations (D365FO) contains a flexible workflow engine that can satisfy all three conditions—if you design it properly. Approvals, when combined with Segregation of Duties (SoD) rules, prevent the classic “create and approve my own transaction” scenario that violates SOX assertions.

HOW D365FO WORKFLOW MAPS TO SOX CONTROL OBJECTIVES

To effectively support SOX compliance, organizations must align system capabilities with specific control objectives—and Dynamics 365 Finance offers the features needed to do just that.

CONTROL DESIGN CHOICES THAT AUDITORS WILL QUESTION

Even with strong workflow tools, poorly structured configurations can raise red flags during audits; understanding what auditors scrutinize helps avoid preventable issues.

CONFIGURING A SOX-READY PURCHASE ORDER APPROVAL (TEST OF DESIGN - the parts auditors ask for)

The steps below follow a purchase order (PO) scenario because POs hit multiple SOX-sensitive accounts—Commitments, Accruals, and ultimately COGS. Replicate the same pattern for vendor invoices, journal vouchers, or project change orders.

Scenario

• Every PO must be approved by a Procurement Manager who is not the originator.
• POs ≥ USD 25 000 receive a second approval from Finance.

Step 1 Enable change management for POs

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

2.On the General tab, activate Enable change management.

3.Set Allow override of settings per vendor to No to prevent policy bypass.

Step 2 Create a new workflow

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

2.Click New > Select Purchase order workflow.

3.Click Run.

4.Workflow editor is loaded.

5.Workflow editor pops-up.

Step 3 Add approval elements

1.In the graphical editor, drag Approve purchase order onto the canvas.

2.Double click on the approval element.

3.Select the sub-approval step and go to step properties.

Step 4 Approval step configuration

Basic settings: Directives for the approver.

Assignment: Approver assignment.

Select participant.

Switch to Role based tab.

Select User group participants in the type of participant.

Select Purchase order approvals in the participant field.

Let's add another approval step ford the Director review & approval.

Basic settings: Directives for the approver director.

Assignment: Approver assignment. Select the director's name here.

Condition: Indicate if this step will be executed under a certain condition.

According to our scenario, order needs to be approved by the director if purchase order's total amount is equal or greater than $25K. 

Save and activate the workflow.

New workflow is ready.

Note that first level approval will be sent to "Purchase order approval" user group. Let's make sure that the user group has the correct users.

Navigate to System administration > Users > User groups

Make sure that approvers are in the correct users.

Another important workflow control is to prevent the submitter from approving the workflow.

Navigate to System administration > Workflow > Workflow parameters.

Note: I will not activate this parameter for the demo purpose.

EXECUTING A SAMPLE PO APPROVAL  TO DEMONSTRATE EVIDENCE (TEST OF EFFECTIVENESS - the parts auditors ask for)

Go to Procurement and sourcing > Purchase orders > All purchase orders and create a new PO.

I've created a purchase order and submitted it to workflow approval.

Click Workflow > Submit

Enter a justification comment.

Workflow approval step 1 has been created.

Log in as Approver user. In the work items assigned to me section, open the record.

 

Let's approve the order by selecting Workflow > Approve.

The next step is to check workflow history to see if there is an action item. Note that there is another approval pending, the director approval due to the total amount is greater than $25K.

Let's approve the order, again. 

Check the workflow history now. Note that the approval workflow is now completed. 

AUDIT NOTE: Retrieving evidence is the most important point here. Take necessary screenshots of workflow history that shows approver user IDs, timestamps, comments and system/workflow version - exportable to excel for auditors.

Note that order status is now Complete.

NOTE: Demonstrate at least two additional edge cases

• Requester tries to approve own PO—system throws an error and says submitter cannot be approver;
• Approver misses 1-day SLA—workflow escalates automatically. Details have been explained below.

EXTRA: Workflow Escalation: Ensuring Control Continuity

In a SOX-compliant environment, timeliness of approvals is just as critical as the approval itself. Workflow escalation ensures that if an approver does not take action within a defined time frame, the task is automatically reassigned to another authorized user—typically a control owner. 

In Dynamics 365 Finance, escalation is configured within the workflow step properties:

Navigate to the approval step in the workflow editor and find the related step, open the properties.

Under "Time limits", set a duration (e.g., 1 day).

Go to Escalation tab.

My configuration says:

▶️ If the workflow step is not approved in 1 day, then it will be assigned to user admin,

▶️ If the workflow step is not approved in 4 hours, then it will be assigned to user Dadiyaman,

▶️ If the workflow step is not approved in 2 hours, then it will be automatically Rejected.

This mechanism ensures control continuity, avoids bottlenecks, and demonstrates that the organization has safeguards against delayed approvals—an important consideration during SOX audits.

CONCLUSION

Designing effective approval workflows in Dynamics 365 Finance is not just a matter of system configuration—it is a control activity that directly supports SOX compliance. When implemented with a clear understanding of control objectives, approval workflows can enforce proper authorization, support Segregation of Duties, and generate the audit evidence needed to validate financial governance.

This article demonstrated how to design and execute a SOX-compliant purchase order approval process in D365FO, from activating change management to enforcing dual-level approvals and workflow escalation. Each workflow design choice—such as preventing self-approvals, using value-based conditions, or defining time-bound escalation paths—should be mapped back to a specific control objective in your organization’s risk and control matrix (RCM).

Ultimately, the goal is to move beyond simply routing transactions for approval. A properly designed workflow provides assurance to management and auditors that transactions are reviewed by the appropriate personnel, decisions are logged and traceable, and control breakdowns are systematically prevented. With D365FO’s workflow engine, compliance teams can build these safeguards directly into the business process—creating a strong line of defense against financial misstatements and audit findings.