Workflow Akuntansi

Workflow Akuntansi Laundrify OS

Dokumen ini menjadi referensi resmi alur akuntansi di aplikasi Laundrify OS untuk kebutuhan:

– operasional harian admin/owner,

– penjelasan ke calon pembeli bisnis,

– due diligence transaksi penjualan usaha,

– persiapan audit dan rencana IPO.

1) Tujuan & Prinsip

Tujuan

– Menjelaskan bagaimana transaksi operasional diterjemahkan menjadi data akuntansi.

– Menyamakan pemahaman antara tim operasional, manajemen, dan auditor.

– Menyediakan jejak kontrol untuk verifikasi laporan.

Prinsip Akuntansi yang Dipakai di Aplikasi

– Basis transaksi jasa: pendapatan muncul saat transaksi laundry dicatat.

– Pemisahan kas vs akrual: metrik kas (lunas) dan akrual (lunas + piutang) dipisah.

– Top up member: tidak langsung pendapatan, diperlakukan sebagai kewajiban sampai dipakai.

– CAPEX vs OPEX: pembelian aset dipisah dari biaya operasional; depresiasi dihitung bulanan.

> Catatan: Dokumen ini adalah dokumentasi sistem. Opini final kepatuhan standar (PSAK/IFRS) tetap ditetapkan oleh akuntan publik/auditor eksternal saat audit.


2) Entitas Data Inti

Tabel/transaksi inti yang dipakai dalam alur akuntansi:

– `transactions` → transaksi laundry (lunas/piutang).

– `expenses` → pengeluaran operasional dan CAPEX.

– `customers` → profil pelanggan + saldo member.

– `member_topup` → mutasi saldo member (+ top up, – pemakaian saldo).

– `equipment` → daftar aset/inventaris yang berasal dari CAPEX.

– `balance_sheet` → snapshot neraca bulanan (input + auto komponen tertentu).

– `prive` → penarikan pribadi owner (dipisah dari operasional).

– `employees` → master karyawan, pembayaran gaji dicatat ke `expenses` kategori gaji.


3) Alur Akuntansi Per Proses Bisnis

A. Transaksi Laundry Reguler

1. Transaksi dicatat ke `transactions` dengan status `lunas` atau `piutang`.

2. Jika member membayar pakai saldo, sistem mengurangi `customers.member_balance`.

3. Pengurangan saldo member dicatat sebagai mutasi negatif di `member_topup`.

Implikasi akuntansi:

– Pendapatan akrual: seluruh transaksi (`lunas + piutang`).

– Kas masuk: hanya transaksi `lunas`.

– Piutang usaha: transaksi `piutang`.

B. Top Up Member

1. User input top up member.

2. Saldo customer naik (`customers.member_balance` bertambah).

3. Riwayat mutasi masuk ke `member_topup` dengan nilai positif.

Implikasi akuntansi:

– Saat top up: kas bertambah, kewajiban (utang saldo member) bertambah.

– Belum diakui sebagai pendapatan sampai saldo dipakai pada transaksi jasa.

C. Pengeluaran Operasional (OPEX)

1. Pengeluaran dicatat ke `expenses` (kategori: listrik, gaji, kimia, dll).

2. Untuk pembelian kimia, stok kimia ikut ter-update sesuai kuantitas.

Implikasi akuntansi:

– Menambah beban periode berjalan (sesuai kategori).

– Mengurangi laba periode.

D. Pengeluaran Aset (CAPEX)

1. Pengeluaran kategori aset/sewa kontrak dicatat sebagai `is_capital = true`.

2. Umur manfaat dan depresiasi per bulan dihitung.

3. Aset juga tercatat ke `equipment`.

Implikasi akuntansi:

– Nilai aset masuk komponen neraca.

– Beban depresiasi dikenakan bertahap per bulan (mode akrual/reporting).

E. Payroll

1. Data karyawan disimpan di `employees`.

2. Saat bayar gaji, sistem membuat pengeluaran kategori `gaji` di `expenses`.

Implikasi akuntansi:

– Penggajian tercermin sebagai beban operasional.

F. Prive Owner

1. Penarikan pribadi dicatat ke `prive`.

2. Data prive dipisahkan dari laporan operasional.

Implikasi akuntansi:

– Digunakan untuk kontrol pengambilan dana pemilik.

– Tidak dicampur ke perhitungan performa operasional harian.


4) Mapping Ringkas ke Akun Akuntansi (Chart of Accounts Konseptual)

– Pendapatan Jasa Laundry

  – Sumber: `transactions.amount`.

– Kas/Bank

  – Sumber utama: transaksi `lunas`, top up member.

– Piutang Usaha

  – Sumber: transaksi `piutang`.

– Utang Saldo Member (Unearned Revenue / Contract Liability)

  – Sumber: agregat `customers.member_balance` member aktif.

– Beban Operasional

  – Sumber: `expenses` non-capital.

– Aset Tetap

  – Sumber: `expenses` capital + `equipment`.

– Beban Depresiasi

  – Sumber: `depreciation_per_month` untuk aset aktif.

– Prive

  – Sumber: `prive`.


5) Jurnal Referensi (Template Operasional)

5.1 Top Up Member

– Dr Kas/Bank

– Cr Utang Saldo Member

5.2 Member Memakai Saldo untuk Laundry

– Dr Utang Saldo Member

– Cr Pendapatan Jasa Laundry

5.3 Transaksi Lunas Non-Member

– Dr Kas/Bank

– Cr Pendapatan Jasa Laundry

5.4 Transaksi Piutang

– Dr Piutang Usaha

– Cr Pendapatan Jasa Laundry

5.5 Pelunasan Piutang

– Dr Kas/Bank

– Cr Piutang Usaha

5.6 Beban Operasional

– Dr Beban Operasional (sesuai kategori)

– Cr Kas/Utang

5.7 Pembelian Aset (CAPEX)

– Dr Aset Tetap

– Cr Kas/Utang

5.8 Depresiasi Bulanan

– Dr Beban Depresiasi

– Cr Akumulasi Depresiasi

5.9 Prive

– Dr Prive / Penarikan Pemilik

– Cr Kas/Bank


6) Laporan di Aplikasi & Arti Angkanya

Income

– Menampilkan pemisahan:

  – Pendapatan Akrual = Lunas + Piutang

  – Kas Masuk = Lunas

  – Piutang = Belum dibayar

PL (Laba Rugi)

– Menampilkan:

  – Laba Akrual = Pendapatan Akrual – Beban

  – Laba Kas = Kas Masuk – Beban

  – Margin dihitung terhadap basis akrual

Reports (Balance)

– Menampilkan komponen aset, piutang, utang saldo member, dan ekuitas.

– Ekuitas pada layar dihitung dari Aset – Liabilitas.

Balance Sheet (Input Bulanan)

– Snapshot neraca bulanan.

– Komponen utang saldo member ditarik otomatis dari total saldo member aktif.


#7) Kontrol Internal yang Sudah Ada

– Pemisahan top up member vs pendapatan jasa.

– Pencatatan mutasi saldo member (+/-) terpisah di ledger `member_topup`.

– Pemisahan CAPEX vs OPEX.

– Pemisahan prive dari laporan operasional.

– Label basis perhitungan di KPI utama agar tidak salah tafsir.


8) Rekonsiliasi Bulanan (Wajib)

Lakukan setiap tutup bulan:

1. Rekonsiliasi Pendapatan

   – Cocokkan total transaksi per periode (lunas + piutang) dengan laporan akrual.

2. Rekonsiliasi Kas

   – Cocokkan kas masuk sistem (`lunas`) dengan mutasi bank/kasir.

3. Rekonsiliasi Piutang

   – Daftar piutang outstanding vs daftar transaksi belum lunas.

4. Rekonsiliasi Utang Saldo Member

   – Total `customers.member_balance` vs mutasi bersih `member_topup`.

5. Rekonsiliasi Beban

   – Total `expenses` vs bukti pengeluaran.

6. Rekonsiliasi Aset & Depresiasi

   – Daftar `equipment` dan `expenses is_capital` vs schedule depresiasi.

7. Rekonsiliasi Prive

   – Total `prive` vs kebijakan penarikan pemilik.


9) Paket Dokumen untuk Due Diligence (Penjualan Usaha / IPO Readiness)

Siapkan data room minimal:

– Kebijakan akuntansi internal (dokumen ini).

– Laporan bulanan: Income, PL, Balance Sheet, Reports.

– Export ledger utama: transaksi, expenses, member_topup, customers, prive.

– Rekonsiliasi bulanan beserta bukti pendukung (bank, invoice, bukti kas).

– Daftar aset + umur manfaat + depresiasi.

– Daftar piutang outstanding & aging.

– Daftar saldo member outstanding (liability schedule).

– Daftar kontrol akses user (admin/owner) & jejak perubahan penting.


10) Gap yang Perlu Disiapkan untuk Level Audit/IPO Lebih Tinggi

Untuk kesiapan enterprise/audit besar, disarankan roadmap berikut:

– Penomoran jurnal otomatis dan immutable audit trail (append-only log).

– Chart of Accounts formal + mapping akun per transaksi.

– Closing process bulanan (lock period) dan approval workflow.

– Modul aging piutang terstruktur (0-30, 31-60, 61-90, >90 hari).

– Kebijakan revenue recognition tertulis per skema transaksi.

– Notes to financial statements (CaLK) template.

– Integrasi bukti dokumen (invoice/receipt attachment) per entry.


11) SOP Penjelasan Cepat ke Auditor / Calon Pembeli

Gunakan narasi ini saat presentasi:

1. “Kami pisahkan basis kas dan akrual agar performa operasional tidak bias.”

2. “Top up member kami perlakukan sebagai kewajiban sampai jasa diberikan.”

3. “CAPEX dipisah dari OPEX dan depresiasi dihitung bulanan.”

4. “Prive owner dipisah dari operasional untuk menjaga kualitas laba.”

5. “Setiap akhir bulan kami lakukan rekonsiliasi pendapatan, kas, piutang, saldo member, beban, aset, dan prive.”


12) Versioning Dokumen

– Nama dokumen: Workflow Akuntansi LaundryOS

– Versi: 1.0

– Tanggal: 16 Maret 2026

– Pemilik dokumen: Admin/Owner LaundryOS

– Frekuensi review: minimal 1x per kuartal atau saat ada perubahan logika transaksi