Tutorial Membuat Laporan Keuangan Otomatis Standar PSAK untuk Klinik & Rumah Sakit
T
Kembali ke Blog

Tutorial Membuat Laporan Keuangan Otomatis Standar PSAK untuk Klinik & Rumah Sakit

Tutorial
Tim Pilar Inovasi 06 Nov 2026 6 min baca 1,123 kata 3
Laporan telat dan selisih terus? Pelajari cara membangun laporan keuangan otomatis standar PSAK: COA, double-entry, posting jurnal SIMRS/POS, hingga neraca dan CALK siap audit.

Tutup buku bulanan di banyak klinik dan rumah sakit masih berakhir di Excel: tiga hari rekonsiliasi, selisih kas Rp2–5 juta, dan laporan baru sampai ke direksi tanggal 25. Padahal PSAK menuntut penyajian konsisten—PSAK 1 untuk struktur laporan, PSAK 72 untuk pengakuan pendapatan, PSAK 71 untuk penurunan nilai piutang BPJS, PSAK 73 untuk sewa. Akar masalahnya bukan standar, melainkan data transaksi operasional dari SIMRS, POS farmasi, dan ERP tidak pernah dijahit ke jurnal akuntansi. Artikel ini membedah cara membangun laporan keuangan otomatis yang patuh PSAK, dari chart of accounts sampai CALK tercetak PDF. Stack contoh: PostgreSQL 16, Python 3.12, SQLAlchemy 2.0, dan openpyxl 3.1.

Fondasi: Chart of Accounts dan Double-Entry yang Selaras PSAK

COA bukan daftar akun asal jadi. Mulai dari struktur PSAK 1: aset lancar, aset tidak lancar, liabilitas jangka pendek, liabilitas jangka panjang, ekuitas, pendapatan, dan beban. Gunakan kode 5 digit yang stabil, misalnya 1-1000 Kas, 1-1100 Piutang Pasien, 1-1110 Piutang BPJS, 1-1200 Persediaan Obat, 1-2000 Aset Tetap, 1-2010 Akumulasi Penyusutan, 2-1000 Utang Supplier, 3-1000 Modal, 4-1000 Pendapatan Rawat Jalan, 4-1100 Pendapatan Rawat Inap, dan 5-1000 Beban Gaji. Simpan metadata per akun: normal balance (debit/kredit), tipe laporan (neraca atau laba rugi), dan grup CALK.

Ledger wajib double-entry dengan constraint di level database. Buat tabel journal_entries (id, entry_date, period_id, ref, source, status, idempotency_key unik) dan journal_lines (entry_id, account_code, debit, credit, cost_center). Nilai uang pakai NUMERIC(19,4), jangan FLOAT. Pasang trigger yang menolak entry bila SUM(debit) != SUM(credit) atau nol. Dengan begitu, kesalahan posting terdeteksi sebelum menyentuh laporan.

Pemetaan PSAK harus eksplisit di COA. Pendapatan diakui saat jasa diberikan (PSAK 72), bukan saat kas diterima—penting untuk klaim BPJS yang cair 30–60 hari. Piutang BPJS dikenakan expected credit loss (PSAK 71) berbasis aging dan forward-looking. Persediaan obat pakai FIFO (PSAK 14), aset tetap disusutkan garis lurus (PSAK 16), dan sewa ruang klinik diakui sebagai right-of-use asset (PSAK 73). Setiap akun diberi tag PSAK agar CALK bisa digenerate otomatis.

Terakhir, buat tabel accounting_periods berstatus open atau closed. Trigger menolak insert/update jurnal pada periode closed, kecuali via jurnal koreksi yang disetujui. Ini yang membuat audit trail rapi dan mencegah staf “menambal” angka bulan lalu.

Otomasi Posting Jurnal dari SIMRS, POS, dan ERP

Prinsipnya event-driven: setiap billing, pembayaran, pembelian, payroll, dan depresiasi mengirim event ke antrean (PostgreSQL LISTEN/NOTIFY atau Redis Stream). Worker membaca event dan memetakan ke template jurnal pada tabel posting_rules(source, event_type, debit_account, credit_account, amount_field). Tidak ada jurnal yang diketik manual untuk transaksi rutin.

Contoh nyata: invoice rawat jalan Rp750.000 dengan klaim BPJS 70% menghasilkan Debit Piutang BPJS Rp525.000, Debit Piutang Pasien Rp225.000, Kredit Pendapatan Rawat Jalan Rp750.000. Di POS farmasi, penjualan Rp120.000 menghasilkan Debit Kas Rp120.000, Kredit Pendapatan Rp120.000, sekaligus Debit HPP Rp85.000 dan Kredit Persediaan Obat Rp85.000. Untuk volume 1.200 transaksi per hari (36.000 per bulan), posting manual jelas tidak realistis.

from decimal import Decimal
from sqlalchemy import text

def post_journal(conn, entry_id, lines):
    total_d = sum(Decimal(str(l['debit'])) for l in lines)
    total_k = sum(Decimal(str(l['credit'])) for l in lines)
    if total_d != total_k or total_d == 0:
        raise ValueError(f'Jurnal tidak balance: D={total_d} K={total_k}')
    for l in lines:
        conn.execute(text('INSERT INTO journal_lines(entry_id, account_code, debit, credit, cost_center) '
                          'VALUES (:eid, :acc, :d, :k, :cc)'),
                     dict(eid=entry_id, acc=l['account'], d=l['debit'], k=l['credit'], cc=l.get('cc')))
    return entry_id

Tambahkan idempotency_key unik per event agar retry tidak menggandakan jurnal. Jalankan job rekonsiliasi harian: total setoran kasir vs mutasi bank, total klaim BPJS vs piutang terbentuk. Selisih masuk ke exception queue dan harus ditutup sebelum periode dikunci. Target SLA posting di bawah 5 menit—dari sebelumnya 3 hari kerja.

Generate Neraca, Laba Rugi, Arus Kas, dan CALK

Mulai dari view trial balance: agregasi saldo awal plus mutasi debit-kredit per akun per periode. Dari view ini, neraca dihitung dari saldo kumulatif akun aset, liabilitas, dan ekuitas; laba rugi dari mutasi akun pendapatan dan beban; arus kas dengan metode tidak langsung, yaitu laba bersih ditambah penyusutan dan penyesuaian perubahan modal kerja. Contoh: laba bersih Rp180 juta, penyusutan Rp45 juta, piutang BPJS naik Rp60 juta, maka arus kas operasi Rp165 juta.

Rendering laporan pakai Jinja2 3.1 untuk template dan WeasyPrint 62 untuk PDF, sedangkan openpyxl 3.1.3 menghasilkan Excel dengan sel pemeriksaan. Sebelum publish, jalankan tiga assertion otomatis: total aset = liabilitas + ekuitas; laba rugi periode = perubahan ekuitas; arus kas = perubahan saldo kas dan bank. Jika salah satu gagal, laporan berstatus draft dan alert dikirim ke Slack atau WhatsApp.

CALK jangan diketik ulang tiap bulan. Simpan kebijakan akuntansi sebagai template, lalu inject angka dari query: aging piutang BPJS per bucket (0–30, 31–60, 61–90, >90 hari), cadangan ECL, mutasi aset tetap, dan rincian pendapatan per unit layanan. Untuk audit, sediakan lampiran berisi daftar jurnal (general ledger) yang bisa difilter per akun dan per sumber transaksi.

Praktik yang terbukti: satu entitas klinik dengan 3 cabang membutuhkan waktu implementasi 6–10 minggu; multi-entitas dengan konsolidasi 3–4 bulan. Kuncinya bukan tools mahal, tapi disiplin data master dan aturan posting yang tertulis.

Best Practices

  1. Jadikan ledger append-only: koreksi lewat jurnal balik, bukan UPDATE atau DELETE.
  2. Kunci periode akuntansi dan terapkan approval berjenjang sebelum reopening.
  3. Simpan idempotency_key di setiap posting untuk mencegah jurnal ganda.
  4. Rekonsiliasi otomatis harian untuk kasir, bank, dan klaim BPJS; selisih wajib masuk exception queue.
  5. Uji dengan data 12 bulan dan review akuntan sebelum go-live, bukan setelah laporan dipublikasikan.

FAQ

Apakah cukup pakai Excel dan pivot table?

Untuk volume di bawah 50 transaksi per hari masih mungkin, tetapi tidak audit-ready. Excel tidak punya constraint double-entry, rawan overwrite, dan sulit melacak siapa mengubah angka. Gunakan database transaksional sejak awal.

Bagaimana menghitung ECL piutang BPJS sesuai PSAK 71?

Gunakan aging bucket, tentukan probability of default per bucket berdasarkan histori pencairan, lalu kalikan dengan outstanding. Review kuartalan dan sesuaikan dengan kondisi forward-looking seperti perubahan regulasi tarif atau keterlambatan pencairan.

Stack minimal yang direkomendasikan apa?

PostgreSQL 16 sebagai ledger, Python 3.12 + FastAPI 0.111 untuk API dan worker, SQLAlchemy 2.0 untuk ORM, serta openpyxl dan WeasyPrint untuk output. Jika tim Anda PHP, Laravel 11 + MySQL 8 juga memadai asalkan constraint dan trigger tetap dipasang.

Berapa lama sampai laporan bisa terbit otomatis?

Untuk satu entitas dengan SIMRS/POS yang sudah punya API, 6–10 minggu cukup: 2 minggu desain COA dan aturan posting, 3 minggu integrasi, 2 minggu UAT, sisanya parallel run dengan laporan manual.

Membangun laporan keuangan otomatis standar PSAK bukan proyek akuntansi semata, melainkan integrasi data operasional, aturan akuntansi, dan kontrol internal. Jika klinik atau rumah sakit Anda masih menutup buku dengan Excel dan rekonsiliasi manual, mulai dari COA, double-entry constraint, dan satu alur posting otomatis lebih dulu. Butuh pendampingan desain arsitektur, integrasi SIMRS/POS ke ledger, atau review kepatuhan PSAK 71/72/73? Konsultasikan kebutuhan Anda dengan tim Nugroho Setiawan untuk mendapatkan peta jalan yang realistis dan terukur.

Solusi terkait dari PT Pilar Inovasi Informatika (produk IT Pilar Inovasi): PilarPOS SIMRS Integrator Bridging BPJS & SatuSehat. Butuh konsultasi gratis?

Terakhir diperbarui 06 Nov 2026

Komentar

Komentar ditinjau sebelum tampil.

Belum ada komentar. Jadilah yang pertama!