Introduction
Every day, the court records a number of services, such as the submission of court decision copies, the registration of powers of attorney, the processing of e-Court accounts, the payment of case fee deposits, or requests for information in information desk of PTSP. Each of these transactions leaves a trail and is recorded in various digital applications. Staff at the case records desk note that a copy of a judgment or divorce decree has been submitted. The cashier notes that payment for that transaction has been received. We see two people, two desks, and two records, which actually represent a single, synchronized event from the PTSP desk and other personnels.
In the past, the process of checking for discrepancies meant sitting down, sometimes for hours, to compare two different applications (for example, the product desk’s record-keeping application and the cashier’s record-keeping application).
In this article, the author will discuss three aspects of optimizing the cross-verification system in the administration of justice: (1) current challenges and potential obstacles to its implementation; (2) how the cross-verification system can be developed and optimized; and (3) the objectives and expected outcomes of its implementation.
Main Discussion
1. The Needs to of Implement Cross-Checking Feature
Before proceeding, the author acknowledges that he does not have comprehensive data on the implementation of cross-verification features in other court apart from where the author works, nor is he in a position to obtain or evaluate such data thoroughly. Hence, rather than assessing implementation across Indonesian courts, this article is intended to draws on the author’s experience developing several applications that incorporate cross-checking features in author’s workplace.
Based on the author’s experience, data discrepancies are often only identified after they are brought to light by a higher court, such as the High Religious Court (PTA), or by a supervising judge during an inspection process. In other cases, such discrepancies may only come to light when one of the disputing parties raises a question to PTSP desks that triggers further verification. Although, most discrepancies may stem from minor human errors, such as typos or delays in data entry.
Rather than waiting for discrepancies to be uncovered through external oversight or subsequent investigations, cross-checks can be conducted routinely and automatically, for example at the end of each workday or at the end of each week. This approach will allow discrepancies to be identified and addressed earlier, thereby minimizing the risk that unresolved discrepancies will accumulate and lead to more serious problems down the line. For example, discrepancies are often discovered at the end of the month, when staff must reconcile records from different applications (or even handwritten paper-based logbooks) as part of the monthly reporting process.
2. How to Build Cross-Checking Feature
Cross-checking can be applied across all applications that record various stages of the same administrative process. Examples include:
- Case Tracking Information System / Sistem Informasi Penelusuran Perkara (“SIPP”) and court hearing queue applications: Data in the court hearing queue application (this “antrian sidang” application is popular in many courts although comes with many names and modification) which is integrated with the SIPP may indicate that the Defendant does not need to be summoned for the next hearing, while the hearing schedule menu in SIPP shows the opposite. The reverse can also occur: the hearing schedule indicates that the Defendant must be summoned, but the cashier desk has not yet recorded the associated cost of summons fee.
- SIPP and SIPP Supporting Application / Aplikasi Penunjang SIPP (“APS”): In courts under the jurisdiction of the Religious Courts, cross-verification between SIPP and APS can be used to identify discrepancies in related records.
- SIPP, receipt application in product desk, and cashier desk records: A copy of a court decision downloaded directly through e-Court, without the relevant parties visiting the case processing desk, may be recorded by the cashier desk but not by the case processing desk. The same situation can occur when the disputing parties download an electronic divorce decree directly. In addition, SIPP includes a field for recording the date on which a divorce certificate (akta cerai) is collected, this field should be consistent with the records on product desk and cashier desk records.
- Cashier records and power of attorney registrations in SIPP: The system can compare payments for power of attorney registrations recorded by cashiers with the corresponding registration data in SIPP. For example, the system can flag payments that have been received but for which the power of attorney registration number and date have not yet been entered into the relevant case record in SIPP.
- Legal-Aid Post / Pos Bantuan Hukum (“Posbakum”) assistance and subsequent e-Court filings. Records of individuals assisted by Posbakum in drafting lawsuit can be compared with records of those who continue their filing process to the e-Court desk to submit their case and eventually pay the required court fees. This can help identify cases where individuals who have visited the information desk for consultation and received assistance in drafting a lawsuit at the legal aid post (posbakum), but subsequently decided not to proceed with filing their case. Such findings do not automatically indicate an error, as a person may have legitimately decided not to proceed. Rather, these findings provide a basis for verification and, if necessary, follow-up by authorized staff.
Cross-checking does not always have to compare two sets of records inputted in two or more application as explained above. Another approach is to compare data in a single application against a set of administrative rules established by the court.
The author recently developed a court hearing calendar application that displays schedules in a monthly view and allows users to filter the calendar by the judge or registrar. The application validates the initial hearing date (Penetapaan Hari Sidang) set for each case based on a series of configurable rules. These rules include, for example, checks for:
- Whether a scheduled hearing falls on a weekend or a national holiday;
- Whether a judge is assigned to the correct hearing room or maybe assigned to a circuit/mobile court outside of the court building;
- Whether there is a sufficient time interval between the case registration and the first hearing. Additional rules govern specific types of cases such as how many interval days should there be in case involving defendants whose whereabouts are unknown (gaib). The application can be developed to suggest an appropriate interval based on data from the post office or historical statistics from SIPP on how long hearing summon via registered mail (surat tercatat) takes to reach a particular city or subdistrict in previous cases involving defendants at the same location with the defendant in such latest case.
- Whether the assigned substitute registrar/clerk is consistent with the applicable chairman’s decree or the registrar’s decision. The application can be developed to suggest an appropriate substitute registrar based on the applicable requirements, such as how frequently a particular substitute registrar has been assigned to a specific judge across that judge’s most recent cases.
The flexibility of this approach lies in the staff’s ability to manage these rules via a settings page, eliminating the need to involve programmers whenever administrative policies change.
The cross-checking process can be further automated so that the system reviews records each afternoon and sends a WhatsApp notification to the relevant staff if any discrepancies are found. To support this, the applications must utilize consistent or compatible data column. The use of distinct databases may still be necessary for ease of management and maintenance, for instance, to differentiate between the clerk’s office application (e.g: root.ptsp_db) and the secretariat application (e.g: root.kesekretariatan_db).
3. Objectives of Cross-Checking Implementation
The primary purpose of cross-checking is to identify discrepancies earlier and reduce the need for manual verification. The underlying principle is the recognition that no employee is immune to error: one employee may make a typo while another records information correctly, or both may have equally accurate records that reflect different stages of a process. Therefore, cross-checking should not automatically be viewed as a means of assigning blame, but rather as a mechanism to facilitate improvement in judicial administration. Any detected discrepancy should first be treated as a sign that verification is needed, rather than as definitive proof of an error.
Conclusion
Digital cross-checking provides an opportunity to make systematic data verification more efficient. First, routine checks can help identify discrepancies earlier. Second, cross-checking can be optimized in three ways: by comparing records across two or more applications, by providing a feature for users to configure rules according to the written established rule (for example by the court’s chairman, registrar, or secretary), and by ensuring that applications use consistent data structures so that records can be read and compared across different applications. Third, discrepancies that are detected should be first viewed as signals to conduct verification, not as definitive proof of error.
Untuk Mendapatkan Berita Terbaru Suara BSDK, Follow Channel WhatsApp: SUARABSDKMARI