SIREKA 2.0 started with a simple observation: the original SIREKA system worked, but it treated all reporting periods the same. Monthly reports, quarterly reports, semester reports, and yearly reports all shared one generic upload schedule. That worked when the system was small, but as BPKAD Kabupaten Tanah Laut's reporting requirements grew more complex, the cracks started showing.
This post walks through how we redesigned the system — from the scheduling engine to the document matrix to the monitoring workspace — and what I learned about building configurable government software.
The original problem
SIREKA 1.0 was a digital platform for financial reconciliation and reporting. SKPD and BLUD units could upload documents, and BPKAD administrators could review them. The core workflow was functional.
But the system had limitations that became harder to ignore:
One generic upload schedule. In practice, BPKAD manages reports across monthly, quarterly, semester, and yearly cycles. Each cycle has different start dates, deadlines, and document requirements. The old system couldn't represent this complexity — it had one upload window for everything.
No document governance. Document types weren't grouped by period or organization applicability. SKPD and BLUD may need different documents for the same reporting period, but the system didn't distinguish between them. Every user saw every document type, regardless of whether it applied to them.
Manual admin monitoring. When an administrator wanted to check which SKPD had uploaded their monthly reports, they had to check each one individually. There was no dashboard, no summary view, no way to see compliance at a glance.
No user guidance. SKPD and BLUD users had no clear view of which reporting period was active, what deadline applied, which documents were required, or which had already been uploaded. They relied on manual follow-up from BPKAD through WhatsApp, email, or phone calls.
These weren't just UX problems. They were structural problems that affected how efficiently BPKAD could manage financial reporting across the entire district.
Designing the scheduling engine
The first major change was introducing period-specific upload scheduling. Instead of one generic schedule, BPKAD administrators can now create separate schedules for each reporting period type.
Each schedule has its own configuration:
- Schedule name — e.g., "Laporan Keuangan Bulanan Juni 2025"
- Reporting year — which fiscal year the schedule applies to
- Period type — monthly, quarterly, semester, or yearly
- Start date — when users can begin uploading
- End date — the upload deadline
- Active status — whether the schedule is currently open
This sounds simple, but the implications are significant. BPKAD can now have a monthly schedule open for June while simultaneously having a quarterly schedule open for Q2. Each schedule controls which documents are required and when they're due.
The scheduling engine stores each schedule independently. Administrators can create, edit, activate, deactivate, and delete schedules through a management interface. They can filter schedules by period type to quickly find what they need.
The deadline countdown
For SKPD and BLUD users, the most visible change was the deadline countdown. When a schedule is active, the home screen shows:
- The active reporting period (e.g., "Monthly — June 2025")
- The upload deadline date
- A real-time countdown showing remaining days, hours, minutes, and seconds
This small feature had a surprisingly large impact. Instead of relying on BPKAD to send reminders, users could see for themselves how much time remained. It created a sense of urgency without requiring manual follow-up.
The system also shows upcoming schedules — future upload periods that haven't started yet. This lets users prepare documents before the upload window opens.
The document matrix
The second major change was introducing a document matrix — a system that defines which documents apply to which periods and which organizations.
Each document type in SIREKA 2.0 has three key properties:
Period applicability. A document can be required for monthly reports, quarterly reports, semester reports, yearly reports, or any combination. For example, "Laporan Realisasi Belanja" might be required for all periods, while "DPA SKPD" is only required yearly.
Organization applicability. A document can apply to SKPD only, BLUD only, or both. This is important because SKPD and BLUD have different reporting requirements — SKPD submit expenditure reports (SPJ Belanja), while BLUD submit operational reports (Laporan Operasional BLUD).
Document category. Documents are grouped into categories like Planning, Expenditure, and Revenue. This helps users and administrators navigate document requirements more easily.
The document matrix is dynamic. When a user opens the upload interface for a specific reporting period, the system generates the list of required documents based on:
- The user's organization type (SKPD or BLUD)
- The active reporting period
- The document applicability rules
- The document category filters
This means a SKPD user uploading a monthly report sees a different document list than a BLUD user uploading a quarterly report — even though they're using the same system.
How the matrix was designed
The document matrix wasn't designed in isolation. It was designed by observing how BPKAD administrators actually manage document requirements.
Before SIREKA 2.0, document requirements were communicated through official letters, WhatsApp messages, and verbal instructions. Each reporting period might have slightly different requirements, and administrators had to manually check whether each organization had submitted the right documents.
The matrix formalizes this into a configurable system. Administrators can define document types, set their period and applicability rules, and the system handles the rest. When requirements change — say, a new document is required for quarterly reports — the administrator updates the matrix, and all users see the change immediately.
The monitoring workspace
The third major change was the admin monitoring workspace. Before SIREKA 2.0, monitoring was manual — administrators had to check each SKPD and BLUD individually to see their reporting status.
The new workspace provides:
Organization sidebar. A side panel lists all SKPD and BLUD units. Administrators can search for a specific organization or browse the list. Selecting an organization loads its reporting status in the main workspace.
Summary view. For each organization, the system shows a summary of reporting progress across all periods. Administrators can see at a glance which periods have complete submissions, which are partial, and which are missing entirely.
Period-specific detail view. Administrators can drill into a specific period — say, monthly reports for March 2025 — and see exactly which documents have been uploaded and which are still missing.
Progress indicators. Visual progress bars show completion status for each period. Green means complete, yellow means partial, red means missing or severely incomplete.
Multiple document selection. Administrators can select multiple submitted documents and download them together. This is especially useful for periodic review, internal archiving, and audit preparation.
The batch download workflow
One of the most requested features was batch download. Before SIREKA 2.0, downloading documents was a one-by-one process — an administrator would open a document, download it, go back, find the next one, and repeat.
The new system allows administrators to select multiple documents across different organizations and periods, then download them all at once. The selected documents are highlighted and counted, making it clear how many files are being prepared.
This feature was designed around real workflow patterns. BPKAD administrators often need to collect documents for audit preparation, internal review, or consolidated reporting. Batch download turns a tedious process into a quick one.
The user upload experience
For SKPD and BLUD users, the upload experience was redesigned to be more guided and informative.
Checklist-based status. Required documents are displayed with visual indicators: a checkmark for uploaded documents, an X for missing documents, and a special indicator for documents ready to upload. Users no longer need to guess whether a required report has been submitted.
Manual upload. Each document has its own upload area — a card-based interface where users can upload, replace, or delete individual files. This is useful for submitting a specific report or replacing a single file.
Bulk upload. For users who need to submit multiple documents at once, the system supports bulk upload. Files are matched to document types using a naming convention: [Document Number]-[Document Name]. The system includes a naming guide modal that explains the format and provides examples.
Category filtering. Users can filter documents by category (Planning, Expenditure, Revenue) to focus on the relevant section instead of seeing all documents at once.
What I learned
Building SIREKA 2.0 taught me several things about configurable government software:
Configuration beats customization. Instead of building different versions of the system for different reporting scenarios, we built one system with configurable rules. The document matrix, scheduling engine, and applicability rules are all data-driven — administrators can change requirements without touching code.
Visual status reduces communication overhead. The checklist indicators, deadline countdown, and progress bars dramatically reduced the need for manual follow-up. When users can see their own status, they don't need to ask BPKAD for updates.
Monitoring is a feature, not a view. The monitoring workspace isn't just a dashboard — it's a complete workflow tool. Administrators can browse organizations, drill into specific periods, select documents, and download them in bulk. The value is in how these capabilities work together.
Period-based thinking changes everything. Once we introduced period-specific scheduling, it affected every part of the system — document requirements, upload flows, monitoring views, and even the database structure. The period became the organizing principle for the entire platform.
SIREKA 2.0 transformed a functional but limited document upload system into a configurable reporting management platform. The upgrade didn't add flashy features — it added structure, visibility, and control to a process that previously relied on manual coordination.
That's what good government software does: it makes the existing work clearer, more traceable, and easier to manage.