Bahasa Indonesia

Three-Statement Modeling yang Tahan Pengawasan

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Anda mewarisi file itu di hari ketiga. Ukurannya 80MB. Enam belas tab. Tiga warna kuning berbeda yang tidak bisa dijelaskan siapa pun di tim. Ada angka 1,07 yang dikodekan keras terkubur di tengah SUMIFS pada tab pendapatan, dan ketika Anda bertanya kepada analis senior apa itu, dia berkata, "Saya pikir Mark memasukkannya untuk deal China tahun 2023." Mark sudah pergi sejak 2024.

Anda mengubah pertumbuhan pendapatan dari 18% menjadi 19% untuk menguji skenario. Laba bersih menjadi negatif di tahun ke-2. Laporan arus kas menunjukkan kas negatif $4 juta dan model mengalami error. Neraca meleset sebesar $873.412.

Itulah yang disebut sebagian besar "3-statement model" di perusahaan operasional. Dan bagian terburuknya bukan bahwa mereka tidak rapi. Yang terburuk adalah bahwa CFO membuat keputusan berdasarkan model-model itu. Model yang rusak akibat satu pertanyaan VP lebih buruk dari tidak ada model sama sekali, karena ia memberikan kepercayaan palsu kepada pimpinan dan Anda yang disalahkan saat kenyataan menyimpang dari deck.

Inilah panduan untuk membangun, atau membangun ulang, three-statement model yang bertahan. Struktur mengalahkan kecanggihan. Model sederhana yang selalu seimbang mengalahkan model cerdas yang rusak dengan satu perubahan asumsi.

Aturan struktural yang membuat model dapat diaudit

Sebelum Anda menulis satu formula pun, tetapkan aturan file. Ini bukan preferensi estetika. Ini adalah perbedaan antara model yang berkembang dan yang menjadi tidak dapat disentuh dalam sembilan bulan.

Satu tab per pendorong. Pendapatan di tab tersendiri. Jumlah karyawan di tab tersendiri. Opex, capex, utang, modal kerja, pajak, masing-masing mendapat lembar tersendiri. Tiga pernyataan (IS, BS, CF) adalah tab output. Mereka menautkan masuk. Mereka tidak pernah menghitung.

Jika Anda mendapati diri membangun asumsi pendapatan di dalam tab laporan laba rugi, berhenti. Anda membuat tab di mana diri Anda di masa depan harus menggulir P&L untuk menemukan tingkat pertumbuhan 3%. Begitulah warisan 80MB lahir.

Satu arah aliran. Kiri ke kanan, atas ke bawah, selalu. Tab pendorong mengisi tab pernyataan. Tab pernyataan mengisi dashboard. Tidak ada yang mereferensikan ke atas. Jika tab CF Anda menarik dari dashboard, Anda telah menciptakan ketergantungan melingkar yang akan menghantui Anda.

Aturan yang jelas: buka file, lihat urutan tab. Jika Anda membaca tab dari kiri ke kanan, Anda seharusnya melihat Input, Pendorong, Pernyataan, Dashboard, Pemeriksaan. Jangan pernah mundur. Jangan pernah melompat.

Kode warna secara konsisten.

  • Biru untuk input yang dikodekan keras (satu-satunya sel yang boleh diisi angka oleh siapa pun)
  • Hitam untuk formula di dalam tab yang sama
  • Hijau untuk tautan lintas tab

Tidak ada pengecualian, tidak ada "akan saya perbaiki nanti." Hari Anda membiarkan formula hitam mereferensikan tab lain adalah hari Anda kehilangan kemampuan untuk mengaudit. Enam bulan kemudian, Anda tidak akan ingat angka hitam mana yang sebenarnya adalah tautan, dan Anda akan menghabiskan hari Sabtu menelusuri preseden.

Satu baris, satu tujuan. Baris pendapatan menghitung pendapatan. Baris tingkat pertumbuhan menghitung tingkat pertumbuhan. Jangan dicampur. Godaan untuk menulis =B14*(1+0.18) di dalam baris pendapatan itu nyata karena menghemat satu baris. Tapi itu juga menyembunyikan asumsi dari analis berikutnya, yang akan menghabiskan satu jam mencarinya.

Empat aturan ini (satu pendorong per tab, aliran satu arah, tiga warna, satu baris per tujuan) menyelesaikan sekitar 70% masalah dalam model yang diwarisi. Membosankan. Tapi berhasil.

Pemeriksaan integritas: tiga formula, satu tab, tidak bisa ditawar

Three-statement model terintegrasi ketika laba bersih di IS merekonsiliasi dengan perubahan laba ditahan di BS, ketika kas akhir di CF sama dengan kas di BS, dan ketika aset sama dengan liabilitas ditambah ekuitas hingga sen terakhir. Jika salah satu dari itu rusak, model salah, dan setiap keputusan yang dibuat berdasarkan itu patut dicurigai.

Bangun tab yang disebut _Checks (garis bawah membuatnya mengapung ke depan dalam urutan alfabet). Letakkan tiga formula di bagian atas, dengan pemformatan bersyarat yang mengubah sel menjadi merah terang ketika nilainya bukan nol atau TRUE.

Pemeriksaan 1: Neraca seimbang.

=ROUND(SUM(bs_total_assets) - SUM(bs_total_liab) - SUM(bs_total_equity), 2)

Ini harus sama dengan nol, setiap periode, setiap skenario. Jika tidak, Anda memiliki plug di suatu tempat yang tidak Anda maksudkan, atau kesalahan tanda pada item modal kerja, atau Anda menghitung ganda penerbitan utang. Jangan lanjutkan sampai ini nol.

Pemeriksaan 2: Laporan arus kas terikat ke neraca.

=ROUND(cf_ending_cash - bs_cash, 2)

Kas akhir dari laporan arus kas Anda harus sama dengan baris kas di neraca untuk periode yang sama. Jika tidak, CF Anda melewatkan sesuatu, biasanya penyesuaian non-kas, pergerakan pajak tangguhan, atau tanda pada aktivitas pembiayaan.

Pemeriksaan 3: Laporan laba rugi merekonsiliasi ke laba ditahan.

=ROUND(bs_retained_earnings_end - bs_retained_earnings_beg - is_net_income + bs_dividends, 2)

Laba bersih untuk periode ditambah laba ditahan awal dikurangi dividen harus sama dengan laba ditahan akhir. Jika tidak, Anda memiliki penyesuaian ekuitas yang terbengkalai (pembelian kembali saham yang masuk ke baris yang salah) atau IS Anda tidak sepenuhnya mengalir ke ekuitas.

Jalankan ketiganya pada setiap kolom, setiap skenario. Tab _Checks seharusnya terlihat seperti lampu lalu lintas: semua hijau TRUE, tidak ada merah. Jika CFO membuka model Anda dan melihat TRUE hijau, FALSE merah, FALSE merah berkedip, itu menjadi keseluruhan percakapan sekarang. Anda tidak akan sempat membahas jembatan EBITDA. Selamatkan diri Anda dari pertemuan itu.

Konvensi penamaan: diri Anda di masa depan adalah pengguna

Satu kebiasaan dengan leverage tertinggi dalam pemodelan adalah rentang bernama. Alih-alih 'Assumptions'!B14, Anda mereferensikan rev_growth_y1. Alih-alih 'Working Capital'!F22, Anda menulis wc_dso_target.

Manfaatnya: ketika Anda membaca formula enam bulan kemudian, Anda bisa memahaminya tanpa berpindah-pindah antar tab. =is_revenue_y2 * gm_target_y2 - opex_total_y2 terbaca seperti kalimat. ='IS'!C8*'Assumptions'!B16-'Opex'!D14 terbaca seperti kebisingan.

Gunakan awalan yang konsisten:

  • is_ untuk baris laporan laba rugi
  • bs_ untuk neraca
  • cf_ untuk laporan arus kas
  • dr_ untuk pendorong
  • wc_ untuk modal kerja
  • kpi_ untuk metrik output

Kemudian tambahkan akhiran dengan metrik dan periode: is_revenue_y1, bs_inventory_q4, dr_headcount_eng_y2. Penamaannya terbaca seperti API. Siapa pun yang mengambil model dapat menebak nama sel yang mereka inginkan.

Satu aturan lagi: jangan pernah memberi nama rentang dengan angka yang dikodekan keras di dalamnya. tax_rate_25 adalah jebakan karena pada hari tarif berubah menjadi 21%, namanya berbohong. Gunakan tax_rate_federal dan biarkan nilainya berada di sel input biru.

Tabel sensitivitas yang layak ada

Sebagian besar tabel sensitivitas dalam model yang diwarisi bersifat pamer. Tabel data dua variabel pada pertumbuhan pendapatan versus penetapan harga, output: pendapatan. Keren. CFO sudah tahu bahwa harga lebih tinggi dan pertumbuhan lebih tinggi menghasilkan lebih banyak pendapatan. Anda telah menambahkan tab dan 200KB ke file.

Sensitivitas yang berguna dijalankan pada metrik yang akan ditanyakan CFO dalam rapat dewan direksi. Margin EBITDA di bawah tiga skenario penetapan harga dan tiga skenario CAC. Free cash flow di bawah asumsi DSO yang berbeda. Masa kas tersisa di bawah skenario pertumbuhan jumlah karyawan yang disilangkan dengan kecepatan penagihan.

Pengaturan praktis: pilih tiga KPI yang masuk ke deck dewan (margin EBITDA, FCF, masa kas tersisa). Untuk masing-masing, buat sensitivitas dua variabel. Letakkan variabel di sisi setiap tabel yang sesuai dengan tuas yang benar-benar ditarik CEO. CAC dan tingkat konversi, bukan pendapatan dan pendapatan. Pertumbuhan jumlah karyawan dan gaji rata-rata, bukan opex dan opex.

Jika CFO bisa melihat satu tabel dan berkata, "Jika penetapan harga turun 5% dan CAC naik 20%, apakah kita masih mencapai panduan FCF?" itu sensitivitas yang berguna. Jika dia harus menghitung jawabannya sendiri dari tabel, Anda membuatnya salah.

Letakkan tabel sensitivitas di tab Sensitivity, satu tabel per KPI, diberi label jelas. Jangan kubur mereka di dalam tab pernyataan.

Jebakan referensi melingkar

Inilah loop yang akhirnya dialami setiap analis: beban bunga bergantung pada saldo utang rata-rata. Saldo utang rata-rata bergantung pada saldo kas (karena jika Anda punya kas, Anda akan melunasi utang). Saldo kas bergantung pada laba bersih. Laba bersih bergantung pada beban bunga.

Excel melihat ini dan baik mengaktifkan perhitungan iteratif, yang kadang berkonvergen dan kadang tidak, atau melempar #REF! dan model rusak.

Anda memiliki dua pilihan yang bersih. Pilih satu, dokumentasikan pilihan tersebut di README model, dan berhenti memperdebatkannya.

Opsi A: Aktifkan perhitungan iteratif. File, Opsi, Rumus, Aktifkan perhitungan iteratif, iterasi maksimum 100, perubahan maksimum 0,001. Ini berhasil, tetapi rapuh. Model kadang menampilkan angka berbeda saat file dibuka versus saat Anda menekan F9. Auditor akan bertanya. Anda akan menghabiskan dua puluh menit menjelaskan referensi melingkar dalam panggilan due diligence.

Opsi B: Putus siklus dengan lag satu periode. Hitung beban bunga berdasarkan saldo utang periode sebelumnya, bukan periode saat ini. Matematikanya sedikit kurang presisi (Anda kehilangan satu periode akurasi bunga), tetapi model bersifat deterministik. Buka, hitung ulang, dapatkan jawaban yang sama setiap saat.

Untuk model operasional di dalam perusahaan dengan pendapatan di bawah $500 juta, Opsi B menang. Kehilangan akurasi adalah kesalahan pembulatan dibandingkan ketidakpastian asumsi dalam sisa model. Untuk model LBO atau pekerjaan penilaian di mana jadwal bunga penting, Opsi A mungkin diperlukan.

Apa pun yang Anda pilih, tuliskan di tab README, dalam bahasa yang jelas: "Beban bunga menggunakan saldo utang periode sebelumnya untuk menghindari referensi melingkar. Lihat formula sel cf_interest_y1."

Kontrol versi dan catatan perubahan yang menyelamatkan pekerjaan Anda

Konvensi nama file: Model_v3.2_2026-04-26_VH.xlsx. Versi mayor naik untuk perubahan struktural. Versi minor naik untuk pembaruan asumsi. Tanggal dalam format ISO agar file diurutkan secara kronologis. Inisial editor terakhir.

Di dalam file, tab _ChangeLog dengan lima kolom: Tanggal, Editor, Versi, Apa yang Berubah, Mengapa.

Contoh baris:

Tanggal Editor Versi Apa yang Berubah Mengapa
2026-04-26 VH 3.2 Memperbarui pertumbuhan ARR FY26 dari 22% menjadi 18% Persiapan board CFO, asumsi baru berdasarkan aktual Q1 yang menunjukkan ekspansi CS 4 poin di bawah rencana

Saat Anda duduk di ruang due diligence dan analis pembeli bertanya mengapa pendapatan perkiraan Q3 bergerak $1,2 juta antara versi 2.8 dan 3.0, Anda membuka catatan perubahan dan membaca baris tersebut. Anda tidak mencari email yang dikirim Mark kepada Anda di bulan Februari. Anda tidak mengatakan "saya pikir." Anda membaca barisnya.

Tab tunggal ini akan menyelamatkan pekerjaan Anda setidaknya sekali dalam karier Anda. Bangun sekarang, sebelum Anda membutuhkannya.

Kapan harus beralih ke alat perencanaan

Excel adalah alat yang tepat untuk three-statement model, sampai tidak lagi. Sinyal bahwa Anda sudah melampaui kemampuannya:

  • Anda membangun ulang model secara substansial setiap kuartal karena versi sebelumnya sudah terlalu rumit untuk dikembangkan
  • Lebih dari dua orang secara teratur menyentuh file dan Anda tidak bisa mempercayai versi yang digabungkan
  • Perubahan skenario membutuhkan lebih dari satu jam untuk dijalankan dari awal hingga akhir, termasuk memperbaiki dan meregenerasi pemeriksaan
  • File Anda lebih dari 50MB atau memiliki lebih dari 25 tab
  • Anda tidak bisa menautkan aktual dari GL secara otomatis, dan setiap akhir bulan adalah latihan salin-tempel yang memakan waktu satu hari

Ketika dua atau lebih dari kondisi itu benar, saatnya melihat alat perencanaan yang sesungguhnya. Pilihan yang layak untuk tim FP&A di perusahaan menengah:

Adaptive Planning (Workday). Paling cocok jika Anda sudah berada dalam ekosistem Workday (HCM, Financials). Kuat dalam pemodelan berbasis pendorong, lemah dalam fleksibilitas untuk logika kalkulasi yang sangat kustom.

Cube. Lebih ringan, duduk di atas Excel alih-alih menggantikannya. Terbaik untuk tim yang tidak ingin melatih ulang diri pada paradigma pemodelan baru tetapi membutuhkan kontrol versi, pengeditan multi-pengguna, dan integrasi aktual.

Pigment. Lebih baru, lebih fleksibel. Kuat dalam pemodelan multi-dimensi dan percabangan skenario. Lebih baik untuk tim dengan logika bisnis yang kompleks (beberapa SKU, geografi, saluran) di mana struktur baris dan kolom Excel tidak lagi memadai.

Kriteria keputusan, dalam urutan bobot:

  1. Seberapa kustom logika pemodelan Anda? Jika standar FP&A (pendapatan berbasis pendorong, opex berbasis jumlah karyawan), Adaptive atau Cube cukup. Jika Anda memiliki logika yang tidak biasa (pendapatan berbasis proyek, konsolidasi kompleks, multi-mata uang mendalam), lihat Pigment.
  2. Di mana data Anda berada? Jika aktual ada di NetSuite, Sage Intacct, atau QuickBooks, ketiganya terintegrasi. Jika Anda menggunakan ERP buatan sendiri, biaya integrasi akan mendominasi keputusan.
  3. Berapa banyak kursi dan berapa anggaran? Cube mulai sekitar $2.500 per bulan. Adaptive dan Pigment biasanya berkisar $30K hingga $80K per tahun untuk tim FP&A menengah.
  4. Seberapa siap tim Anda untuk melatih ulang diri? Cube memiliki kurva belajar terkecil. Adaptive sedang. Pigment memerlukan investasi nyata dalam pelatihan ulang dan membangun kembali model dalam paradigma baru.

Jangan beralih terlalu dini. Model Excel yang bersih dengan disiplin di atas akan melayani fungsi FP&A dengan 50 orang. Pemicunya bukan ambisi; itu adalah rasa sakit. Ketika rasa sakit tetap di Excel melebihi rasa sakit migrasi, pindahlah.

Standarnya

Three-statement model yang tahan pengawasan adalah model yang bisa diambil oleh analis mana pun di tim, mengubah satu input, melihat pemeriksaan tetap hijau, dan mempercayai outputnya. Itulah standarnya. Bukan keanggunan. Bukan kecerdasan. Kepercayaan.

Anda membangunnya dengan membuat struktur yang membosankan dan eksplisit. Satu tab per pendorong. Satu arah aliran. Tiga warna. Tiga pemeriksaan integritas di tab _Checks. Rentang bernama alih-alih referensi sel. Penanganan referensi melingkar yang terdokumentasi. Catatan perubahan yang memungkinkan pertanyaan due diligence mendapat jawaban satu baris.

Lakukan itu, dan analis berikutnya yang mewarisi file Anda tidak akan mengutuki nama Anda. Mereka akan mengubah satu input, melihat pemeriksaan tetap hijau, dan melanjutkan pekerjaan mereka.

Itulah model yang tahan pengawasan.

Pelajari Lebih Lanjut

About the author

Camellia

Camellia

Principal Product Marketing Strategist

Camellia is Principal Product Marketing Strategist at Rework, helping B2B buyers pick the right software with confidence. With 6+ years in product marketing and 150+ SaaS tools evaluated across CRM, project management, and sales engagement, Camellia turns competitive intelligence into clear, honest comparisons. Readers get vendor evaluations they can trust to cut through marketing noise and decide faster.