Managing is not the same as administering. Managing is linked to having to make decisions based on information which may or may not be available or complete. Administering, on the other hand, is ensuring all steps and actions are in line with clearly stated guidelines. There is less scope for discretionary decision that is in-built in managing.

In view of this, managing sometimes call for gut-feel decision based on the risk-reward axis. Accountability is the hall-mark of managing. In administering, the rules need to be adhered to, notwithstanding the situation. Any departure from the stated rules is looked upon as non-compliance.

As entrepreneurs, it is important to realise that business is managed and not administered! This means, any decision that the entrepreneur makes in relation to the business would normally be based on non-complete and hazy information as time is of essence. Hence business management to steer the business to a safe and secure future well-being is a challenge indeed for entrepreneurs. This is more so since the business does not exist in isolation but exists within a business ecosystem. It is impacted by actions by other players in the ecosystem and impacts others in the ecosystem. A business ecosystem can be diagrammatically shown as below:

business ecosystem

Fortunately, there are tools available to help entrepreneurs in managing their business. These tools allow entrepreneurs when making business decisions to be on the risk-reward axis where relevant information which can be extracted from such business tools are available.

These tools can be categorised as “Enterprise Management System” (EMS). At its very basic level, EMS would be on a single functionality mode. For instance, function related to accounting, or marketing, or HRMS. The focus is narrow and specialised. Invariably, accounting would be among the first function that a business seeks under EMS.

However, an EMS need to have a wider scope in terms of functionality. This is because EMS needs to address the three segments existing in every business.

The three segments are front-end segment, middle segment, and back-end segment.  Awareness and understanding this segmental concept is key for entrepreneurs. The segments, however, may not always be as clear-cut or pre-defined. Some of them may be merged together or some may be split further.

The front-end segment primary deals with activities related to customer and marketing. The middle segment relates mainly to raw materials and production process; whilst the back-end segment relates to activities that “glue” the different parts of the business together in terms of financial planning and reporting, and compliance to regulations and laws within the business ecosystem.

The three segments can be diagrammatically shown as below:

business segments

An Enterprise Management System (EMS), hence, should be able to fulfill most of the primary functions within a business as dictated by the three major segments as explained above. A business using only a single function such as accounting would only be addressing certain requirements at the back-end segment. The more the functions are available and integrated, and used as a business tool, the larger would be the information base, from which relevant information can be extracted and analysed, in support of the decision-making process by the entrepreneur.

In this context, entrepreneurs managing businesses can hopefully make better decisions for the future well-being of the business. This is due to “blind-spots” appearing before the entrepreneur can be reduced and “visibility” in the business horizon be clearer and enhanced.

A final note on the segments within a business. People within the business must collaborate and act as a team where internal disputes or interests need to be subservient to the needs of the customer or external party. Even though people in the business inevitably see themselves as belonging to different sections, it is vital to realise that the customer on the outside sees staff as one and the same organisation.

Any bad experience with any one person would paint a bad image of the business, even though accountability is with another person! Thus, staff must be fully conversant on the meaning and implications of “Customer Relationship Management (CRM).”

I shall continue further on this topic in my future write-up. Watch this space.





In my interaction with SME entrepreneurs, I always have this feeling that they have problems understanding the meaning of debit or credit in the context of an accounting system. This should not be the case. The reason being these terms are easy to comprehend and use. You do not need to be a student of accounting to really grasp these concepts. I believe that in the old days, the system was created as such, to make things simpler to record and to report; with a built-in internal control to ensure that all figures are processed accordingly with no missing or mistaken figure or transaction.

It is critical to understand the in-built internal control used by the system. The numbers recorded on one side will always equal to the numbers recorded on the other side.

I imagine that historically the person inventing the seeds of accounting system as we know it must have taken a blank piece of paper. He then drew a vertical on the blank page to split the page into two halves. Then he proceeded to say, the left side shall be in balance with the right side all the time. An action impacting the two halves can either be an increase, a decrease or a hold.

debit-credit LHS-RHS

At the start, the two halves will be balanced meaning that the Left-hand Side (LHS) amounts equals the Right-hand Side (RHS) amounts. He then invented the term “Debit” to denote actions that increase the amounts on the LHS; and “Credit” to denote actions that increase the amounts on the RHS. For the reverse actions, he proceeded to use “Credit” to denote actions that decrease the amounts on the LHS and “Debit” to denote actions that decrease the amounts on the RHS. Hence as follows:

LHS = Debits for increase in amounts; and Credits for decrease in amounts

RHS= Credits for increase in amounts; and Debits for decrease in amounts

With this, the double-entry system was created. In order to maintain the in-built internal control of a balanced LHS and RHS, any action of increase, decrease or hold would necessitate another corresponding increase, decrease or hold action.

The inventor then proceeded to populate the LHS of the page with items deemed relevant to this side, and did the same for the RHS.

When there is an increase in amount action for the LHS item, another corresponding action is performed to counter this movement, either by an increase in amount action for item in the RHS or a decrease in amount action for another item in the LHS.

Hence a debit action is counter-acted with a credit action. This is still in use until today, and remains to be known as debits and credits of the double-entry accounting system.


So, what are the items that populate the LHS of the page and the RHS?

I shall explain this in my next write-up. Stay tuned!



Seminar 16 May 2017 – Khas untuk Usahawan IKS

Seminar 16 Mei 2017 – Tingkat Pengurusan Kewangan & Perakaunan untuk Usahawan IKS.

Terima kasih pada para perserta untuk seminar yang telah diadakan. Semoga ada manafaat untuk kita.


IMG-20170516-WA0033 (1)

Demonstrasi Sistem Online – see attached file for presentation slides:

Accounting Demo Online

Agenda bagi seminar tersebut adalah seperti berikut:

Agenda 16 May 2017 draft



Presentation Slides – Pengurusan Kewangan Perniagaan

frontpage 14May2017


Terima kasih kepada para peserta “Pengurusan Kewangan Perniagaan bagi Usahawan Kiosk” kerana memberi peluang untuk berkongsi kemahiran pengurusan bisnes dan kewangan hari ini di Shah Alam. Saya doakan yang perkongsian tersebut sedikit sebanyak bermanafaat untuk anda dalam perjalanan anda sebagai usahawan didalam dunia perniagaan.

Saya berbesar hati untuk menjawab sebarang pertanyaan yang ada berkaitan pengurusan bisnes dan kewangan bisnes anda.

Terima kasih juga pada ICU Selangor, Bahagian Kiosk.

Slides bagi perkongsian hari ini adalah seperti file lampiran.

Salam hormat.

Thank to the participants of kiosk business-operators for the opportunity to share on the business & financial management skills today in Shah Alam. I pray that some of the sharing are beneficial to you as you endeavour as enterpreneurs in the the world of business.

I would be glad to respond to any query that you may have in relation to financial management for your business.

Thank you to ICU Selangor, Kiosk Division as well.

The presentations slides are as attached.

Kind regards.





Sejarah sistem perakaunan yang digunapakai sekarang ini menetapkan yang setiap activiti ekonomi yang melibatkan nilai kewangan (“financial value”) akan dicatitkan dalam dua penrekodan (“double entry”). Tujuan ini dilakukan adalah supaya jumlah yang dimasukkan senantiasa seimbang. Ini bagi membantu pencatit akan maklumat yang direkodkan, dan memastikan penrekodan dibuat selaras dengan kehendak sistem tersebut.

Dari kaedah sistem perakaunan “double entry” terbit istilah “Debit” dan istilah “Credit”. Misalan ini adalah sama seperti kedua-dua bahagian pada duit syiling. “Two faces, but refers to the same coin”. Setiap “double entry” itu akan menerangkan sesuatu perkara (“what item”) pada satu bahagian; dan kemudian menerangkan perkara apa yang diwaklili (“represented by”) pada bahagian yang lain.

Dengan ini, sistem perakaunan “double entry” akan senantiasa seimbang. Dan kaedah ini juga membuatkan imbangan duga (“Trial Balance”) untuk menjadi seimbang. Ini adalah dimana matematik nya adalah seperti berikut:

Jumlah Debit = Jumlah Credit

Cuma terdapat pecahan untuk Debit tersebut dan demikian untuk Credit. Imbangan Duga adalah lapuran kewangan utama kerana dari sinilah boleh dikeluarkan Lapuran Penyata Untung/Rugi dan Lapuran Kunci Kira-Kira.

Pecahan pada “Debit” atau pun “Credit” dan definisi mudah istilah-istilah tersebut adalah seperti berikut:

debit-credit no 1

[* Modal (atau “Equity”) biasanya ditunjukkan bersama Liabiliti kerana ianya adalah sejenis Liabiliti yang khusus.]

Cara nak mengenali “Debit” atau “Credit” adalah dengan melihat samada bertambahnya atau berkurangnya jumlah untuk istilah-istilah yang diterangkan. Butiran nya adalah seperti berikut:

debit-credit no 2

Misal: Catitan adalah untuk “Debit” jikalau jumlah Aset terdapat penambahan; dan catitan adalah untuk “Credit” jikalau jumlah Aset terdapat pengurangan.

Jika diperhatikan pada kitaran bisnes, sistem perakaunan “double entry” yang melibatkan “Debit” dan “Credit” boleh jelaskankan seperti berikut:

impact debit-credit

example debit-credit

Boleh dilihat yang setiap keterangan akan disusuli oleh dua penrekodan, yaitu “Debit” dan “Credit”; bergantung pada impak yang terbit dalam keterangan tersebut.

Dengan ini bolehlah disimpulkan yang bahawa membongkar rahsia “Debit” dan “Credit” dalam sistem perakaunan memerlukan kefahaman tentang Aset dan Liabiliti (yang menjadi asas untuk Lapuran Kunci Kira-Kira); dan Pendapatan dan Perbelanjaan (yang menjadi asas untuk Lapuran Penyata Untung/Rugi). Dari titk tolak ini, penrekodan “double entry” untuk “Debit” dan “Credit” bergantung pada penambahan atau pengurangan jumlah untuk item-item tersebut.

Mudah saja!


  1. Debit biasanya di tunjukkan sebagai jumlah positif dan Credit pula ditunjukkan sebagai jumlah negatif; selaras dengan perbezaan sifat jumlah-jumlah tersebut.
  2. Namun demikian sekiranya Debit dan Credit ini di tunjukkan berasingan dalam ruangan “column” masing-masing, jumlah untuk Debit dan Credit kebiasaan nya akan ditunjukkan sebagai jumlah positif.
  3. Tetapi sekiranya Debit dan Credit ini ditunjukkan dalam senarai yang sama dalam ruangan “column” yang satu, jumlah Credit pasti ditunjukkan dalam bentuk jumlah negatif.





Setiap aliran yang berkait dengan nilai wang perlu di dokumen kan, dan aliran ini di kenalpasti pembahagian nya dalam bentuk transaksi. Dalam erti kata lain, transaksi-transaksi ini adalah pecahan daripada aliran tersebut. Sebagai contoh, aliran dalam proses pembelian akan berterusan selagi bisnes terlibat dalam proses pembelian. Bagaimana pun, aliran pembelian akan dikenalpasti melalui transaksi yang berlaku. Aliran pembelian mungkin berlaku sepanjang tahun, tetapi ianya  dikenalpasti dalam bentuk, misalnya, 50 transaksi yang berlaku dan yang didokumenkan untuk tahun tersebut.

kitaran bisnes Chart of Accounts

Dan apabila transaksi-transaksi itu perlu didokumenkan, bagaimanakah caranya? Dalam sistem bisnes, kita akan letakkan transaksi-transaksi itu dibawah tajuk yang sesuai, bagi tujuan pendokumenan.

Kita perlu tahu dibawah tajuk apakah transaksi itu patut didokumenkan. Dan tajuk ini wajib membayangkan apa kandungan transaksi agar pembaca tajuk tersebut faham secara terus tentang maksud dan kandungan tajuk tersebut.

Secara dasarnya, kesemua transaksi-transaksi yang berlaku, yang terbit dari kesemua aliran proses dalam bisnes boleh didokumenkan dalam satu tajuk. Misalnya, dibawah tajuk “Transaksi Bisnes”. Bagaimanapun, ini tidak berbaloi kerana cara begini tidak memberi manfaat kepada bisnes dari segi analisa maklumat tentang prestasi bisness. Apakah yang dapat dititip dari jumlah nilai wang yang terdapat dalam tajuk tersebut bagi mendapatkan maklumat tentang prestasi untung atau rugi bisnes? Agak sukar!

Mungkin sebagai pembaikan, kita pecahkan tajuk itu kepada “Transaksi Bisnes” dan “Transaksi Cash”. Dengan ini setiap transaksi berkaitan “cash” didokumenkan dibawah tajuk “Transaksi Cash” dan yang lainnya dibawah tajuk “Transaksi Bisnes”. Jika ini dilakukan, kita akan dapat tahu jumlah cash yang direkodkan untuk bisnes dengan melihat jumlah dibawah tajuk “Transaksi Cash”.

Walau bagaimana pun, ini masih tidak berbaloi kerana pecahan pada tajuk “Transaksi Bisnes” wajib dibuat seterusnya. Misalnya, pembelian dan jualan merupakan dua transaksi yang berbeza sifatnya; dan boleh didokumenkan dibawah tajuk-tajuk yang sepatutnya. Contohnya, “Transaksi Pembelian” dan “Transaksi Jualan”.  Dengan ini, transaksi-transaksi yang berkaitan pembelian didokumenkan dibawah tajuk “Transaksi Pembelian”; dan yang berkaitan jualan dibawah tajuk “Transaksi Jualan”.

Dan begitulah seterusnya, dimana tajuk-tajuk yang sesuai yang membayangkan kandungan transaksi akan diwujudkan didalam bisnes. Dan senarai tajuk-tajuk inilah yang dinamakan “Chart of Accounts”; dan setiap tajuk itu dinamakan “account name”.

Usahawan perlu juga memahami yang tajuk-tajuk yang diwujudkan berkait rapat dengan sifat transaksi yang didokumenkan. Transaksi-transaksi yang melibatkan Punca Pendapatan bagi bisnes kebiasaannya akan didokumenkan dibawah kumpulan “Sales Revenue” atau Jualan. Bagi Pembelian dan Kos Jualan, ianya dibawah “Purchases/Cost of Sales” atau Pembelian/Kos Jualan. Begitulah seterusnya untuk Perbelanjaan, Aset, Liabiliti dan lain-lain. Bagi memudahkan pengasingan kumpulan tajuk-tajuk ini kod-kod akan dicipta untuk setiap kumpulan. Tajuk-tajuk yang diwujudkan didalam kumpulan berkenaan akan menuruti kod kumpulan.

Dengan ini, kita dapati dalam “Chart of Accounts” ada apa yang dinamakan “Account Header” yang membayangkan kumpulan bagi tajuk-tajuk tertentu; dan “Account Details” yang menunjukkan tajuk yang diwujudkan untuk mendokumenkan transaksi bisnes. Tajuk ini kebiasaannya dalam bentuk “account code” dan “account name”.

Chart of Accounts example

Dan melalui olahan-olahan pada “Chart of Accounts” inilah kita dapat mengeluarkan lapuran kewangan seperti Penyata Untung/Rugi (“Profit and Loss Statement”) dan Kunci Kira-kira (“Balance Sheet”).

Apa yang penting yang perlu difahami dalam pengeluaran lapuran kewangan adalah bisnes perlu menetapkan “Chart of Accounts” tanpa sebarang perubahan. Ini bagi membolehkan perbandingan (“comparison”) dibuat dalam memantau prestasi dari tahun ke tahun. Ini bermakna pengolahan “Chart of Accounts” perlu di beri perhatian pada awal pengujudannya agar perubahan yang dibuat keatasnya kemudian adalah minimal.





The idea of mapping arises because of the modular nature of information system designed for businesses. And the reason why the design concept is modular is to simplify the interconnected process by segregating the process to manageable logical portions and ease the programming required behind the system. It is also to isolate any bugs in the programming during debugging process.

The critical factor in modular design for a system is the integrity of the system as a whole which must be assured. Data passed from on module to another must be intact and as expected. If this is not happening, then the integrity of the whole system is suspect. When integrity is suspect, then the system is inevitably a failure since reliability and accuracy cannot be assured. Factors which are important in a business information system.

Since the modular concept requires data to be inputted only once in a particular module, the source data represents the details captured in the said module. Once the data is captured in detail, there is no necessity for the same detailed data to be passed on to another module. Very seldom in system design that this is done.

Details are maintained in one module. Summary of the details that has been pre-defined and mapped to the corresponding detailed data is maintained in another module. By the process called “drill-down”, the clicking on the summary data will bring the user to the detailed data and displayed on-screen by the system.

Imagine a module that maintains the details on inventory. The list of inventory names, quantity-in-hand, unit cost, etc. is managed here. When quantity is added from purchases or manufacturing, the source data on the details is captured in the inventory module. This inventory process will subsequently trigger an accounting entry in the accounting module. The summary is captured in the accounting module on the total inventory added. This is reflected by the increase in the monetary value of the Inventory Account balance.

If there is no “mapping” established, then each and every item in the inventory module will have a corresponding account created in the accounting module. So, if there are, say, 300 inventory items then there will be 300 corresponding accounts for inventory in the accounting module. This is wasteful and cumbersome to manage. A better way to manage is to “map” the items in the inventory module to a particular accounts code in the accounting module. Hence the whole list of 300 products could be map to say, 3 or 4 accounts codes; depending on the requirements of the business. This will be a much more elegant and cleaner method to manage the situation.

Thus, when details of the data are transferred to the other module, the other module will capture and reflect summary balances only. The data transfer can either be performed automatically or manually; depending on the system data flows.

An example is illustrated as below:

Let’s say that there are nine (9) product codes in the inventory module. The details such as description, stock balance, price and unit cost are managed in this Inventory Module. These nine items are “mapped” to one accounts code in the Accounting Module, i.e. to “Inventory – Fashion Products”.

Suppose that there is an Inventory-In transaction where finished items are received from Manufacturing. The details are recorded in the Inventory Module to the corresponding product. In this instance, only three items are manufactured and hence three amounts are recorded (i.e. the details) with total amount of RM1,750. When these transactions are imported into Accounting Module, the total recorded in the accounts code for “Inventory – Fashion Products” is RM1,750 (i.e. in summary); without identifying the details.

 mapping inventory to account code

The “import” process when triggered can be performed automatically or manually. An automatic process is preferred when importing the data to another module. Nonetheless, a manual process for “import” will do just fine so long the correct accounts codes are identified.

With this arrangement, the details are in Inventory Module. The accounts code in the Chart of Accounts will then not unnecessarily be a long and cumbersome list. Other “mapping” can also be performed subject to the capability of the business information system.

Finally, note that the “mapping” in the example above is known as “many-to-one” relationship. Other types of relationships are one-to-one relationship, one-to-many relationship and many-to-many relationship.

Please be informed that we shall be conducting our monthly seminar for SME entrepreneurs on enhancing Accounting and Finance knowledge and skills on the 18 April 2017 at Bangi Gateway. Interested business owners and guests are welcome to attend and participate in this sharing session.




Untuk makluman usahawan IKS yang berminat dalam meningkatkan ilmu keusahawanan. Seminar bulanan yang dianjurkan oleh pihak GNZ akan diadakan pada 18 April 2017 ini bertempt di Bangi Gateway. Untuk pendaftaran, click link berikut:


18 April 2017

Tingkatkan ilmu keusahawanan. Ketahui cara membongkar misteri lapuran kewangan dalam memantapkan bisnes anda! #1sme1sistem.