Jawapan ringkas: untuk membuat padanan bayaran homestay, ambil penyata bayaran OTA, padankan setiap baris dengan tempahan menggunakan kod pengesahan, semak jumlah semua baris sama dengan wang yang masuk ke bank, dan baru rekodkan. Dibuat dengan tangan, ia lambat dan senang silap. PMS kami, AntlerHub, membuat padanan itu dan meninggalkan satu klik manusia sebelum apa-apa direkodkan.
Kebanyakan panduan tentang topik ini ditulis untuk pengurus sewa jangka pendek di Amerika yang guna QuickBooks. Yang ini ditulis untuk pengendali di Malaysia yang ada Airbnb, Agoda, Booking.com dan akaun bank yang menunjukkan baris "AIRBNB PAYMENTS" tanpa sebarang penjelasan. Ia menerangkan cara sistem kami sendiri mengendalikannya, termasuk bahagian yang tidak sekemas yang kami mahu.
Kenapa satu kemasukan bank daripada Airbnb susah dipadankan?
Kerana bank nampak satu nombor, tetapi OTA nampak banyak tempahan. Secara umum, Airbnb melepaskan bayaran kira-kira 24 jam selepas waktu daftar masuk yang dijadualkan untuk penginapan kurang 28 malam, kemudian bank mengambil beberapa hari untuk memaparkannya (Pass the Keys). Syarikat perisian pengurusan hartanah menggambarkan masalah yang sama: beberapa tempahan digabung dalam satu deposit, yuran dan pelarasan ditolak sebelum wang dihantar, dan caj pada satu tempahan boleh ditolak daripada bayaran lain (VRPlatform).
Berikut contoh rekaan. Angkanya bukan sebenar, hanya untuk menunjukkan rupa masalahnya:
| Tempahan (kod pengesahan) | Bersih kepada anda |
|---|---|
| Penginapan A | RM 1,240.50 |
| Penginapan B | RM 862.00 |
| Penginapan C | RM 1,455.90 |
| Penginapan D | RM 304.00 |
| Kemasukan bank | RM 3,862.40 |
Bank anda menunjukkan RM 3,862.40. Senarai tempahan anda ada empat penginapan, setiap satu dengan harga kasar dan komisen yang perlu anda kira sendiri. Kalau anda tak boleh tunjuk empat penginapan mana yang membentuk nombor itu, anda tak boleh pastikan sama ada ada wang yang hilang.
Apa sebenarnya dalam penyata bayaran?
Ia bergantung pada OTA, dan itulah masalah kedua.
- Airbnb mengeksport fail di mana satu baris bayaran diikuti baris tempahan yang dilindunginya. Pengumpulan ikut kedudukan: baris selepas baris bayaran milik bayaran itu.
- Agoda, Booking.com, Expedia dan Ctrip/Trip.com memberi senarai rata, dan nama lajur berubah antara eksport. Penyata bayaran Booking.com dan nasihat kiriman wang Expedia pula datang sebagai PDF.
- Tarikh ialah perangkap. 07/08/2026 bermaksud 7 Ogos bagi satu platform dan 8 Julai bagi platform lain.
Pembaca kami boleh baca CSV, Excel dan PDF. Ia mencari lajur mengikut tajuk, bukan kedudukan, dan bila tarikh tidak jelas, ia baca mengikut cara Airbnb, Expedia dan Agoda mengeksport, kemudian menandakannya dan tidak memilih secara senyap. Pembaca itu tidak membuat keputusan sendiri: ia melaporkan apa yang disangka fail itu katakan, ditambah amaran, dan seorang manusia mengesahkan.
Bagaimana padankan satu baris penyata dengan tempahan?
Kod pengesahan dahulu, kerana itulah satu-satunya pengenal yang kedua-dua pihak ada. Sistem kami mencari kod itu dalam tempahan yang sudah ditarik masuk daripada pengurus saluran.
Sesetengah penyata tidak mencetak kod. Maka cara sandaran ialah nama tetamu ditambah tarikh daftar masuk, dan kedua-duanya mesti sepadan. Kalau dua tempahan berkongsi nama dan tarikh daftar masuk yang sama, baris itu tidak diteka. Ia ditanda sebagai tidak sepadan dengan nota supaya anda pautkan sendiri, kerana pautan yang salah senyap-senyap mengkreditkan tempahan yang salah.
Baris tidak sepadan tidak menyekat keseluruhan kumpulan. Wang di bank itu benar sama ada anda boleh namakan setiap tempahan di belakangnya atau tidak, jadi baris itu diimport, ditanda dan mudah dicari. Anda boleh nyahtanda jika mahu mengecualikannya.
Bagaimana jika penyata yang sama, atau tempahan yang sama, muncul dua kali?
Ini lebih kerap daripada yang disangka: anda eksport julat tarikh yang bertindih, atau OTA mengeluarkan semula bayaran yang dibetulkan dengan rujukan baharu. Ada dua perlindungan.
- Pemindahan itu sendiri unik. Satu bayaran dikenal pasti oleh pengendali, platform dan rujukan bayaran OTA. Mengimport semula penyata yang sama mengemas kini bayaran yang masih belum direkod dan tidak menyentuh yang sudah direkod. Bila fail tiada rujukan (fail Trip.com tiada), sistem membina satu daripada platform, tarikh dan jumlah, dan menyemak sama ada wang yang sama sudah ada dalam akaun.
- Setiap tempahan ingat bayaran mana yang menyelesaikannya. Baris untuk tempahan yang sudah dilindungi bayaran terdahulu diberi label, jadi anda nampak pada draf sebelum mengesahkan apa-apa.
Ada satu perkara jujur di sini. Airbnb kadang-kadang membayar penginapan panjang secara ansuran dalam dua pemindahan. Itu sah, jadi ansuran kedua tetap dikira, tetapi diberi label "dibayar lebih awal" supaya anda boleh bezakan ansuran daripada pendua. Airbnb juga boleh menyenaraikan bilik dan cukai pass-through sebagai baris berasingan dalam satu pemindahan, jadi baris dijumlahkan mengikut tempahan sebelum tempahan direkod.
Tempahan mana yang termasuk skop?
Hanya yang anda suruh sistem mulakan daripadanya. Setiap pengendali ada tarikh daftar masuk mula guna. Tempahan yang daftar masuk pada atau selepas tarikh itu dipadankan, dikunci, dan dikira sebagai wang yang OTA masih berhutang kepada anda. Penginapan yang daftar masuk sebelum itu masih dipaparkan dan direkod, tetapi tiada pautan tempahan dan tiada kunci.
Sebabnya masalah sempadan. Penginapan yang merentasi tarikh mula guna sebahagiannya akaun lama dan sebahagiannya akaun baharu, dan belum ada layanan perakaunan yang dipersetujui untuk pecahan itu. Kami memilih untuk tidak memautkan, bukannya mereka peraturan. Ruang kerja baharu lalai pada hari ia bermula, dan anda boleh mengubahnya pada skrin penyelesaian.
Apa yang direkodkan dalam akaun?
Wang yang benar-benar tiba. Catatannya: debit bank, kredit akaun kutipan platform. Jika penyata menyatakan komisen OTA secara berasingan, komisen direkod sebagai perbelanjaan dan baris bank ialah jumlah bersih.
Satu peringatan penting untuk akauntan: kami tidak menaikkan akaun belum terima bagi setiap tempahan yang berbunyi "Airbnb berhutang RM X" semasa tempahan dibuat. OTA mengeluarkan invois kepada tetamu, menyimpan komisennya dan membayar anda bersih, jadi satu-satunya angka yang boleh kami nyatakan tanpa mereka-reka ialah yang benar-benar tiba. Jika akauntan anda mahukan invois kasar bagi setiap tempahan, itu reka bentuk yang berbeza daripada kami.
Dua perkara praktikal:
- Rekod dibuat ke Bukku, jadi akaun Bukku yang bersambung dan akaun bank yang dipetakan diperlukan. Tanpanya, bayaran kekal belum diproses dengan ralat yang boleh dibaca.
- Setiap wang masuk membawa tag OTA dan lembaran tempahan yang dilindunginya, supaya setahun kemudian "RM 3,862.40 daripada Airbnb" masih menjawab soalan "penginapan yang mana?".
Agoda ada satu lagi had. Satu fail bayaran Agoda mencampurkan tempahan Agoda Homes dan Agoda YCS tanpa apa-apa untuk membezakannya, jadi penyelesaian menganggapnya sebagai satu "Agoda". Trip.com dan Ctrip juga satu kumpulan.
Kenapa ada langkah draf dan sahkan, bukan automatik sepenuhnya?
Kerana fail penyata ialah hasil kerja manusia. Orang tersalah seret tab, bulan, atau seret fail yang sama dua kali. Maka satu proses baca menghasilkan kumpulan draf yang anda lihat dan sahkan. Hanya Sahkan yang menulis bayaran dan jurnal.
Sahkan kembali serta-merta dan kerja latar belakang membuat rekod, satu pusingan sistem akaun bagi setiap bayaran. Satu penyata boleh ada ratusan baris, dan tab pelayar tidak patut menjadi penghalang antara anda dengan akaun yang lengkap. Jika pelayan dimulakan semula separuh jalan, bayaran yang belum direkod kekal belum diproses, dan satu kerja cuba semula mengambil apa yang belum diproses atau gagal.
Apa lagi yang boleh silap?
- Susunan fail berubah. OTA menukar nama lajur. Pembaca boleh menangani sinonim, tetapi susunan yang benar-benar baharu bermakna amaran dan pembetulan manual.
- Tarikh bayaran tiada, biasanya daripada PDF. Anda tetapkan tarikh wang tiba sebelum ia direkod.
- Kemasukan bank tidak sama dengan penyata. Itulah yang padanan cari, tetapi ia bermakna seseorang perlu mengejar perbezaan dengan OTA.
- Tempahan tanpa harga dalam sistem tidak boleh dikira sebagai wang yang masih terhutang. Ia muncul dalam kiraan berasingan supaya anda boleh betulkan.
Rutin yang praktikal
- Muat turun penyata daripada setiap OTA seminggu sekali, atau selepas setiap bayaran besar.
- Muat naik dan baca draf: baris tidak sepadan dahulu, kemudian apa-apa yang berlabel dibayar lebih awal atau di luar skop.
- Bandingkan jumlah draf dengan kemasukan bank.
- Sahkan. Beberapa hari kemudian lihat ringkasan penyelesaian tertunggak untuk tahu apa yang setiap OTA masih hutang.
Kalau anda urus 10 unit atau lebih dan masih buat ini dalam hamparan, lihat perbandingan PMS lawan Excel kami, dan untuk apa yang berlaku selepas wang dipadankan, bagaimana penyata pemilik bulanan dibina. Jika mahu ini berjalan pada unit anda sendiri, halaman AntlerHub dan harganya di /antlerhub.
Artikel ini menerangkan cara perisian kami merekod angka. Ia bukan nasihat perakaunan atau cukai; sahkan cara syarikat anda merekod pendapatan dan komisen OTA dengan akauntan anda sendiri.