Considerations for Multiperiod Accounting

To achieve a successful implementation of multiperiod accounting feature in Accounting Hub, the following points must be taken into consideration.

Determine when to raise a new accounting event

Determine when a new accounting event must be raised throughout the life cycle of a multiperiod transaction.

If only the multiperiod start and end dates are changed, a new accounting event isn't required. As the transaction object is maintained to provide the new multiperiod start date, the impact of the change is reflected in the next multiperiod journal.
Raise a new accounting event if the amount is changed, or a transaction is canceled after the transaction is accounted in a Final status.

If the multiperiod start date is changed after the transaction is accounted, it's not necessary to raise a new accounting event. The assumption is that all other transaction attributes remain the same. If the transaction object is maintained to provide the new multiperiod start date, the impact of the change is reflected in the next multiperiod journal. This depends on the prorate method and is also true for future journal entries.

However, if the transaction amount is changed after the transaction is accounted; the new accounting event is needed, which affects the total deferral amount.

Tip: We suggest a detailed analysis be performed to determine whether to raise a new accounting event when transaction attributes are updated.

Raise a transaction reversal event

Consider the multiperiod journal accounting date when raising the transaction reversal event.

Set the reversal accounting date to a date after the last multiperiod journal with Final status. A reversal entry reverses all existing final entries, including the multiperiod journals, with the reversal accounting date.

For example, the transaction accounting date is on 01-Feb and multiperiod journals have been created for February and March with a Final status. If the transaction is canceled, the cancellation event should be set to 01-Apr or the first day of the next open period, whichever is later.

Provide the multiperiod start and end dates

The multiperiod start date and multiperiod end date must be provided in transaction objects for event classes that support multiperiod accounting. These date sources are mapped to the accounting attributes Multiperiod Start Date and Multiperiod End Date for the event class. They must both be blank or both be populated in the transaction objects.

Once a multiperiod journal is created in Final status, the multiperiod end date should not be modified to any day prior to the accounting date of the last multiperiod journal in the primary and secondary ledgers.

Deferring the multiperiod end date

When you're deferring the multiperiod end date, then the recognition amount has to be adjusted. As the recognition line isn't generated based on the journal line rule, the switch debit and credit option isn't applicable. The appropriate offsetting entry for the positive or negative amount is generated to offset the extra recognition.

For example, if you're extending for 3 months and have already run the multiperiod accounting for the first 2 months, you would have recognized more than the amount required to offset; hence a negative entry will be generated.

Provide the multiperiod transaction data

Multiperiod transaction data must be available in subledger transaction objects until the last multiperiod entry is accounted in Final status.

At least one line level transaction object is required for the event class to use multiperiod feature. Ensure transaction objects are populated with current data for the multiperiod transaction throughout the life cycle of multiperiod, even if the transaction is accounted.

For example, if the multiperiod start date is changed after the transaction is accounted but not all future entries have been accounted. The new multiperiod start date should be populated in the transaction object. This enables the Create Multiperiod Accounting process to calculate the prorate amount according to the modified multiperiod date range.

Process the multiperiod accounting

Multiperiod recognition entries are created based on transaction objects data and accounting rule definition at the time the Create Multiperiod Accounting process is executed.

The entered amount value for the multiperiod journal is calculated by a formula. This formula is assigned to the Entered Amount accounting attribute on the multiperiod journal line rule.
The accounted amount value for multiperiod journals is calculated by the Create Multiperiod Accounting process, prorating proportionally to the entered amount, including rounding differences.

Multiperiod accounting entries aren't created:

If any subledger level reporting currency or secondary ledger is disabled, although the multiperiod transaction may not be fully recognized yet.
If subledger level reporting currency is added after the journal is created in Final status, the multiperiod journal isn't created for the new reporting currency.
If the transaction accounting date is prior to the first open period of a reporting currency or secondary ledger, the journal isn't created for the reporting currency or secondary ledger.

Multiperiod transactions are processed by the Create Multiperiod Accounting process only once for each accounting period and transaction.

Don't modify the multiperiod start date for a transaction to a date in a prior accounting period of the last multiperiod journal in primary and secondary ledgers.
If the multiperiod start date for a transaction is modified to a date in a prior accounting period, accounting periods that were previously processed for the transaction by the Create Multiperiod Accounting process aren't processed, regardless of the period status. Any adjustment in the prorated amount due to change of start date will be accounted in the next accounting period.