A finance systems admin gets a message from the controller two days before month-end close: the Income Statement pulled into the board deck last quarter grouped two expense accounts differently than this quarter’s version does, and nobody can say who changed the row definition, or when. In most Business Central environments today, that question has no good answer, because there has never been a financial report change log tracking those definitions. General ledger entries are tracked obsessively. Posted documents are locked down. But the row, column, and report definitions that decide what a financial statement actually shows have sat outside the audit trail entirely, unless someone thought to add them to Change Log Setup years ago, which almost nobody did.
Business Central 2026 release wave 2, shipping as version 29, closes that specific gap. Two general-availability features land together: a financial report change log that runs automatically with no setup required, and a G/L account tracing tool that lets report authors see exactly how an account feeds into a calculation before they publish it. Both are currently in public preview, running from the first week of September through the first week of October 2026, with general availability expected once the wave completes its rollout in October. Neither one touches how reports are distributed. This is about knowing what changed in the definitions themselves, and why a number moved.
Why financial report definitions were an audit blind spot
Business Central’s Change Log has existed for years, and it works well once configured. An administrator opens Change Log Setup, picks the tables worth watching, and chooses between tracking every field or a curated subset, since tracking everything tends to bloat the database and slow things down. Microsoft’s own guidance steers people away from logging ledger entries and posted documents for exactly that reason, and toward system fields like Created By and Created Date instead. The result is a tool that most BC partners configure around customers, vendors, and a handful of setup tables, because that’s where the obvious audit risk lives.
Financial report row definitions, column definitions, and report definitions rarely make that list. They’re metadata, not transactional data, so they don’t feel like an audit priority in the same way a blocked vendor or a changed payment term does. But a single edit to a row definition, adding an account to a subtotal, changing a totaling formula, retiring a category mapping, can silently change what every downstream financial report shows without touching a single ledger entry. That’s precisely the kind of change that’s hard to catch after the fact and easy to miss during a routine change log review, because nobody thought to put it there.
What the financial report change log actually captures
The new financial report change log in BC29 doesn’t require anyone to open Change Log Setup at all. Direct modifications to financial row definitions, column definitions, and report definitions are recorded automatically, the moment they happen, regardless of whether change logging is turned on for anything else in the environment. Entries land on the same Change Log Entries page administrators already use for everything else: who made the change, what table and field, the old value, the new value, and when it happened.
That last detail matters more than it sounds. Business Central’s Change Log has a well-known quirk where entries don’t actually appear until the acting user’s session refreshes, whether that’s a session timeout, a company switch, or a full sign-out and sign-in. Teams unfamiliar with that behavior sometimes conclude the log isn’t working when a change made minutes ago doesn’t show up yet. That quirk applies here too, so it’s worth flagging to anyone reviewing financial report changes in near real time during a close cycle.
Because this tracking is always on for report definitions specifically, it sidesteps the performance tradeoff that governs everything else in Change Log Setup. Report and row and column definitions are edited rarely compared to transactional tables, so logging every field on them doesn’t carry the same database bloat risk that logging every field on, say, the G/L Entry table would. Microsoft appears to have made that call deliberately rather than leaving it to each partner to configure correctly, or more likely, not configure at all.
Tracing G/L account usage before you publish a change
The second GA feature addresses a different, more immediate problem: figuring out where a specific account shows up across a financial report before you make a change that affects it, rather than after. Financial reports in Business Central are built from row definitions and column definitions that act as two separate vectors, with each report cell calculated by applying a row’s formula against a column’s data definition. Rows commonly reference G/L Account Categories rather than individual accounts, a deliberate design choice that keeps a report resilient when the chart of accounts changes underneath it. That resilience comes at a cost: it’s genuinely hard to eyeball a row definition and know which accounts it actually pulls in, or whether an account has drifted out of its intended category entirely.
The account tracing capability gives report authors a way to identify uncategorized accounts and see how a given account maps into calculations, directly from within the report definition, before publishing. Paired with the change log, this closes a loop that previously required guesswork: an admin can now both trace forward, from an account to the reports it touches, and trace backward, from a report change to who made it and when.
What technical teams should actually do with this
Because the financial report change log is automatic and requires no configuration, there’s no setup checklist for the feature itself. The work is in the surrounding governance. Start by pulling the current Change Log Setup and confirming nobody already added the financial report tables manually in an attempt to solve this problem years ago; a duplicate log entry per change isn’t harmful, but it’s noise nobody needs. Next, decide on a retention policy specifically for these entries. Financial report definitions tend to see concentrated edit activity around fiscal year-end and during audit prep, when finance teams restructure statements for new account categories or reporting requirements, so a policy that clears entries older than a fixed window keeps the Change Log Entries page useful rather than cluttered with years of routine tuning.
It’s also worth briefing whoever owns financial reporting on the distinction between this feature and Field Monitoring, Business Central’s related capability that sends email alerts when sensitive fields change. Field Monitoring and Change Log Setup are mutually exclusive per table specifically to avoid redundant tracking, and the new automatic report-definition logging sits alongside both as a third, always-on mechanism. Nobody needs to configure alerts for report definition changes to get the audit trail, but a team that wants proactive notification rather than after-the-fact review will still need to build that separately, since the change log records history rather than pushing alerts.
One adjacent BC29 feature worth a brief mention, since it ships in the same wave and touches the same reports, is the ability to bundle multiple financial reports into a single scheduled PDF output. That’s a distribution capability, not a governance one, and it solves a different problem than the one this article covers. Teams evaluating both should treat them as separate rollout decisions: get the audit trail and account tracing configured and understood first, since that’s what protects report integrity, and treat distribution scheduling as a convenience layer on top once the underlying definitions are something you trust.
The practical payoff
None of this changes how anyone builds a financial report in Business Central. Row and column definitions still work exactly as they did, account categories still map the same way, and the Financial Reports page still looks the same. What changes is accountability. The next time a board-ready statement looks different from the prior quarter’s version and someone asks why, the answer no longer depends on institutional memory or a lucky guess about who touched what. It’s a filtered view on the Change Log Entries page, showing exactly which row, column, or report definition changed, who changed it, and what the value was before.
For organizations running Business Central as their financial system of record, particularly those with external auditors who ask pointed questions about report governance, that’s a meaningful gap closing quietly rather than a headline feature. Routeget Technologies has been walking clients through exactly this kind of financial reporting governance review as BC29 moves from preview toward general availability, and the pattern holds across nearly every environment we’ve looked at: the change log gap was real, and almost nobody had closed it on their own.
#BusinessCentral #FinancialReportChangeLog #ERPGovernance #GLAccountTracing #FinanceAutomation #ERPAuditTrail