Audit Trail, Change Log, and Compliance in D365 Business Central

How BC’s change log works, which tables and fields Finance must log, the GL entry audit trail and why it is designed the way it is, the document approval workflow controls that satisfy auditor requirements, the data retention and document archiving setup, and the annual audit readiness review Finance should conduct before the auditors arrive.

The GL Audit Trail—Why It Is Designed the Way It Is

BC’s General Ledger has an immutable audit trail by design. Once a journal entry or document is posted, the resulting GL entries cannot be modified or deleted. This is not a limitation—it is a fundamental accounting control. The GL Entry table in BC is a permanent record: every entry has an Entry No., a User ID (who posted it), a posting date, a source document reference, and a description that connects back to the originating transaction. A GL entry that appears incorrect cannot be changed; it must be reversed with a new offsetting entry, which itself becomes a permanent part of the audit trail. The reversal entry references the original entry. Every correction is visible and traceable.

This immutability is why Finance can answer the auditor’s question “show me all journal entries posted by user X between January and March” with a simple GL Entry query filtered by User ID and date range. It is also why the question “who approved this transaction?” requires looking not in the GL (which shows who posted it) but in the approval workflow history (which shows who approved it before posting). BC maintains both: the GL for the permanent transaction record, and the Approval Entry table for the approval chain that authorized the posting.

The Change Log—What It Tracks and What Finance Must Configure

BC’s Change Log (Finance → Administration → Change Log Setup) records field-level changes to BC table records: who changed it, when, what the previous value was, and what the new value is. Unlike the GL’s automatic immutable trail, the Change Log must be explicitly configured by Finance to log specific tables and fields. Nothing is logged by default. Finance must decide which tables matter and turn logging on for the fields that carry audit risk.

Table / Field	Risk if Unlogged	Logging Priority
Vendor — Bank Account No.	A vendor banking detail change before a large ACH payment cannot be traced without the change log. Classic payment fraud vector: change the vendor bank account, receive one payment, restore the original account.	Critical — log all changes
Vendor — Payment Method, Payment Terms	Changes that accelerate payment timing or switch from check to ACH without Finance awareness.	Critical — log all changes
Customer — Credit Limit	A credit limit increase on a customer before a disputed large order. Without the log, Finance cannot determine when the limit changed or who authorized it.	Critical — log all changes
General Posting Setup — Sales/Purchase Account	A posting group account change that redirects revenue or expense postings to a different GL account. Can mask misclassification or be used to manipulate reported income.	Critical — log all changes
G/L Account — Account Type, Direct Posting	Changes that allow direct posting to accounts that should be controlled (summary accounts, balance sheet accounts that should only be populated by subledger postings).	High — log all changes
Customer — Blocked, Currency Code	Unblocking a blocked customer allows transactions that should have been prevented. Currency code changes affect invoicing and collection in unexpected ways.	High — log all changes
User Setup — Allow Posting From/To, Amount limits	Changes that expand a user’s posting date window or amount limits outside their authorized range.	High — log all changes
Item — Unit Cost, Costing Method	Costing method changes on existing items affect inventory valuation going forward. Unit cost changes affect COGS on all future sales of the item.	Medium — log changes to cost fields
Employee — Bank Account (if used for expense reimbursement)	Same vendor banking detail risk applied to employee expense reimbursements processed through BC.	Medium — log bank-related fields

Document Approval Workflows—The Control Evidence Auditors Ask For

The auditor’s standard request for “documentation of the purchase invoice approval process” has two parts: the policy (who is required to approve, at what thresholds) and the evidence (proof that the approvals actually occurred for the invoices in the sample). In BC, the evidence lives in the Approval Entry table, which stores every approval request, approval decision, and rejection with the approver’s User ID and timestamp. The Approval Entries page (accessible from the purchase invoice or from Workflow → Approval Entries) provides the evidence trail for any specific transaction.

BC’s workflow engine (covered in Post 6 for the GL journal context) supports approval workflows for purchase invoices, purchase orders, sales orders, general journal batches, and payment journals. For audit readiness, Finance must ensure: approval workflows are active for the document types that the audit scope requires, approval thresholds reflect the organization’s current authorization matrix (not the go-live matrix that may be two years out of date), and the workflow history is retained and accessible for the audit period being examined.

Data Retention, Document Archiving, and the Audit Period

D365 BC is hosted on Microsoft’s infrastructure with continuous backups. Microsoft’s standard retention for BC Online environments is 28 days of point-in-time recovery, with longer retention available through the Microsoft Azure backup infrastructure. For the statutory records retention requirement (seven years for US financial records, ten years in some jurisdictions), Finance must understand what is covered by Microsoft’s infrastructure and what Finance must supplement with BC’s document archiving and export capabilities.

BC retains all posted ledger entries permanently within the production environment for the life of the subscription—they are never automatically purged from the GL Entry, Customer Ledger Entry, Vendor Ledger Entry, or other permanent tables. What BC does not guarantee is the retention of unposted documents: unposted purchase invoices, unposted journals, draft sales orders. Finance should configure Document Archiving (found in the Document Management setup) to retain copies of posted sales and purchase documents for the audit period. Archived documents are read-only copies that preserve the original document format as it existed when posted, separate from the live transaction record.

For long-term audit trail access—particularly for regulatory examinations that may require records from several years prior—Finance should also maintain an annual data export: a BC data export or a Power BI historical snapshot that captures the full GL entry detail, the Change Log entries, and the Approval Entry history for each completed fiscal year. Store the export in a controlled SharePoint archive. If the organization ever needs to provide evidence from a period that predates the current BC configuration or subscription, the export ensures the evidence is available independent of the live BC environment.

The Annual Audit Readiness Review

Finance should conduct a structured audit readiness review six to eight weeks before the external auditors arrive. The review has four components:

Change Log Coverage Review
- Open BC’s Change Log Setup and verify that all critical tables and fields identified during implementation are still configured for logging. BC updates and extension installations can occasionally reset or affect Change Log settings. Confirm that the log contains entries for the audit period for each critical table. If a critical field shows no log entries for the past year, investigate whether the logging was active or whether the field was simply never changed.
Workflow and Approval Matrix Reconciliation
- Compare BC’s configured workflow approval limits and approvers to the current authorization matrix. Identify any discrepancies—thresholds that were not updated when the matrix changed, approvers who have left the organization and whose workflow assignments were not transferred, or document types that should have approval workflows but do not. Correct all discrepancies before the audit begins; an auditor who identifies them during field work has a finding.
User Access Review (Pre-Audit)
- Run the quarterly access review described in Post 25 specifically as a pre-audit preparation step. Confirm that no active users have SUPER access who are not BC administrators. Confirm that the SOD conflict list shows no active unresolved conflicts. Prepare the documented access review evidence that the auditor will request as part of IT general controls testing. If the quarterly reviews were documented throughout the year, this step is a final confirmation; if quarterly reviews were skipped, this step is a catch-up that will reveal accumulated access issues.
GL Reconciliation Package Preparation
- Prepare the standard reconciliation package the auditor will request: trial balance, account reconciliations for all significant balance sheet accounts, the bank reconciliation for each bank account, the AR aging reconciled to the GL AR balance, the AP aging reconciled to the GL AP balance, the fixed asset register reconciled to the GL net fixed assets balance, and the inventory valuation report reconciled to the GL inventory balance. Having this package complete before the audit begins compresses the field work timeline and demonstrates to the auditor that Finance has controls over the completeness and accuracy of the financial records.
Document Archive and Evidence Availability Check
- For the fiscal year under audit, verify that all posted sales invoices, purchase invoices, and journal entries are accessible in BC and that the document archive contains copies. Pull one sample transaction from each major cycle (AR, AP, GL) and trace the full evidence chain: the original document, the approval workflow history, the posted ledger entry, and the Change Log for any master data changes relevant to that transaction. If the full chain can be traced in 10 minutes for a sample transaction, it can be traced for any transaction the auditor selects.
Configuration Change Log for the Year
- Prepare a summary of significant BC configuration changes made during the fiscal year under audit: chart of accounts changes, posting group changes, workflow threshold changes, extension installations and removals. Finance should be able to explain when each change was made, who authorized it, and what business reason drove it. Configuration changes that the auditor discovers from the Change Log but that Finance cannot explain from documentation are audit findings. The change management protocol from Post 26 should have produced this documentation automatically if it was followed; the pre-audit review confirms the documentation exists and is complete.

Five Audit Trail Mistakes Finance Regrets

⚠️ Vendor Bank Account Change Not Logged—Payment Fraud Investigation Has No Evidence Trail

A $127,000 ACH payment is made to a vendor’s “new banking details” that the AP coordinator updated in BC after receiving an email purportedly from the vendor requesting a bank account change. The payment does not arrive at the vendor. Finance investigates and determines the email was a social engineering attack. The attacker had the vendor’s BC vendor number, contact name, and invoice history. Finance asks IT to determine when the bank account was changed and which user made the change. IT looks at the Vendor table in BC. The Change Log for the Vendor table was not enabled. There is no record of when the bank account field was last modified or which user modified it. The fraud investigation cannot establish the timeline or the access point without the Change Log evidence that would have been captured automatically if logging had been configured.

Fix: Enable Change Log logging for the Vendor table, specifically for the Bank Account No., Payment Method Code, and Payment Terms Code fields, before any vendor payments are made from the system. The Change Log setup for these fields takes five minutes and provides permanent before-and-after evidence for every vendor master change for as long as the log is retained. Configure the same logging for the Customer table’s credit limit and banking fields. These are the highest-priority Change Log configurations in any BC implementation; they should be part of the go-live checklist, not a post-incident remediation. If the Change Log is not currently configured for these fields, configure it today—it begins logging from the configuration date forward.

⚠️ Change Log Grows Unchecked to 4 Million Records—BC Performance Degrades Noticeably

The implementation team configured the Change Log broadly—logging enabled on 18 tables, including the Item Ledger Entry table and the Customer Ledger Entry table. The Item Ledger Entry table logs a change record every time an item ledger entry is posted. In a distribution company processing 400 inventory transactions per day, the Change Log accumulates 400 records per day from the Item Ledger Entry table alone. Over two years, the Change Log table has 290,000 records from the Item Ledger Entry table alone, plus records from 17 other tables. Total size: 4.1 million records. BC users begin noticing that certain page loads are slower than at go-live. IT traces the performance degradation to queries that scan the Change Log table. The fix requires a Change Log purge and reconfiguration of the logging scope.

Fix: Never enable Change Log logging on transaction tables (Item Ledger Entry, Customer Ledger Entry, Vendor Ledger Entry, GL Entry, Value Entry). These tables have their own immutable audit trails. Logging them in the Change Log creates redundant records at very high volume and serves no audit purpose the original ledger entries do not already provide. Limit Change Log logging to master data tables (Vendor, Customer, Item, G/L Account) and configuration tables (General Posting Setup, VAT Posting Setup, User Setup, Workflow Setup). Configure the Change Log purge to run automatically for entries older than the retention period, using the Delete Change Log Entries batch with a scheduled date. Review the Change Log table size quarterly and investigate any unexpected growth.

⚠️ Approval Workflow Thresholds Are Two Years Out of Date—Auditor Finds That Invoices Above the Authorization Matrix Limit Have Been Auto-Approved

The board-approved authorization matrix was updated 18 months ago: purchase invoices between $10,000 and $50,000 now require VP approval, up from the prior $25,000 threshold. Nobody updated BC’s purchase invoice approval workflow. The workflow still automatically approves invoices up to $25,000 without human review. In the 18 months since the matrix was updated, 34 purchase invoices between $10,000 and $25,000 posted without the required VP approval. The auditor identifies the discrepancy during the review of the authorization matrix against BC’s workflow configuration. The finding: 34 invoices totaling $416,000 were processed without required authorization for 18 months. The control failed not because the workflow was broken but because it was never updated to match the policy change.

Fix: The authorization matrix and BC’s workflow configuration must be treated as a linked pair. Whenever the authorization matrix changes—whether by board approval, CFO directive, or business unit policy update—BC’s workflow approval limits must be updated in the same change management cycle, before the new policy takes effect. Finance should own the workflow configuration update; it is a Finance control, not an IT task. Include a “workflow threshold current” check in the quarterly access review: compare the current workflow approval limits in BC to the current authorization matrix on file and document that they agree. This 15-minute quarterly check prevents the 18-month undetected divergence scenario.

⚠️Posting Periods Are Never Locked—Prior-Period Entries Post Without Finance Awareness

BC’s User Setup page allows Finance to restrict each user’s posting date range to prevent posting in closed periods. At this organization, no posting date restrictions are configured for any user. Seven months after March is closed and the March financial statements are finalized, an AP coordinator posts a purchase invoice dated March 15 because the vendor sent a corrected invoice for a prior period and the coordinator coded it to March without checking with Finance. The March GL entry posts silently. The auditor, who relied on the finalized March financial statements, asks Finance to explain the March entry with a July posting date. Finance cannot explain it without researching the AP coordinator’s actions; the coordinator doesn’t remember the specific invoice.

Fix: After each period is closed and the financial statements for that period are finalized, lock the period by setting the Allow Posting From date in the User Setup to the first day of the next open period. For the entire Finance team, the posting date range should move forward with the close cycle: after March is closed, the minimum posting date for all Finance users is April 1. Only the Controller or a designated administrator should have access to post in a prior period, and any prior-period posting must go through a documented exception process with Controller approval. The User Setup posting date restriction is a 10-minute configuration change per user after each close—this is the control that prevents silent prior-period postings from appearing in finalized statements.

⚠️No Audit Readiness Review Conducted—Audit Fieldwork Uncovers Issues That Finance Should Have Found First

The external auditors arrive and begin fieldwork. On day three, they identify: a vendor whose bank account changed two days before a $93,000 payment (Change Log not configured, no evidence available), a purchase invoice for $34,000 that bypassed the approval workflow because the invoice was entered through a batch import that the workflow does not intercept, three prior-period journal entries posted in the current period with no Controller approval documentation, and a user who has SUPER access and also approves her own purchase invoices. None of these findings are the result of fraud or intentional misconduct. All of them result from Finance not having conducted the structured audit readiness review that would have identified and corrected each issue before the auditors arrived. The auditor issues four findings. Finance management spends the next three weeks responding to management letter items.

Fix: The annual audit readiness review, conducted six to eight weeks before the auditor arrives, is the Finance activity that converts audit findings from discoveries into pre-emptive corrections. Finance finds the issue, fixes it, and documents the fix. The auditor either does not find the issue (because it was corrected) or finds it and finds the correction already documented (which converts a finding into a disclosed and remediated item). The readiness review is not glamorous work and does not produce anything visible to management in normal times. Its value is entirely in what does not appear in the management letter at the end of the audit. Build it into the annual Finance calendar as a standing six-week pre-audit project, assign the review components to specific team members, and document the results formally.

Do This / Don’t Do This

Do This

Configure Change Log logging for vendor bank account fields, posting group configuration tables, and customer credit limit fields as a go-live requirement
Limit Change Log logging to master data and configuration tables—never transaction tables
Schedule the Change Log purge automatically for entries older than the retention period
Lock posting periods after close by updating User Setup Allow Posting From dates
Reconcile BC’s workflow approval thresholds to the authorization matrix at each quarterly access review
Conduct a structured six-component audit readiness review six weeks before the auditors arrive
Maintain annual data exports for long-term audit trail access independent of the live BC environment
Document all configuration changes with authorization, business rationale, and date—the Change Log records who made the change; Finance documentation records why

Don’t Do This

Leave vendor bank account fields unlogged in the Change Log—this is the highest-risk master data change in any AP environment
Enable Change Log logging on high-volume transaction tables—performance degradation is inevitable
Allow posting date restrictions to go unconfigured—prior-period postings will appear in finalized statements
Update the authorization matrix without updating BC’s workflow approval limits in the same change cycle
Treat the annual audit as the first time Finance reviews its control environment—auditor discoveries are Finance failures, not audit discoveries
Assume BC’s Microsoft-managed infrastructure covers the full statutory records retention obligation—supplement with document archiving and annual exports
Skip the audit readiness review in a year where “things are running smoothly”—audit findings surface in good years because the preparation was skipped

Up Next:

Audit trail and compliance closes the governance arc of the BC series. The next post moves to one of BC’s most practically useful Finance modules for product- and distribution-based businesses: Warehouse Management and Inventory Costing in Business Central—how BC’s warehouse management tiers work, the costing method decision Finance must own at implementation, how inventory valuation interacts with the GL, the cost adjustment process and why Finance must understand it, and the inventory reconciliation Finance needs to run at every period close.

— Bobbi

D365 Functional Architect · Recovering Controller

Thank you for reading!

If this post helped you solve a real problem, share it with a Finance colleague who is in the middle of an ERP implementation or a post-go-live optimization. If you have a topic that I haven’t covered, please reach out. There is always one more post worth writing.

Interested in learning more? Here are a few of my latest posts: