Dynamics 365 Finance 10.0.49: Excluding Closing Period Transactions from Outstanding Encumbrances

Overview

Microsoft Dynamics 365 Finance version 10.0.49, planned for September 2026, introduces a new option in the Outstanding encumbrance report. After the related feature is enabled, users can exclude transactions associated with closing periods from the report.

This is primarily relevant to organizations that use encumbrance accounting, budget control and formal year-end closing periods. It addresses a reporting problem rather than introducing a new accounting process.

The main objective is to let report users separate operationally outstanding commitments from transactions recorded specifically during financial close. This should reduce the need to export the report and remove closing-period activity manually.

What changes in version 10.0.49

Before this update, the Outstanding encumbrance report could include transactions posted in closing periods. Depending on an organization’s year-end procedures, these entries could make it harder to identify which encumbrances represented normal open commitments.

The new capability adds a report-level choice to omit closing-period transactions. A user preparing the report should therefore be able to decide whether the output should:

• Include transactions from closing periods, consistent with the previous reporting scope.
• Exclude closing-period transactions and focus on the remaining encumbrance activity.

The feature is activated through Feature management.

Enabling the feature should not be treated as equivalent to selecting the new report option. Feature management makes the capability available, while the report parameter determines how a particular report run is filtered. This distinction should be confirmed during testing because Microsoft’s short release description does not specify the option’s default value.

The pain point in the previous behaviour

Closing periods serve a different purpose from ordinary operating periods. They are commonly used to isolate year-end adjustments, final allocations or other close-specific postings from routine accounting activity.

When closing-period transactions appeared in the Outstanding encumbrance report, finance teams could encounter several practical problems:

• The report did not align directly with an operational list of open commitments.
• Users had to identify close-specific entries outside the standard report.
• Excel-based filtering introduced an additional manual control step.
• Different users could apply different exclusion rules and produce inconsistent totals.
• Reconciliation between budget reports, procurement records and year-end schedules became harder to explain.

The issue was not necessarily that the existing report total was mathematically incorrect. The problem was that transactions with different business purposes were presented together, while users had no standard report parameter to separate them.

Why the new option is an improvement

A parameter within the standard report provides a more repeatable basis for year-end analysis. Instead of relying on a user-defined spreadsheet filter, the distinction can be made when the report is generated.

This can improve the process in three areas.

Clearer reporting scope

The report request can state explicitly whether closing-period activity is included. Reviewers can understand the basis of the reported total without reconstructing an external filtering method.

More consistent reconciliation

Budget managers and accountants can run both variants and reconcile the difference. In principle, that difference should represent the closing-period transactions affected by the new filter, subject to the actual selection logic implemented by Microsoft.

Reduced manual processing

Where teams currently export report lines and remove closing-period entries manually, the new option may eliminate that step. The benefit will be greatest in legal entities with many year-end adjustments or detailed encumbrance activity.

Behaviour that must be verified

The release information does not define several important technical details. Do not build a production procedure around assumed behaviour without testing them.

The following points remain assumptions to verify:

1. How a closing-period transaction is identified. It is reasonable to expect that the report uses the fiscal calendar period type, but Microsoft’s brief description does not confirm the exact query logic.
2. Which date controls the classification. The filter may evaluate an accounting date, source document date or another date carried by the encumbrance transaction.
3. How reversals and carry-forward entries are handled. A transaction originating in one fiscal year but reversed or carried into another may cross operating and closing periods.
4. Whether the option is selected by default. The default report parameter value is not specified.
5. Whether saved report settings retain the selection. Usage data, saved queries or batch configurations may preserve parameter values, but this must be tested.
6. Whether the feature changes only presentation or also report calculations. The published scope indicates a reporting option and does not describe any change to posting, budget control or encumbrance accounting. Confirm this by comparing underlying transactions before and after activation.

Who is affected

Roles

The following roles should review the change:

• Budget managers who monitor available budget and outstanding commitments.
• General ledger accountants responsible for fiscal year-end processing.
• Procurement and purchasing controllers who reconcile purchase commitments.
• Public sector finance users working with encumbrance accounting.
• Financial controllers who approve year-end reports.
• Dynamics 365 Finance administrators responsible for Feature management and deployment validation.

Processes

The feature can affect reporting procedures for:

• Year-end encumbrance review.
• Budget-to-actual and commitment reconciliation.
• Purchase order commitment analysis.
• Audit support and closing documentation.
• Encumbrance carry-forward validation.
• Recurring or batch-generated encumbrance reports.

Legal entities

The feature is most relevant to legal entities that both use encumbrance accounting and post transactions into fiscal closing periods. A legal entity that does not use closing periods, or has no encumbrance activity in those periods, may see no material difference.

Feature activation and report parameter persistence may not follow the same organizational scope. Confirm whether activation is environment-wide and whether the report selection is stored per user, per company or per batch job in the deployed build.

What to do before the update

1. Identify current report usage

Document where the Outstanding encumbrance report is used, including:

• Legal entities and fiscal calendars.
• Report owners and recipients.
• Batch schedules.
• Excel-based adjustments.
• Reconciliation workbooks and audit procedures.

Pay particular attention to instructions that tell users to remove year-end or closing-period entries manually.

2. Build a baseline

Before enabling the feature, retain sample outputs for at least one closed fiscal year. Record the report parameters and total outstanding encumbrance amount.

Prepare a list of known transactions posted in:

• An operating period.
• A closing period.
• A period around the fiscal year boundary.
• A reopened or adjusted period, if applicable.

3. Review fiscal calendar setup

Confirm which periods are configured as closing periods for each affected calendar. Incorrect period classification could lead to misleading test conclusions even if the report works as designed.

4. Define expected results

For each test transaction, specify whether it should appear when the new exclusion is selected. Do not define the expectation only at total level; line-level evidence is needed to explain any difference.

Testing after the update

Enable the feature first in a sandbox or user acceptance testing environment. Then perform the following checks:

1. Run the report using the previous-equivalent selection, with closing-period transactions included.
2. Compare the output with the pre-update baseline.
3. Run the report again with closing-period transactions excluded.
4. Compare both outputs at line and total level.
5. Reconcile the difference to known closing-period entries.
6. Test multiple legal entities and fiscal calendars.
7. Test carry-forward, reversal and year-boundary scenarios where used.
8. Verify interactive, batch and saved report executions.
9. Confirm that posting, budget balances and source document status remain unchanged.

If the difference includes transactions from normal operating periods, capture the voucher, accounting date, fiscal period and source document. This evidence will help determine whether the result is caused by period setup, report logic or test data.

Production adoption

After successful validation, update the reporting procedure so that users know which selection to use for each purpose. The report title alone may not communicate whether closing-period entries were included, so retained evidence should include the parameter page or another record of the selected scope.

It can also be useful to run both variants during the first production year-end. The reconciliation between them provides a direct control over the transactions removed by the filter.

The feature should be adopted as a controlled reporting change, not simply enabled because it is available. Its value depends on fiscal calendar design, year-end posting practices and the organization’s definition of an operationally outstanding commitment.

References

• What’s new or changed in Dynamics 365 Finance 10.0.49