title: “General Ledger” description: “Chart of Accounts hierarkis, jurnal double-entry, posting lifecycle, buku besar per akun, trial balance, dan auto-journaling dari lintas modul di SNISHOP ERP.”

General Ledger

General Ledger adalah pusat akuntansi SNISHOP ERP. Setiap transaksi keuangan — baik dari input manual maupun otomatis dari modul POS, Manufacturing, Expense, Invoice, atau Payroll — tercatat di jurnal umum menggunakan prinsip double-entry bookkeeping. Sistem ini mengelola Chart of Accounts (COA) hierarkis 3 level dengan 5 tipe akun, memvalidasi keseimbangan debit-kredit hingga toleransi Rp 0.01, dan mendukung lifecycle jurnal dari draft hingga reversal.

Arsitektur General Ledger

Entity Relationship Diagram (ERD)

Diagram berikut menunjukkan relasi antar entitas inti dalam modul General Ledger beserta entitas pendukung dari modul keuangan lainnya. Relasi ini menggambarkan bagaimana data mengalir dari rekening kas (Account), pencatatan transaksi (FinancialRecord), chart of accounts (GLAccount), hingga ke jurnal umum (GLJournalEntry).

Penjelasan Relasi

GLJournalEntry → GLAccount: Satu jurnal memiliki banyak line items, masing-masing line item mereferensikan satu GLAccount melalui account_id. Ini adalah inti dari double-entry bookkeeping — setiap jurnal minimal memiliki 2 line items (satu debit, satu kredit).
GLAccount → GLAccount (self-referential): COA bersifat hierarkis. Field parent_account_id memungkinkan akun anak merujuk ke akun parent-nya. Contoh: “BCA Rupiah” (level 2) → parent → “Kas & Bank” (level 1) → parent → “Aset Lancar” (level 0).
FinancialRecord → Account: Setiap pencatatan transaksi keuangan berasal dari suatu rekening/kantong (Account). Untuk transfer, ada rekening tujuan (transfer_to_account_id).
FinancialRecord → GLAccount: Pada konteks bisnis, FinancialRecord dapat dipetakan ke akun COA tertentu untuk keperluan konsolidasi laporan keuangan.
GLJournalEntry ↔ FinancialRecord: Keduanya terhubung melalui reference_id dan reference_type. POS transaction misalnya, membuat FinancialRecord dengan source='pos' dan secara paralel dapat menghasilkan GLJournalEntry dengan reference_type='manual' atau melalui proses rekonsiliasi.

Chart of Accounts (COA)

5 Tipe Akun

Tipe	Saldo Normal	Kode COA	Contoh
Asset	Debit	1-xxxx	Kas, Bank, Piutang, Persediaan, Aset Tetap
Liability	Kredit	2-xxxx	Hutang Usaha, Hutang Pajak, Hutang Bank
Equity	Kredit	3-xxxx	Modal Saham, Laba Ditahan, Prive
Revenue	Kredit	4-xxxx	Penjualan, Pendapatan Jasa, Pendapatan Bunga
Expense	Debit	5-xxxx	HPP, Gaji, Sewa, Listrik, Marketing

3 Level Hierarki

Level	Fungsi	Contoh
0 — Header	Kelompok besar	Aset Lancar, Aset Tetap, Liabilitas Jangka Pendek
1 — Main Account	Akun utama	Kas & Bank, Piutang Usaha, Persediaan
2 — Sub Account	Akun detail	BCA Rupiah, Mandiri Rupiah, Kas IDR

Diagram Hierarki COA Lengkap

Berikut adalah visualisasi pohon COA yang menunjukkan 5 tipe akun beserta contoh 3 level hierarki untuk masing-masing tipe. Struktur ini digunakan SNISHOP ERP untuk mengklasifikasikan seluruh transaksi keuangan PT Selera Pedas Nusantara.

Field GLAccount — Schema Lengkap

Schema berikut diambil langsung dari definisi entitas GLAccount di sistem SNISHOP ERP.

Field	Tipe	Required	Default	Deskripsi
`id`	string (UUID)	ya	auto-generated	Primary key
`company_id`	string (UUID)	ya	—	ID perusahaan; multi-tenant isolation
`account_code`	string	ya	—	Kode akun unik (misalnya: `1000`, `2100`, `4001`). Format: digit pertama = tipe akun (1=Asset, 2=Liability, 3=Equity, 4=Revenue, 5=Expense)
`account_name`	string	ya	—	Nama akun dalam Bahasa Indonesia
`account_type`	enum	ya	—	Tipe akun: `asset`, `liability`, `equity`, `revenue`, `expense`
`category`	string	tidak	—	Kategori akun (misalnya: `Current Asset`, `Fixed Asset`, `Receivable`)
`sub_category`	string	tidak	—	Sub-kategori akun untuk klasifikasi lebih detail
`parent_account_id`	string (UUID)	tidak	—	ID akun parent untuk hierarki COA (self-referential ke `GLAccount.id`)
`normal_balance`	enum	ya	—	Saldo normal akun: `debit` atau `credit`
`is_active`	boolean	tidak	`true`	Status aktif/nonaktif. Akun nonaktif tidak bisa digunakan untuk jurnal baru
`description`	string	tidak	—	Deskripsi tambahan tentang akun
`level`	number	tidak	`0`	Level hierarki: `0` (header), `1` (main account), `2` (sub account)

RLS (Row-Level Security): Create, Read, Update, Delete — semua terbatas pada pengguna yang terautentikasi dengan akses ke company_id yang sesuai.

Jurnal Umum (GLJournalEntry)

Field Jurnal — Schema Lengkap

Schema berikut diambil langsung dari definisi entitas GLJournalEntry di sistem SNISHOP ERP.

Field	Tipe	Required	Default	Deskripsi
`id`	string (UUID)	ya	auto-generated	Primary key
`company_id`	string (UUID)	ya	—	ID perusahaan; multi-tenant isolation
`entry_date`	date (YYYY-MM-DD)	ya	—	Tanggal entri jurnal
`reference_number`	string	tidak	—	Nomor referensi eksternal (misalnya: `TRX-001`, `INV-001`, `EXP-2026-042`)
`reference_type`	enum	tidak	—	Tipe referensi sumber entri: `manual`, `invoice`, `purchase_order`, `transfer`, `expense`
`reference_id`	string (UUID)	tidak	—	ID dokumen sumber (Invoice ID, PO ID, Expense ID, dll)
`description`	string	ya	—	Deskripsi jurnal — keterangan ringkas transaksi
`line_items`	array of objects	ya	—	Baris jurnal double-entry. Setiap item: `{account_id, account_code, debit, credit, description}`
`total_debit`	number	tidak	`0`	Total akumulasi debit seluruh line items
`total_credit`	number	tidak	`0`	Total akumulasi kredit seluruh line items
`is_balanced`	boolean	tidak	`false`	Apakah `total_debit = total_credit`. Harus `true` sebelum bisa di-post
`status`	enum	tidak	`draft`	Status jurnal: `draft`, `posted`, `reversed`
`posted_date`	date	tidak	—	Tanggal saat jurnal diposting ke buku besar
`posted_by`	string (UUID)	tidak	—	ID user yang melakukan posting
`notes`	string	tidak	—	Catatan tambahan (misalnya: alasan reversal)

RLS (Row-Level Security): Create, Read, Update, Delete — semua terbatas pada pengguna yang terautentikasi dengan akses ke company_id yang sesuai.

Line Item Structure (Sub-Schema)

Setiap elemen dalam array line_items memiliki struktur sebagai berikut:

Field	Tipe	Default	Deskripsi
`account_id`	string (UUID)	—	ID `GLAccount` yang menjadi akun target. Harus merujuk ke akun yang `is_active = true`
`account_code`	string	—	Kode akun (di-copy dari `GLAccount.account_code` untuk kemudahan baca)
`debit`	number	`0`	Jumlah debit. Tidak boleh ada nilai di `debit` dan `credit` secara bersamaan
`credit`	number	`0`	Jumlah kredit. Tidak boleh ada nilai di `debit` dan `credit` secara bersamaan
`description`	string	—	Keterangan untuk baris jurnal ini

Contoh line items untuk transaksi pembayaran invoice:

[
  {
    "account_id": "uuid-of-bca-account",
    "account_code": "1101-001",
    "debit": 5000000,
    "credit": 0,
    "description": "Pembayaran invoice INV-2026-001"
  },
  {
    "account_id": "uuid-of-piutang-account",
    "account_code": "1102-001",
    "debit": 0,
    "credit": 5000000,
    "description": "Pembayaran invoice INV-2026-001"
  }
]

Validasi: Math.abs(totalDebit - totalCredit) < 0.01

Journal Entry Lifecycle

State Machine Detail — Aturan Transisi

Berikut adalah aturan lengkap untuk setiap transisi state pada jurnal. Setiap transisi memiliki pre-condition yang harus dipenuhi sebelum sistem mengizinkan perubahan status.

Dari State	Ke State	Trigger	Pre-Conditions	Efek Samping
`[*]`	`draft`	Create jurnal baru	`line_items` tidak kosong, `description` terisi	Generate `entry_number` unik, set `is_balanced` berdasarkan validasi debit/kredit
`draft`	`draft`	Edit jurnal	Status masih `draft`	Update field yang diubah, re-kalkulasi `total_debit`, `total_credit`, `is_balanced`
`draft`	`posted`	Post jurnal	`is_balanced = true`, minimal 2 line items, semua `account_id` valid dan aktif	Set `posted_date = today`, `posted_by = current_user`, kunci jurnal (tidak bisa edit)
`draft`	`deleted`	Hapus jurnal	Status masih `draft`	Soft-delete atau hard-delete tergantung konfigurasi
`posted`	`reversed`	Reverse jurnal	Status = `posted`, dibuatkan jurnal reversal baru	Jurnal asli ditandai `reversed`, jurnal reversal baru di-post otomatis

Diagram Transisi State Lengkap

Status	Deskripsi	Aksi yang Bisa Dilakukan
Draft	Jurnal baru dibuat, belum diposting	Edit, Delete, Post
Posted	Sudah diposting ke buku besar	Reverse (tidak bisa edit langsung)
Reversed	Sudah dibalik dengan jurnal koreksi	Read-only

Posting Jurnal

Validasi: total debit = total kredit (toleransi Rp 0.01)
Set posted_at = now, posted_by = current user
Update status: draft → posted
Update saldo akun di buku besar

Reverse Jurnal

Buat jurnal baru dengan debits/credits yang dibalik
Reference ke jurnal original
Mark jurnal original sebagai reversed
Post jurnal reversal

Validasi Double-Entry

Setiap jurnal yang masuk ke sistem SNISHOP ERP harus memenuhi aturan validasi double-entry bookkeeping berikut. Validasi dilakukan secara otomatis oleh sistem pada saat create dan sebelum posting.

Aturan Validasi

#	Aturan	Deskripsi	Toleransi	Kapan Dicek
1	Debit = Kredit	Total debit seluruh line items harus sama dengan total kredit	`Math.abs(totalDebit - totalCredit) < 0.01` (Rp 0.01)	Setiap kali save dan wajib saat post
2	Minimal 2 Line Items	Setiap jurnal harus memiliki minimal 2 baris (satu debit, satu kredit)	—	Saat create/post
3	Account Aktif	Semua `account_id` di line items harus merujuk ke `GLAccount` yang `is_active = true`	—	Saat create/post
4	Single-Sided Entry	Dalam satu line item, hanya boleh ada nilai di `debit` ATAU `credit`, tidak keduanya	`debit > 0 XOR credit > 0`	Setiap kali save
5	Company Isolation	`GLAccount` di line items harus memiliki `company_id` yang sama dengan `GLJournalEntry`	—	Saat create
6	Level Valid	Hanya akun level 2 (sub account) yang boleh digunakan di line items. Level 0 (header) dan level 1 (main) tidak boleh langsung dijurnalkan	`line_item.account.level === 2`	Saat post
7	Tanggal Valid	`entry_date` tidak boleh lebih dari periode fiskal yang sudah ditutup	—	Saat post
8	Idempotency	Untuk auto-journaling, `idempotency_key` mencegah duplikasi jurnal jika request di-retry	Unique constraint	Saat create (auto-journal)

Contoh Validasi Double-Entry

Benar (balanced):

Line 1: Debit Kas & Bank (BCA)     = Rp 5.000.000
Line 2: Kredit Piutang Usaha        = Rp 5.000.000
─────────────────────────────────────────────────
Total Debit  = Rp 5.000.000
Total Kredit = Rp 5.000.000
Selisih      = Rp 0 ✓ (balanced)

Salah (tidak balanced):

Line 1: Debit Kas & Bank (BCA)     = Rp 5.000.000
Line 2: Kredit Piutang Usaha        = Rp 4.500.000
─────────────────────────────────────────────────
Total Debit  = Rp 5.000.000
Total Kredit = Rp 4.500.000
Selisih      = Rp 500.000 ✗ (TIDAK balanced — sistem menolak post)

Penanganan Selisih Pembulatan (Rounding)

Dalam praktik, selisih hingga Rp 0.01 (satu sen) ditoleransi karena pembulatan desimal pada perhitungan pajak atau kurs. Jika selisih lebih dari Rp 0.01, sistem akan menolak posting dan menampilkan pesan error beserta detail selisihnya.

Sequence Diagram — Alur Jurnal Manual

Berikut adalah sequence diagram lengkap untuk proses input jurnal manual oleh akuntan melalui UI SNISHOP ERP.

Sequence Diagram — Auto-Journaling dari Modul

Berikut adalah sequence diagram yang menunjukkan bagaimana berbagai modul di SNISHOP ERP secara otomatis menghasilkan jurnal ke General Ledger tanpa input manual dari akuntan.

Buku Besar Per Akun

Buku besar menampilkan seluruh transaksi yang mempengaruhi satu akun tertentu beserta saldo berjalan.

Field Buku Besar

Field	Deskripsi
Tanggal	Tanggal transaksi
Keterangan	Deskripsi jurnal
Reference	Nomor jurnal / nomor referensi
Debit	Jumlah debit
Kredit	Jumlah kredit
Saldo	Saldo setelah transaksi

Saldo Berjalan

Saldo Awal + Total Debit - Total Kredit = Saldo Akhir

Untuk akun dengan saldo normal debit (Asset, Expense):

Debit menambah saldo
Kredit mengurangi saldo

Untuk akun dengan saldo normal kredit (Liability, Equity, Revenue):

Kredit menambah saldo
Debit mengurangi saldo

Trial Balance

Trial balance menampilkan ringkasan saldo dari seluruh akun pada periode tertentu. Total debit dan kredit harus seimbang.

Field Trial Balance

Field	Deskripsi
Account Code	Kode akun
Account Name	Nama akun
Type	Tipe akun (asset/liability/equity/revenue/expense)
Opening Balance	Saldo awal periode
Total Debit	Total debit selama periode
Total Credit	Total kredit selama periode
Closing Balance	Saldo akhir periode

Validasi

Math.abs(totalDebit - totalCredit) < 1

Jika tidak seimbang, berarti ada kesalahan pencatatan yang perlu diperbaiki sebelum membuat laporan keuangan.

Color Coding

Tipe Akun	Warna
Asset	Biru
Liability	Merah
Equity	Ungu
Revenue	Hijau
Expense	Oranye

Entity Schema — Account (Rekening/Kantong)

Entitas Account merepresentasikan rekening kas, bank, e-wallet, atau kantong dana yang digunakan dalam transaksi keuangan. Berbeda dengan GLAccount (Chart of Accounts) yang merupakan akun pembukuan, Account adalah rekening fisik/digital tempat uang benar-benar berada.

Field	Tipe	Required	Default	Deskripsi
`id`	string (UUID)	ya	auto-generated	Primary key
`user_id`	string (UUID)	ya	—	ID pengguna pemilik rekening
`company_id`	string (UUID)	tidak	—	ID perusahaan (null untuk personal)
`name`	string	ya	—	Nama rekening/kantong (e.g., `Kas`, `BCA`, `Mandiri`, `Dompet`)
`type`	enum	ya	`cash`	Jenis rekening: `cash`, `bank`, `e-wallet`, `other`
`account_number`	string	tidak	—	Nomor rekening (optional)
`bank_name`	string	tidak	—	Nama bank (untuk `type=bank`)
`initial_balance`	number	tidak	`0`	Saldo awal saat pembuatan rekening
`current_balance`	number	tidak	`0`	Saldo saat ini; di-update oleh server saat ada transaksi POS, invoice payment, expense, atau void
`currency`	string	tidak	`IDR`	Mata uang
`icon`	string	tidak	`💰`	Icon rekening untuk UI
`color`	string	tidak	`#3B82F6`	Warna untuk UI
`is_active`	boolean	tidak	`true`	Status aktif rekening
`is_default_pos`	boolean	tidak	`false`	Rekening default untuk POS Kasir
`notes`	string	tidak	—	Catatan tambahan
`mode`	enum	tidak	`personal`	Mode rekening: `personal` atau `business`

Entity Schema — FinancialRecord

Entitas FinancialRecord adalah pencatatan transaksi keuangan yang berasal dari berbagai sumber (manual, AI, POS, Manufacturing, Distribution, dll). Entitas ini melengkapi GLJournalEntry — sementara GLJournalEntry menggunakan prinsip double-entry ke COA, FinancialRecord lebih fokus pada pencatatan arus kas riil dari/to rekening (Account).

Field	Tipe	Required	Default	Deskripsi
`id`	string (UUID)	ya	auto-generated	Primary key
`user_id`	string (UUID)	ya	—	ID pengguna
`company_id`	string (UUID)	tidak	—	ID perusahaan (null untuk personal)
`account_id`	string (UUID)	tidak	—	ID rekening/kantong sumber dana (referensi ke `Account`)
`type`	enum	ya	—	Jenis transaksi: `income`, `expense`, `transfer`
`amount`	number	ya	—	Jumlah transaksi
`category`	string	tidak	—	Kategori transaksi
`description`	string	tidak	—	Deskripsi singkat
`date`	datetime	ya	—	Tanggal transaksi
`attachment_url`	string	tidak	—	URL bukti transaksi (foto struk, dll)
`source`	enum	tidak	`manual`	Sumber transaksi: `manual`, `ai_text`, `ai_scan`, `pos`, `manufacturing`, `distribution`, `recall`, `stock_opname`
`mode`	enum	tidak	`personal`	Mode pencatatan: `personal` atau `business`
`transfer_to_account_id`	string (UUID)	tidak	—	ID rekening tujuan (untuk `type=transfer`)
`transfer_fee`	number	tidak	`0`	Biaya transfer (jika ada)
`reference_id`	string (UUID)	tidak	—	ID referensi transaksi sumber (invoice, POS, expense)
`reference_type`	enum	tidak	—	Tipe referensi: `invoice_payment`, `pos_transaction`, `expense`, `manual`, `transfer`, `production_order`, `distribution_shipment`, `distribution_return`, `batch_recall`, `stock_opname`
`idempotency_key`	string	tidak	—	Kunci idempoten untuk mencegah duplikasi transaksi
`is_inventory_material`	boolean	tidak	`false`	Apakah pembelian bahan baku persediaan (anti double-counting di P&L)
`channel_fee`	number	tidak	`0`	Potongan biaya marketplace / platform fee
`cogs_amount`	number	tidak	`0`	Biaya pokok penjualan (HPP/COGS) yang dibekukan saat transaksi POS
`tax_amount`	number	tidak	`0`	Jumlah pajak (PPN keluaran untuk revenue)

Auto-Journaling dari Modul Lain

SNISHOP ERP otomatis membuat jurnal dari transaksi di modul lain:

Expense → GL

11 Expense Categories:

salary, raw_material, operational, production_cost
travel, meals, accommodation, equipment
office_supplies, training, other

Manufacturing → GL (Two-Phase)

Phase	Trigger	Jurnal
Phase 1	`completeProductionBatch`	Debit: WIP, Kredit: Persediaan
Phase 2	`verifyAndReleaseProductionBatch`	Debit: Finished Goods, Kredit: WIP

Best-effort posting: GL failure tidak membatalkan production. Jika gagal, ditandai RECONCILIATION_REQUIRED.

Invoice Payment → GL

Debit: Kas/Bank (Asset)
Kredit: Piutang Usaha (Asset)

Hanya pembayaran dengan verification_status = 'verified' yang membuat jurnal.

POS Transaction → FinancialRecord

POS transaction tidak langsung membuat GLJournalEntry, tapi membuat FinancialRecord dengan source='pos'. Laporan P&L menggabungkan keduanya.

Reference Types

Reference Type	Sumber	Deskripsi
manual	Input manual	Jurnal manual dari accountant
invoice	Invoice	Pembayaran invoice B2B
purchase_order	Purchase Order	Penerimaan barang dari supplier
transfer	Transfer	Transfer antar rekening
expense	Expense	Expense yang sudah approved

Filter & Search

Filter	Opsi
Date Range	Hari ini, Minggu ini, Bulan ini, Kuartal ini, Tahun ini, Custom
Account	Pilih akun tertentu atau semua
Status	Draft, Posted, Reversed
Reference Type	Manual, Invoice, PO, Transfer, Expense
Entry Number	Search by nomor jurnal
Description	Search by kata kunci

Export

Format	Use Case
PDF	Arsip, audit, presentasi
Excel	Analisis lebih lanjut, manipulasi data
CSV	Integrasi dengan sistem lain

Tips Penggunaan

Review trial balance secara berkala untuk memastikan pencatatan sudah seimbang
Jangan menunda posting jurnal terlalu lama agar saldo di buku besar selalu update
Gunakan deskripsi jurnal yang jelas supaya mudah ditelusuri saat audit
Manfaatkan filter untuk melihat transaksi pada periode atau akun tertentu
Untuk koreksi, gunakan reverse (jangan edit jurnal yang sudah posted)
Export trial balance bulanan untuk arsip dan audit

​title: “General Ledger” description: “Chart of Accounts hierarkis, jurnal double-entry, posting lifecycle, buku besar per akun, trial balance, dan auto-journaling dari lintas modul di SNISHOP ERP.”

​General Ledger

​Arsitektur General Ledger

​Entity Relationship Diagram (ERD)

​Penjelasan Relasi

​Chart of Accounts (COA)

​5 Tipe Akun

​3 Level Hierarki

​Diagram Hierarki COA Lengkap

​Field GLAccount — Schema Lengkap

​Jurnal Umum (GLJournalEntry)

​Field Jurnal — Schema Lengkap

​Line Item Structure (Sub-Schema)

​Journal Entry Lifecycle

​State Machine Detail — Aturan Transisi

​Diagram Transisi State Lengkap

​Posting Jurnal

​Reverse Jurnal

​Validasi Double-Entry

​Aturan Validasi

​Contoh Validasi Double-Entry

​Penanganan Selisih Pembulatan (Rounding)

​Sequence Diagram — Alur Jurnal Manual

​Sequence Diagram — Auto-Journaling dari Modul

​Buku Besar Per Akun

​Field Buku Besar

​Saldo Berjalan

​Trial Balance

​Field Trial Balance

​Validasi

​Color Coding

​Entity Schema — Account (Rekening/Kantong)

​Entity Schema — FinancialRecord

​Auto-Journaling dari Modul Lain

​Expense → GL

​Manufacturing → GL (Two-Phase)

​Invoice Payment → GL

​POS Transaction → FinancialRecord

​Reference Types

​Filter & Search

​Export

​Tips Penggunaan