Simplification of Accounting As At Dates - Product Advisory

August 2021

With the release of 21R3, Accounting dates have been simplified to ensure logical processing of chronological events. In some cases, this changes the order in which events are processed, yielding different results and generating adjusting entries. These comprehensive changes improve the overall handling of convoluted combinations of accounting events and facilitate reconciliation with other accounting and disclosure reports.

Overview

Historically, the dates captured on many screens – particularly for “day two” events that change the accounting for a lease – have been confusing because they were used for multiple purposes. First and foremost, the user-specified as at date (labeled in some places as booking ledger date, ledger date, or effective date) served as the disclosure date – the date as at which the event would first be reflected on reports, both historical and future-looking. For postdated events, this allowed capture of the event before it happened, e.g., a five-year extension of a real estate lease starting from a date four months in the future, so that it could be disclosed as an obligation. This is not to be confused with the posting date – the date on which the first associated journal entry is dated. For postdated events, this is generally the date on which the event actually takes effect, but for backdated events, both the disclosure date and the posting date are constrained and cannot be before the first day of the first open fiscal period.

Within the system, however, there is a calculation date, which is in some cases surfaced to the user as a remeasurement date, which is critical for proper accounting. For postdated events, the calculation date is generally the same as the disclosure date, but for backdated events, the calculation date – unlike the other two dates – ignores month end close. Accounting is calculated as if the books were open, but the actual journal entries are aggregated up to and posted as adjusting entries in the first open period.

To better understand the distinction – and resulting problems – consider a classic hopscotch scenario. On March 1, you learned of a six-month renewal that had been negotiated to extend the assets on a lease starting July 1. For this renewal, the disclosure date and calculation date are both March 1, and the posting date is either July 1 (if the renewal was reasonably certain and does not require remeasurement) or March 1 (if the renewal constitutes a Change in Estimates and requires remeasurement). Two months later, on May 1, with the books closed through April, you learn that the negotiation also included a partial return of two assets on the lease effective March 31, and that the April, May, and June payments have been reduced to reflect the surviving payment for the remaining assets. In recording that return, the disclosure date and the posting date are constrained to May 1, as the books are closed, and the accounting will be posted as catch-up adjusting entries. However, the calculation date for the termination should still be March 31, with the surviving rental amount applied using a calculation date of April 1 (the first affected payment period).

This complexity in understanding how dates are selected and used has been left too much to the understanding of the user. With 21R3, LeaseAccelerator has significantly simplified how these dates are determined and, where appropriate, specified by the user. For example, when recording a backdated event which occurred in a closed period, there is no optionality concerning the disclosure date or the posting date – both must be the first open period. And with the exception of step payment renewals and step payment adjustments, there is no optionality regarding the calculation date used for the event either, so the user interface has been adjusted to reflect this.

Additionally, many clients – particularly those with 4/4/5 calendars and variants thereon – struggled with reperformance of calculations associated with mid-month remeasurements, particularly where such remeasurements were in the middle of both a fiscal period and a payment period, but where the payment period is not aligned with the fiscal period. To simplify these calculations, and in conformance with the standard practice of reporting based on monthly activity, all remeasurements are now aligned to the start of a fiscal month. For example, a six-month renewal effective March 10 for a Gregorian filer with periods closed through May will now be remeasured using a calculation date of March 1 to align with the start of the fiscal period. This ensures a full month of expense in the first fiscal month and reduces the complexity of expense recognition under various calendar structures.

UI Fields Impacted

The following workspaces will use a drop-down associated with the Ledger Date or Remeasurement Date instead of the standard date picker:

• Book Deal

• Payment Adjustment

• Record Asset Event

The following workspaces use a different presentation for Booking Ledger Date:

• Deal Summary

• Accounting Classification

Book Deal

In the new approach, the Ledger Date field will only allow a specific set of options, shown as a fiscal Month and Year, that can be used to record when a lease will become visible on reports. This is presented along with justification for why a date is applicable and if any adjusting entries will be created. In many scenarios, only one option is available. But it certain instances, a user is allowed to select from multiple options depending on the lease start date and the available open period(s). This feature in the UI guides users through lease entry and is best for current periods.

Note: No options will be given where the Ledger Date is after the Commencement Date.

When a lease has a start date in the past and that date is in a closed period, users will not see the Ledger Date label or drop-down. An explanation is shown for informational purposes related to the closed periods and adjusting entries.

When a lease has a start date in the past and that date is in an open period, users will see the Ledger Date label and drop-down, but they will only be able to select the fiscal period in which the event occurs.

When a lease has a start date in an open period and that date is in the current fiscal month and the previous fiscal month is still open, users will see the Ledger Date label and the drop-down. The available fiscal months to choose from are either the current period or the previous period and each fiscal period option gives additional information on when the lease will be recognized. Again, entering leases via the UI is best suited for activity in the current period.

Note: In the examples above, November is the first open period.

Side effect: Open books no longer allow historical reporting to be protected.

Side effect: Shifted remeasurement dates mean adjusting entries.

Deal Summary

The Booking Ledger Date in Deal Summary on the Summary tile is now shown as a fiscal Month and Year. This date reflects the first date on which the deal will be disclosed in accounting reports and corresponds to the first day of that fiscal period.

The Booking Ledger Date for existing deals shows the date as Month and Year to align with the new approach based on the Commencement Date and Fiscal Calendar and accounting is reflected as of the first day of the fiscal period. If the deal has an Available For Use Date (AFUD) that is earlier than the Commencement Date, then the fiscal period for the AFUD will be shown.

The date in the UI will not change with subsequent re-bookings when attempting to change only the Ledger Date in instances where you are given more than one option in the Book Deal workspace. If the wrong Ledger Date was used, then best practice is to delete and re-enter if periods are open, or rollback booking and re-enter if periods are closed.

Alternatively, if the Commencement Date requires a change, and if this is done from the Book Deal workspace, the Ledger Date will default to the fiscal period that contains the lease start date. The Booking Ledger Date in Deal Summary will not change as this is the date that the lease was first disclosed. The best practice in this scenario is to delete and re-enter if periods are open, or rollback booking and re-enter if periods are closed.

As noted above, if the Commencement Date is in a closed period, then you will not be presented with the option to select a Ledger Date. The Deal Summary shows the first open period in the Booking Ledger Date field.

If the Commencement Date is in the past, not in the current fiscal period, and in an open period, then you are only presented with one Ledger Date option which is the fiscal period in which the event occurs. Deal Summary shows this period in the Booking Ledger Date field.

When a lease has a start date in an open period and that date is in the current fiscal month and the previous fiscal month is still open, Deal Summary uses the option selected for the first date on which the deal will be disclosed in accounting reports from the Book Deal workspace.

Leases with start dates in the future, outside of the current available fiscal period(s) presented during booking, will show the Booking Ledger Date populated with the first date on which the deal will be disclosed in accounting reports from the Book Deal workspace.

Accounting Classification

The Booking Ledger Date option does not appear in the Reclassify Effective Date drop-down. For purposes of Accounting Classification, the only dates that have an impact on this are the Commencement Date and the Available-For-Use Date. The date format of the Reclassify Effective options remains the same, as prior to the new approach, as a month, day, and year; and is displayed the same in the Deal Summary Reclassify Events section. However, the accounting classification is performed as at the first day of the fiscal period in which the event occurs.

Payment Adjustment

In the new approach, the Remeasurement Effective Date/Posting Date field is renamed to Remeasurement Date and is replaced with a drop-down that more explicitly states what the date affects, along with an explanation of why the date is applicable. The Remeasurement Date label appears below the Reason For Change label.

Note: No options will be given where the Remeasurement Effective Date is after the affecting payments date.

For recurring payment adjustments, the affecting payments date is labeled ‘Change payment amount, starting:’.

For one-time payment adjustments, the affecting payments date is labeled ‘Change payment amount, for payment due:’.

For all one-time, or ‘Other’ recurring payment adjustments, the Remeasurement Date label and drop-down will not be available since one-time adjustments are not remeasured.

For recurring payment adjustments with Reason For Change not ‘Other’, the Remeasurement Date label and drop-down are shown.

For leases booked to IFRS 16 ledgers when using the Reason For Change of ‘Underlying index rate changed’, the label changes to ‘Remeasurement Date (IFRS 16 only)’.

Record Asset Event

In the new approach, the Ledger Date date picker was replaced with a drop-down that more explicitly states what the date affects, along with an explanation of why the date is applicable.

Note: No options will be given where the Ledger Date is after the affecting payments date.

When editing an EOT Event from Deal Summary using the kebab icon, please note that the Ledger Date for the event you are editing will not default to the date the event was last saved with, so it may be necessary to reselect this date.

In addition, the label for the Effective Date now changes based on which type of end-of-term option type is being recorded.

• Renewals have the label ‘First day of renewal period’

  

• Returns have the label ‘Return Date’

  

• Buyouts have the label ‘Buyout Date’

  

• Impairments have the label ‘Impairment Date’

  

• Others have the label ‘Asset Expiration Date’

  

• Upgrade/Trade-ins have the label ‘Upgrade/Trade-in Date’

  

Special Scenario - Step Payment Renewal

Consider a backdated lease has been captured in the system. The lease started in 2016, ending 12/31/2020, and had step payments with an annual escalator. The decision was made to renew the lease for three years, which requires recordation of a step payment renewal -- 12 months starting 1/1/2021 at one payment, 12 months starting 1/1/2022 at the next step up, and 12 months starting 1/1/2023 at the final step. As is appropriate, the same ledger date (1/1/2021) is used for all three to force a single remeasurement.

The three step renewals are being recording in June 2021, both May and June are open, the available Ledger Dates and an explanation for each date available in the drop-down are as follows:

12 months starting 1/1/2021 – January 2021 (Fiscal period in which the event occurs is closed. Adjusting entries will be created in the first open period)

12 months starting 1/1/2022 – January 2021 (Recordation of another step in a step renewal), May 2021 (Recognition of a postdated event in preparation for closing prior period), June 2021 (Fiscal period in which the postdated event is being recorded)

12 months starting 1/1/2023 – January 2021 (Recordation of another step in a step renewal), May 2021 (Recognition of a postdated event in preparation for closing prior period), June 2021 (Fiscal period in which the postdated event is being recorded)

Import Fields Impacted

The following Imports are impacted by this new feature:

• PIW

• Payment Adjustment

• Record Asset Event

• Modify Deal

Numerous existing validations have been updated and some have been removed to align with the approach.

The most notable apply to all imports listed above and are:

• In general, acceptable or recommended dates are provided in the validation messages.

• When the ledger date or remeasurement date specified is not the first day of the fiscal period LeaseAccelerator will provide a warning noting that the date will be adjusted back and provide the date.

• Treatment of backdated events are clearly noted with warnings or errors and dates are provided.

• Catch up entries are noted and the date when they are reflected is given, when applicable.

Portfolio Import

Users will notice that Ledger Date is no longer a required field in the new PIW for 21R3. The comments for the Ledger Date field give guidance on best practice. However, the PIW allows users to select the first day of any open fiscal period and is best for lease entry of historical deals.

• PIW Schedule tab comments for Ledger Date field:

  • If the Lease Start Date (LSD) is in closed period, leave this field blank. Accounting will be calculated as if the lease was recognized in the fiscal month in which it starts but journal entries will begin with catch up posting in the open period.

  • If Ledger Date is not specified and the LSD is in an open period, the lease will be recognized, and accounting will start in the fiscal month containing the earlier of the Lease Start Date and today's date. 

  • A ledger date prior to the LSD may be used to drive early recognition of leases that have a future commencement date. Any ledger date specified must be the 1st day of the fiscal period and in an open period.

    

In addition, users will notice that after Validating the PIW in the new approach, the Ledger Date drop-down is removed. This means when a PIW specifies a backdated Ledger Date, LeaseAccelerator will use the Lease Start Date, and if a PIW specifies a post-dated Ledger Date, LeaseAccelerator will use the current fiscal period. If no date is specified in a PIW, LeaseAccelerator will use the first day of the fiscal period for either the earliest AFUD or Lease Start Date.

New Bulk Import after Validation step 

Old Bulk Import after Validation step

Note: Ledger Date cannot be after the Lease Start Date. An error will appear blocking import.

Payment Adjustment Import

Upon import validation, users will receive a warning message if they specify a Remeasurement Effective Date for one-time payment adjustments, letting them know the system will ignore the date. No warning is shown if a Remeasurement Date is specified for ‘Other’ since they are never remeasured.

Users will notice in the new PIW on the Payment Adjustments tab, that the comments for the optional field are updated.

• PIW Payment Adjustments tab comments for Remeasurement Effective Date field:

  • If Remeasurement Effective Date is not specified, it will be recorded as the first day of the fiscal month containing the start of the first adjusted payment period or today's date whichever is earlier. Note, that the first day of the adjusted payment may be earlier than the effective date if payments are in arrears. When recording a step payment adjustment, each step of the adjustment should specify the same Remeasurement Effective Date.

    

Note: The Remeasure Effective Date cannot be after the affecting payments date. An error will appear blocking import.

Record Asset Event Import

In the new approach, the Ledger Date fields (3-columns) remain unchanged on both the standalone Record Asset Event import and the exported EOT Notification and Recordation reports.

If the ledger date fields are left blank, LeaseAccelerator will use the first day of the first open period. Best practice for the Ledger Date Day is to use the first day of the first open period or leave it blank and let the accounting engine use the correct date. If using a date that is not in the acceptable list of options, you will receive validation warnings or errors.

Note: The Ledger Date cannot be after the affecting payments date. An error will appear blocking import.

Modify Deal Import

In the new approach, the Ledger Date of the modified deal will be the earlier of the Modification Date and the date on which modification is recorded.

For additional information regarding the MDIW, but unrelated to this advisory, please review the Product Advisory for MDIW Auto Classification and Booking.

Reporting Impacts

As At Drop-downs and New Behavior

In the new approach, the As At drop-down in the reporting parameter is pre-populated with period end dates.

This parameter change applies to all reports that require an As At date parameter selection, except for disclosure reports, such as the ARO Disclosure Report, the MAR, and the QAR. The calendar widget is no longer available where the new drop-down appears.

The default As At period end date appears as the first option on the As At drop-down. The default As At period end date is the prior fiscal month’s end date, relative to the system date. This default enables users to easily select the closest fiscal month-end date, relative to the current system date. 

The drop-down selection of future As At reporting dates is limited to 60 days past the current system date. As At drop-down parameter options for future dates will only show fiscal month-end dates that fall within the 60-day criterion. The future As At date criterion applies to disclosure reports as well. For example, the QAR’s Current Period Reporting ASAT drop-down will only have fiscal month-end dates that are 60 days into the future.

All other As At options will appear under the default As At date in chronological and descending order.

How As At Works on the Ledger Export

It is important to note that the ledger date for any event, whether it is the initial booking or an event in the lease lifecycle, can only be on or before the affecting payment date. In other words, a ledger date prior to the lease start date, a payment adjustment or an asset even effective date can be used to drive early recognition, for financial statement disclosure purposes, of leases that have a future commencement date or a future payment adjustment or end of term event. The lease will be calculated, and accounting will start in the fiscal month containing LSD or AFUD, when applicable. Therefore, when generating the Ledger Export (LE), the As At must be at least equal to your initial Booking Ledger Date (BLD), if any date prior to the initial BLD is selected it will result in an error on the Excel report stating that this “IS NOT AN EXISTING DEAL IN THE SYSTEM”.

Report Parameters Example 1:  LSD 1-Oct-2021, BLD May 2021. The LE report parameters are shown in Figure 1. The lease is calculated, and accounting will start on the month containing the LSD as shown in Figure 2.

Figure 1

Figure 2

Report Parameters Example 2:  LSD 15-Oct-2018, AFUD 9-Sept-2018, BLD September 2018. The LE, parameters are shown in Figure 3. The lease is calculated, and accounting will start on the month containing the AFUD as shown in Figure 4.

Figure 3

Figure 4

LeaseAccelerator encourages you to take advantage of the Release Preview period to give this a spin!