Insights

AP masa nyata: ketahui hutang anda sebelum penyata tiba

Tanya pengawal kewangan hotel berapa hutang hartanah kepada pembekal sekarang juga, dan jawapan jujurnya biasanya "beri saya masa hingga Khamis". Wang itu sudah terhutang sebaik sahaja barang melepasi pelantar pemunggahan — tetapi rekodnya menunggu kemasukan data, dan kebenarannya menunggu penyata pembekal. Berikut sebab akaun belum bayar ketinggalan daripada realiti, dan kenapa penyelesaiannya ialah pangkalan data, bukan beban kerja.

Masalahnya: akaun belum bayar wujud sebelum rekodnya

Jumlah-hutang-kami sentiasa basi. Barang diterima sepanjang minggu; invois dimasukkan apabila pejabat kewangan sempat. Antara dua peristiwa itu, baki AP yang dilihat pengurusan adalah salah — kadangkala tersasar satu penghantaran, kadangkala sebulan penghantaran. Penyata pembekal tiba dan menjadi lejar de facto hartanah, yang sebenarnya terbalik sama sekali.

Invois tiba tanpa induk. Pembekal membilkan barang yang diterima seseorang berminggu-minggu lalu. Pesanan yang mana satu? Betulkah kuantitinya? Adakah harganya harga yang dikontrakkan? Apabila pesanan pembelian dan penerimaan berada dalam sistem lain — atau dalam fail lever arch — semakan menjadi satu siasatan, jadi ia dilangkau, dan bil berlebihan serta pendua terlepas masuk.

Hari pembayaran menjadi kelam-kabut. Apa yang perlu dibayar minggu ini, kepada siapa, dan apa yang boleh menunggu? Dibina daripada kertas, larian pembayaran mengambil masa sehari dan masih ada yang tercicir — pembekal dikenakan sekatan kredit atas invois yang sebenarnya sudah dibayar, atau dibayar dua kali kerana penduanya memakai rujukan berbeza.

Kenapa ia berlaku: pembelian dan akaun belum bayar dalam sistem berbeza

Ini ialah separuh AP daripada masalah struktur yang biasa. Peristiwa yang mencipta dan mewajarkan akaun belum bayar — pesanan, penerimaan, harga yang dipersetujui dengan pembekal — berlaku dalam sistem pembelian. Liabiliti, kelulusan dan pembayaran pula berada dalam sistem perakaunan. Sambungkan kedua-duanya dengan eksport dan kemasukan semula, dan setiap serahan menambah kelewatan serta menggugurkan konteks:

• Penerimaan yang sepatutnya mencipta liabiliti sebaliknya menunggu invois dimasukkan.
• Invois yang sepatutnya disemak dalam beberapa saat terhadap pesanannya menjadi pemburuan fail.
• Pembayaran yang sepatutnya menutup rantaian berpaut sebaliknya hanya merujuk nama pembekal dan satu jumlah — sambil berharap.

ERP generik mengendalikan hal ini dengan baik di dalam dirinya sendiri — tetapi di hotel, bahagian pembelian berjalin dengan resipi, outlet, stor dan folio yang tidak dapat dilihatnya, jadi hartanah menjalankan pembelian di satu tempat dan akaun belum bayar di tempat lain, dan jurangnya dijambatani oleh tutup hujung bulan. Cukai berbilang sistem, sekali lagi.

Bagaimana WinX menyelesaikannya: AP pada pangkalan data pembelian

Akaun belum bayar WinX ialah modul pada pangkalan data yang sama dengan pembelian, stok dan lejar am — ERP itu bukan dilampirkan pada operasi, ia ialah operasi:

• Penerimaan mencipta keterlihatan — barang yang diterima terhadap pesanan pembelian serta-merta menjadi sebahagian daripada gambaran akaun belum bayar, sebelum sebarang invois dimasukkan. Diterima-belum-diinvois ialah senarai sedia ada, bukan penemuan audit hujung tahun.
• Invois menyemak dirinya terhadap rantaiannya — invois pembekal direkod terhadap pesanan dan penerimaan yang mewajarkannya; ketidakpadanan kuantiti dan harga muncul semasa kemasukan, dan pendua tiada tempat bersembunyi.
• Larian pembayaran dengan kawalan — invois yang diluluskan dikumpulkan ke dalam kelompok pembayaran mengikut tarikh matang dan pembekal, dilepaskan di bawah profil kebenaran pembayaran; pembayaran dicatat ke lejar pembekal dan GL dalam satu gerakan, sama ada cek, pindahan atau dalam talian.
• Keperluan tunai, lebih awal — setiap akaun belum bayar membawa tarikh matangnya sejak lahir, jadi keperluan tunai minggu depan ialah pertanyaan pada data langsung. Logik lejar langsung yang sama yang meletakkan P&L pada hari itu juga.
• Satu vendor, satu kebenaran — bahagian AR berfungsi dengan cara yang sama (AR lapuk ialah masalah cerminannya), jadi kedua-dua belah kitaran tunai membaca daripada lejar langsung yang sama.

Terbukti di tempat volum invois paling berat

Tekanan akaun belum bayar meningkat sejajar dengan outlet dan pembekal. Manila Ocean Park + Hotel H2O menjalankan sekitar 40 outlet pada satu pemasangan WinX — setiap satunya menerima barang, menggunakan stok dan menjana obligasi pembekal pada rekod yang sama yang digunakan pejabat kewangan untuk membayar. Kumpulan berbilang hartanah seperti The Signature Suites (Kuala Lumpur + Puchong) mendapat rantaian yang sama bagi setiap hartanah dengan pelaporan kumpulan disatukan — akaun belum bayar kelihatan mengikut entiti dan secara keseluruhan, dari satu log masuk.

Soalan lazim

Kenapa akaun belum bayar sentiasa menjadi kejutan di hotel?

Kerana obligasi dan rekodnya lahir dalam sistem berbeza pada masa berbeza. Hartanah berhutang apabila barang diterima; sistem kewangan hanya tahu apabila seseorang memasukkan invois. Antara saat-saat itu angka AP adalah salah, dan penyata pembekal membawa pembetulannya.

Bagaimana satu pangkalan data mengubah semakan invois?

Invois pembekal direkod terhadap pesanan pembelian dan penerimaan barang yang mewajarkannya — rekod berpaut yang sama yang dicipta penjaga stor. Ketidakpadanan muncul semasa kemasukan, ketika ia masih perbualan; bukan semasa audit, ketika ia sudah menjadi hapus kira.

Bagaimana pembayaran pembekal dikawal?

Invois yang diluluskan mengalir ke dalam kelompok pembayaran mengikut pembekal dan tarikh matang, di bawah kawalan kebenaran pembayaran yang menentukan siapa melulus dan melepaskan. Pembayaran dicatat ke lejar pembekal dan GL dalam gerakan yang sama — cek, pindahan bank atau dalam talian.

Apakah manfaat AP masa nyata untuk aliran tunai?

Setiap akaun belum bayar membawa tarikh matangnya sejak saat ia wujud, jadi tunai yang diperlukan minggu depan ialah pertanyaan pada data langsung, bukan unjuran daripada tutup bulan lepas. Penuaan hanyalah satu laporan; penyesuaian penyata berhenti menghasilkan kejutan.

Berkaitan: Pembelian: kenapa stor kehabisan pada malam Sabtu · WinX ERP & kewangan · P&L pada hari itu juga, bukan selepas tutup bulan · AR lapuk dan perakaunan terputus · Kajian kes