Intercompany Reconciliation Close Improvements

vincezk

We have received a lot of feedback on the reconciliation close process. We know the current reconciliation close process has the following flaws, which make it difficult to use.

The current period is by default open. In most cases, the closing activities for the previous period are done at the beginning of the current period. For example, now is September, but you are doing the closing for August. Thus, even though the working period is closed, one can still run matching in the current period, which affects the data in the previous periods.
The lock is at the leading unit level. When a pair is closed, the involved two units are both locked. And all other pairs that involve one of the 2 units are all blocked for matching.
The Reconciliation Close statements of previous periods get changed due to the matching run in the follow-up periods. The historic closed statements should keep unchanged.
The current reconciliation close has no control over the ICMR elimination. No matter closed or not, elimination always reads the latest data from ICADOCM.

We are happy to announce that all above flaws are resolved in the coming releases CE2502(maybe later in PCE2025).

Period Initially Closed

By default, periods are initially open, and you need to manually close them at the period end. This setup is convenient if you don't want to block matching until you close the pairs in the current period. However, in most cases, you work for the previous period in the new period. You expect open for the previous period and close for the current period. You can achieve this by checking the "Period Initially Closed" for the reconciliation case that is closed-activated(ICAARC).

Now, when you open the app Manage Reconciliation Close and check the recon case in the new period, you will see the "Reconciliation Close Status" column shows "Initially Closed" and you need to click the button "Open Period" to open all the pairs in the period. If you don't do that, you can still run matching jobs successfully in the period 2024010. However, the matching job only rolls in the new items without generating any assignments. Neither can you manually assign or unassign in the app Manage Assignments.

Lock on Pair Level

Before CE2502, when a pair is closed, all other pairs that have either the leading or the partner unit will be locked for matching. For example, during a matching run, units A, B, and C are involved. If pair A->B is closed, then B->A, A->C, C->A, C->B, and B->C are all locked against matching.

In CE2502, when a pair is closed, it only locks the pair; all other pairs are not affected. For example, if pair A->B is closed, then B->A, A->C, C->A, C->B, and B->C are still allowed to match. However, locked against matching doesn't block the data roll-in. New data still gets roll-in to ICADOCM with status "01 Roll-In".

If you run a matching job with some pairs closed and some pairs open, then you will get an application log like below. Bearing in mind that items belong to the locked pairs are not assigned even if they hit certain matching rules.

Snapshot Reconciliation Statement

The reconciliation close statements of previous periods get changed by matching runs in the follow-up periods due to the following reasons:

Journal entries could be posted to the previous posting periods. Thus, the entries are lately rolled in after their posting periods were closed.
Each matching run could un-assign and re-assign assignments that are tagged with the temporary reason codes. Which means reason codes could be changed for certain items, thus affecting the reconciliation statements.

The solution is to snapshot the reconciliation statements when the close action takes place. That is, when the user clicks the button "Close" for certain pairs, the calculated reconciliation statements will persist. The app Manage Reconciliation Close is enhanced to support snapshots.

In the first list view, you can Schedule Reconciliation Close Jobs. Of course, you can still select the pairs and then click the button "Close". However, if the number of pairs exceeds 50, then it will ask you to schedule a job instead. This is because each pair generates and persists a recon statement snapshot, which costs time. If you close more than 50 snapshots at a time in the front-end, it may cause the session timeout.

And you will see 2 amount columns: Difference at Latest Cutoff and Difference at Closing. Since after a pair is closed, new items can still be rolled in during a matching run, thus the amounts can still get changed. The first amount column stands for the latest cutoff amounts (each matching run generates a cutoff timestamp for a leading unit), while the second column stands for the amounts at last closing for the pair. If the 2 amounts are different, then it stands for new data roll-in after last closing, and thus a re-open activity should be considered. If you check the pair C1001 to C1000, you can find the "Reopen Recommended" is set to "Yes".

If you check the details of each pair's reconciliation statement, you can find more information. You can see each side 2 amounts, which are Closing Amount and Latest Amount, with the corresponding cutoff timestamps. Thus, the difference is calculated by adding the amounts from the two sides. You can find in the above picture that the partner's latest amount "-54,509.00EUR" is blue highlighted. This is because after the last closing cutoff, there were new items rolled in, thus changing the summarized amount. You can consider reopening the pair to count in the changes. Or you just leave it as is, then the affective reconciliation closing statement is version 1, as shown in the dropdown list at the upper right corner.

Imagine you run matching or upload to roll-in new items for a closed pair. Then, in the Current Reconciliation page, you will see the affections on the Latest Amounts, Difference at Latest Cutoff, and Unknown Reason category in the Reason Code Breakdown section. However, it doesn't affect the existing reason code breakdown amounts, nor the closing amounts and differences. And you can switch to the historic closing statement snapshots.

Reconciliation Close Control over Elimination

Before CE2502, the reconciliation close had no control over the ICMR elimination. No matter closed or not, the ICMR elimination just reads what is in ICADOCM up to now. The only impact is that, once closed, data in ICADOCM is frozen. We found our customers somehow accept this, as they don't want too much intertwined between reconciliation close and elimination. They want elimination run without considering too much on reconciliation.

However, having reconciliation close control over elimination will provide the following benefits:

Clear process control makes sure the data consistency and backtracking.
The reconciliation statements go through approval and provide substantiation of the elimination differences.
Elimination status can be monitored in the app Manage Reconciliation Close, which allows to run elimination for dedicate pairs to save time.

In CE2502, we have made some changes that may not be well reflected on the UI. But I will try to give some elaboration.

Before closing the pairs, you can still run the elimination task (ID 2042). It will generate elimination differences with whatever in ICADOCM. So to say the elimination difference is not substantiated, but you can still get the preliminary elimination results.

Once you closed a pair of 2 consolidation units, there will be a cutoff timestamp recorded on each unit, and the elimination status will be set to "1 Outdated", which indicates the existing elimination result (if it has) may be outdated; a re-run of the elimination for this pair is needed. This time, the elimination run will take the 2 cutoff timestamps to filter in the data from ICADOCM. That is, only the matching items that are before the cutoff timestamp of each unit will be taken into elimination difference calculation.

Since after the pair gets closed, new assignment or un-assignment activity is blocked, therefore, the difference breakdown by reason code is frozen. Although the amounts in the "Unknown Reason" category may still get changed, due to the cutoff timestamp filtering, these changes will not be conveyed into the elimination.

Once the elimination run is finished, the status of the pair is set to "4 Completed". Then, for later elimination runs, this pair will be excluded unless you re-open the pair for any changes.

Now, you can check the elimination difference in the app Group Data Analysis. You will see almost the same differences breakdown by reason codes on the subitem "915", which stands for the transactional difference. And "980" stands for the currency conversion difference; "981" stands for the other difference. It substantiates the elimination differences and makes the data backtracking possible.

Conclusion

We have received a lot of feedback on ICMR. The requirements on reconciliation close are most prominent. We hope the above improvements can clear some obstacles in using the closing features. We will keep listening to your voice from all the channels. We'd appreciate it if you could give more valuable feedback. Together, we can make the product better.