1. What an ERP actually is
Strip away the marketing and an ERP — Enterprise Resource Planning system — is one idea: every part of the company writes into the same database, so a fact is recorded once and everyone reads the same copy of it.
That is genuinely all. The modules, the dashboards and the approval screens are consequences. If HR, payroll, purchasing and accounts each keep their own file, then every month somebody has to make those files agree, and the company's real position is always a few days behind whatever it is doing. An ERP removes the copying, and the disagreement goes with it.
2. Master data and transactions
This is the most useful distinction in the entire subject, and almost nobody explains it to new users.
Master data is the list of things that exist: employees, departments, customers, suppliers, items, accounts, leave types. It changes rarely. It is nouns.
Transactions are the things that happen: a punch, a leave application, a purchase order, a payment, a journal entry. They arrive constantly, they carry a date, and they refer to master data. They are verbs.
The practical rule. Fix master data before you go live, not after. A wrong employee record does not stay one mistake — it becomes wrong in every punch, every leave balance and every payslip that refers to it, and each of those has to be corrected separately later.
3. How a document becomes a number
Every transaction in every ERP travels the same road, whether it is a leave application, a purchase order or a payment:
Two of those states deserve attention.
Submitted is where the document stops being editable. This annoys new users — "I just want to fix a typo" — and it is the single most important control in the system. If a document can change after somebody approved it, the approval means nothing. The correct fix is not to edit; it is to return the document, so the trail shows what happened.
Posted is where a business document becomes an accounting fact. Before posting, a purchase order is an intention. After posting, it is a liability in your books. Posting is normally irreversible: you correct it by posting an opposite entry, never by deleting, because deleting would leave a hole where an auditor expects a story.
4. The modules and what each one owns
Module names differ between products, but the ownership almost never does. The useful question about any module is not "what does it do" but "what fact does it own" — the fact that everyone else must read from it rather than keep their own copy of.
| Module | Owns the fact of… | Typical documents |
|---|---|---|
| HR | who works here, in what role, under whose supervision | Employee record, transfer, separation |
| Attendance | who was present, when, and for how long | Punch, manual adjustment, overtime |
| Leave | who is legitimately absent, and what remains of their entitlement | Leave application, encashment |
| Payroll | what each person is owed for a period | Payroll run, payslip, deduction |
| Purchasing | what we have committed to buy | Requisition, purchase order |
| Inventory | what we physically hold, and what it is worth | Receipt, issue, transfer, adjustment |
| Finance | what all of it means in money | Journal, invoice, payment, receipt |
Notice that finance sits at the end of every chain. That is not seniority — it is arithmetic. Attendance decides pay, pay becomes an expense; purchasing decides stock, stock becomes an asset. An ERP is largely the machinery that carries operational events into the accounts without anybody retyping them.
5. Double-entry in three minutes
You do not need to be an accountant to use an ERP, but the moment you understand this, every finance screen becomes readable.
Every transaction is recorded twice: once for where value went, once for where it came from. The two are called debit and credit, and in every valid entry they are equal. That is the whole mechanism — it is a checksum invented in the fifteenth century and never improved on.
Buying stock worth Tk 50,000 from a supplier on credit:
| Account | Debit | Credit | Meaning |
|---|---|---|---|
| Inventory | 50,000 | We now hold goods worth this much | |
| Accounts payable | 50,000 | We owe the supplier this much |
Later, paying that supplier from the bank:
| Account | Debit | Credit | Meaning |
|---|---|---|---|
| Accounts payable | 50,000 | We no longer owe it | |
| Bank | 50,000 | The money left the account |
Nothing was created or destroyed; value moved. Because every entry balances, the sum of all debits in the company must equal the sum of all credits — which is what a trial balance checks. If it does not balance, something is wrong, and the system can tell you so without anyone noticing by eye.
What this means day to day. In a well-built ERP you rarely type debits and credits. You record a business event — receive goods, pay a bill, run payroll — and the system produces the double entry from rules set up once. Your job is to make sure the rules are right, not to do the arithmetic.
6. Approvals, and why they exist
An approval chain is not bureaucracy that got digitised. It exists to enforce segregation of duties: the principle that the person who requests something should not be the person who authorises it, and neither should be the only person who records it.
The reason is unglamorous. Most losses in most companies are not dramatic fraud; they are one person holding every step of a process with nobody looking. Splitting a document across two or three people does not require you to distrust anybody — it just removes the situation in which trust is the only control.
Good ERP approvals share four properties, and it is worth checking any system for all four:
- Ordered — level two cannot sign before level one.
- Attributed — the record shows a person, a timestamp and a comment, not just the word "approved".
- Configurable as data — changing who signs what should be an administrative change, not a programming one.
- Reversible only forwards — an approver can return a document for correction, which is visible, rather than silently editing it.
7. Reports: one number, one place
There are two kinds of report and confusing them causes most reporting arguments.
Transactional reports answer "what happened?" — a list of punches, an outstanding-invoice list, a stock ledger. They must be exact, current and traceable back to individual documents.
Analytical reports answer "how are we doing?" — attendance trends, overtime by department, ageing summaries, dashboards. They aggregate, and they are for judgement rather than for proof.
The discipline that matters is that both must come from the same data. The moment a dashboard is fed by a separate spreadsheet, you have two versions of the truth and meetings stop being about decisions and start being about whose number is right.
8. Why ERP projects fail
Very few fail for technical reasons. The recurring causes are the same everywhere, and all four are avoidable if you know them in advance.
Dirty master data
The single biggest cause. Duplicate employees, staff who left three years ago, suppliers spelled four ways. The system faithfully carries every one of those errors into every transaction that follows. Cleaning the lists is dull, unglamorous work that nobody wants to own — and it decides the outcome of the project.
Nobody actually owns it
An ERP needs an owner inside the company — a person, named, with time allocated, who learns the system properly and decides how it is configured. Without that, the vendor makes decisions that should have been the company's, and every question becomes a support ticket.
Customising before understanding
The instinct on day one is to make the new system behave exactly like the old spreadsheet. Some of those habits exist for good reasons; many exist only because the spreadsheet could not do better. Run the standard way for a month first, then customise what genuinely does not fit. You will customise about a third of what you expected to.
Going live everywhere at once
Switching on attendance, leave, payroll, purchasing and accounts on the same Sunday guarantees that when something is wrong you cannot tell which module caused it. Go module by module. Attendance first is usually right: it produces visible value in week one and it teaches everyone the interface with low stakes.
Glossary
The words that appear on every ERP screen, defined once.
- Master data
- The lists of things that exist — employees, items, accounts, suppliers. Changes rarely, referenced constantly.
- Transaction
- Something that happened on a date: a punch, an order, a payment. Refers to master data.
- Document
- One transaction as a user sees it, with a number, a status and an approval history.
- Posting
- The moment a business document becomes an accounting entry. Normally irreversible; corrected by a further entry.
- General ledger (GL)
- The complete record of every financial posting, organised by account.
- Chart of accounts
- The structured list of accounts money can be recorded against — assets, liabilities, income, expenses.
- Debit / credit
- The two halves of every entry. Equal in every valid transaction. Not "good" and "bad".
- Trial balance
- A check that total debits equal total credits across the whole ledger.
- Ageing
- How long money has been owed to you, or by you, grouped into bands such as 0–30 and 31–60 days.
- Sub-ledger
- Detail behind one ledger account — for example every customer's balance behind the single receivables figure.
- Reconciliation
- Proving that two records of the same thing agree — stock on the shelf against stock in the accounts, for instance.
- Accrual
- Recognising something in the period it belongs to rather than when cash moves. Leave earned monthly is an accrual.
- Segregation of duties
- Splitting a process so no single person can request, approve and record the same thing.
- Audit trail
- The permanent record of who did what, when. Its value is that it cannot be edited.
- Role
- A named set of permissions given to a job rather than a person, so access follows the position.
- Go-live
- The date the new system becomes the official record and the old one stops being updated.
- Opening balance
- The position carried into the new system on day one, so history does not have to be re-entered.
Where to go next. If you want to see these ideas in a working system, the ZakERP user manual is public and shows every one of them in practice. If you want the argument for our approach specifically, read Why ZakERP.