Change log and audit trail in Business Central

The change log is Business Central's data-change audit trail. Every monitored table, column, and event (insert, modify, delete, rename) can be recorded, producing an immutable history of who changed what when. Customers in regulated industries (finance, pharma, food, public sector) rely on it; everyone else should at least know what it does.

The model. Two layers of configuration:

1. Change Log Setup (overall) — a master switch that turns logging on or off for the tenant.
2. Change Log Setup (Tables) — a per-table, per-action configuration. For each table, the administrator chooses what to track per event:

• All Fields — every column change is logged.
• Some Fields — only the columns marked individually are logged.
• No — no change tracking for this event.

This per-table, per-event control is what makes the change log practical rather than overwhelming. Logging every change on every table on a transactional system would generate massive volume; logging only sensitive columns (customer credit limit, vendor bank account, payment terms) on critical tables is sustainable.

What gets logged. Each change-log entry records:

• Table and field.
• Type of change (insert, modify, delete, rename).
• User who made the change.
• Date and time.
• Old value.
• New value.
• Primary key of the affected record.

Retrieval. The Change Log Entries page lists every entry, filterable by user, table, date range, primary key. Drilldowns show context. For audit work, entries export to Excel for archiving.

Performance impact. Change logging is not free. Each logged column adds a write to the change log table on every change to that column. Heavily-logged tables (sales lines, item ledger entries) slow down. Best practice:

• Log master data tables comprehensively — customer card, vendor card, item card, GL account, dimension values.
• Log a few critical transaction tables narrowly — only the fields that matter for audit.
• Don't log high-volume transaction tables broadly — the cost-benefit doesn't justify it.

Other audit signals. The change log isn't the only audit surface in BC:

• G/L entries are immutable by design — every posted journal is the audit record.
• Posted documents (sales invoices, purchase invoices, shipments) are immutable; corrections post a counter-document.
• Workflow approval entries record every approval action.
• Application Insights telemetry captures session events, error events, page navigation, and API calls.
• Activity Log (a separate feature) tracks specific high-level operations (data sync runs, security changes).

Compliance. For regulated regimes that require demonstrable audit (FDA 21 CFR Part 11 for pharma, similar regimes in food, financial services compliance like SOX), the change log plus the immutable G/L and posted documents form the foundation. ISVs sometimes layer additional audit modules for stricter regimes.

Retention. Change log entries are retained until manually purged. Build a retention policy aligned to statutory requirements (typically 7+ years for financial audit) and a periodic cleanup of older entries beyond the retention period.

Operational reality. Enable change log on master data from day one; tune transactional logging based on actual audit needs in the first months. Don't wait for the first audit to start logging — retroactive audit doesn't work.