Software for contractors in Malaysia

This page is for Malaysian main contractors and trade contractors who run several jobs at once and can no longer find the latest instruction. The team might be a director, a project manager, a quantity surveyor, and site supervisors. The jobs might be fit-out, M&E, renovation, or small civil packages. The shared trait is a contract sum that changes, and a claim that must match the change.

It is a poor fit for a developer choosing an enterprise project suite for dozens of simultaneous towers, and for a consultancy that sells design rather than construction. It is also a poor fit if the only request is a drawing register with no commercial file. We will say so. A document folder without a claim is a lighter problem, closer to our document-management pages.

If you also buy materials into a store and issue them to jobs, say whether the store is the pain or the claim is the pain. Inventory pages on this site cover stock. This page covers the project commercial file. Doing both in the first release is how contractor projects double before anyone has certified a claim.

The award letter is a PDF. Variations arrive as WhatsApp photos of a marked-up drawing. The progress claim is a workbook emailed to the client’s representative. The subcontractor’s bill is another workbook. When the client pays a different amount, nobody can point to the line that was cut, because the pack was rebuilt for each submission and the previous version was overwritten.

Site evidence has the same shape. A supervisor photographs a completed area. The photo lives on that phone. A month later the claim is challenged and the phone has a new owner. Instructions to proceed, stop, or change a detail are in a group chat that the quantity surveyor is not in. The commercial file and the site file are strangers.

A second pattern is the tool bought for reporting. A project system shows a Gantt chart nobody updates, while the real dates live in a Monday meeting. If the team will not maintain a programme, do not buy a programme. Buy the claim pack and the variation log they already produce under pressure.

The project has a client, a site, a contract sum, a start, and a status. Variations have a description, a value your QS entered, a status, and the instruction that caused them. Progress claims have a period, the amount applied, the amount certified if you record it, and the pack of backup. Subcontractor bills point at the same project so a margin conversation is possible without merging spreadsheets on Sunday.

Site records are attachments with a date and a place in the file: an instruction, a photo set, a delivery note for materials issued to that job. They are not a second universe. The person preparing the claim should open the project and find the evidence, not ask a supervisor to scroll a camera roll.

Approvals are acts. A variation above a figure needs a director. A claim needs the QS and then the director before it is marked submitted. A WhatsApp “ok” is not the approval unless that person also records it on the file. This is the same idea as any other approval workflow. The noun is the claim.

A progress claim is a snapshot. Once it is submitted, the lines should stay as submitted. A later correction is a new event, not an edit that rewrites history. Clients and consultants dispute memories. A stored pack with a time and a person is the argument you can still have in six months.

Certified amounts, retention, and what was received are fields your commercial team already tracks. The system can show applied versus certified versus received. It should not compute a contractual entitlement from a clause a developer guessed. If your QS has a method and will test it against old claims, a later phase can assist the arithmetic. The first release is the pack and the status.

Retention release is a date and a condition, often defects liability. The file can remind the commercial team that a date has arrived. It cannot decide that the work is defect-free. That remains a site and contract judgement. A reminder with no owner becomes noise. Name who clears it.

A subcontractor bill should name the project, the package, the amount, and whether your team has accepted it. Contra charges and back-charges need a reason. Paying a subcontractor from a personal note while the project file shows a different figure is how margins disappear. The file does not send the money. Your accounts team still pays from the bank. The file says what was approved to pay.

Material requests from site can be a simple list: item, quantity, job, date needed. Purchasing turns accepted lines into an order in whatever buying process you already have. If purchasing is already a mess across the whole company, that may be an ERP or inventory scope, not a site app. The construction file should know the request belonged to a job.

Delivery notes photographed at the gate are evidence, not stock. If you need bin locations and reorder points, use the inventory pages. Attaching the note to the job is enough for many fit-out contractors. Pretending every screw is a warehouse will not be maintained by a supervisor at 6pm.

We will not produce structural calculations, shop drawings, or a BIM model. We will not advise whether a variation is contractually valid. We will not submit CIDB, DOSH, or local-authority forms as a managed service. A checklist of documents your contract manager already requires can live on the project. The obligation to lodge them stays with you.

We will not backdate a claim or hide a variation from a pack that was already submitted. History is the product. If a figure was wrong, the correction is visible. Teams that want a delete button for commercial history are asking for a fight with their own auditor later.

Safety incidents can be recorded as a site note if you want a place to put them. A full safety-management certification programme is a different system and often a different specialist. We will not market a note field as a safety certification.

Bring one completed claim pack, one variation that changed the sum, and the subcontractor bill that sat beside them. Bring the WhatsApp thread only if you are willing to show how instructions actually arrive. The audit is the gap between those artefacts and a single project.

Name an owner. Usually that is the quantity surveyor or the contracts manager, with project managers feeding status and directors approving above a limit. If nobody owns the claim calendar, software will not invent the discipline. Also decide the words: draft, submitted, certified, paid, disputed. Fuzzy words become a fuzzy report.

Then read the construction management software page for modules and the RM20,000–RM55,000 band. If your brief still says “like Procore, but for everything, by next month,” rewrite it. A buildable sentence is: one project type, claims, variations, and subcontractor bills, with the QS’s figures stored as entered.

Once a handful of jobs can show applied, certified, and received without a rebuilt workbook, the next requests are predictable. A client portal for pack download. A cost code that matches the accountant. A photo standard the supervisors will follow. Each is a phase. A portal before the pack is stable just publishes confusion faster.

Groups with a separate trading arm should not force supplier invoices and project claims into one screen on day one. Trading pages on this site describe distribution. Construction pages describe the job. They can share a supplier later. They should not share a first scope.

Staff on site change often. The supervisor’s action should be short: upload the instruction, confirm the material request, look at this week’s tasks. The QS’s screen can be longer. Designing both for the director’s dashboard first is why site staff keep using chat.