Monitoring of the statute of limitations

in the Indecs system

7

Case study

Many of the early users of Indecs were people who handled small volumes of cases. As the number of users grew, the program was able to handle larger and larger volumes of cases. One of our larger partners presented a problem. They said that the volume of cases made it impossible for them to keep track of the limitation periods, and as a result many cases were being lost in court. They wanted to find a solution to avoid having to keep track of them in Excel sheets and on paper.

Since the limitation period is a factual situation that applies according to rules that are formulated and precisely defined in the law, it was obvious that it could be transposed into an automatic or semi-automatic process. Hence, the procedure for monitoring the limitation period was born.

The partner’s main requirement regarding the process was that the system should calculate and track the limitation periods for various claims and transactions falling under the different Civil Codes (both the old and the new ones) without external intervention. In addition, they required various alerting and warning functionalities to be implemented alongside these.

Based on the legislation, a procedure has been developed, whereby the warning and alert parts can be parameterised and converted into a corporate design and internal rules. To the greatest satisfaction of the partners, they have thus been given the possibility of a limitation period monitoring procedure immediately accessible from the interface, which helps them enormously in the management of their transactions.

7

The way the procedure works is basically that it starts by investigating debts on the basis of different products. First, it detects what kind of debt is involved and thus which limitation period applies (telecom 1 year, home loan 5 years).

Subsequently, it is necessary to consider whether the original contract falls under the old or the new Civil Code. Based on this, the process of examining interrupting events begins. If any interrupting event is found, it is recorded in the transaction history, and the “expected limitation date” is extended by the limitation period relative to the date of the interrupting event. This continues until interrupting events that suspend the limitation period are no longer available.



As the limitation period approaches, the program sends various alerts according to the user’s preferences. The first alert, a yellow warning, is sent when there are 90 days remaining, indicating that the limitation period is about to expire. This is also marked as a task for the case owner. After that, at 60 days, an orange warning is sent, notifying the case owner. At 30 days, a red warning is triggered, and another alert is sent to the case owner. During these alerts, colleagues must act in accordance with internal policies. The program has no control over this. If we want to implement this process in a workflow, mandatory actions can be enforced for the steps, which the case handler cannot bypass. However, this is not part of the basic functionality.

The process can be adapted at various points to the profiles and internal regulations using various parameters. The basic functions are the ones that cannot be changed, among others due to legal regulations.