An ERP knows invoices; it does not know that zone B4 is stuck in coating behind a drawing revision. Muthari OS knows exactly that — and does not do your accounting, payroll or tax. They are different jobs, and pretending otherwise is how contractors end up with an expensive system nobody on the factory floor opens.
General ledger, payables and receivables, payroll, tax and statutory compliance. If you have one, keep it — Muthari does not touch its ground.
The operational truth per project: submittal register, PO approvals and goods receipts, batch stock with QC, fabrication stages, delivery notes and QR tracking, installation records, inspections and rework, budgets, variations and progress claims — with enforced stage gates and an audit trail written as it happens.
Today the boundary is a clean export from Muthari’s side — registers to Excel, and a full-workspace export any administrator can run. There is no automatic ERP integration yet, and we will not pretend there is. If day-one ERP integration is a hard requirement, we are not your vendor yet.
An ERP is the only correct place for the general ledger, payables and receivables, payroll, tax and statutory filing, consolidated reporting across companies, and supplier payment. It is auditable in a way a project system is not required to be, and your auditors and your bank already speak its language. Nothing here suggests replacing it.
Most construction ERPs do ship a projects or manufacturing module, and contractors reasonably ask why that is not enough. Three reasons recur, and none of them is that the software is bad.
An ERP models work as something that consumes budget in an accounting period. A fabricator’s work is a zone that moves through named stages against a drawing revision. You can force zones into cost codes, but the thing you most need to ask — which zones are held behind an unapproved drawing — is not a question the data shape supports.
The screens assume a trained user at a desk with time. The people who create operational truth are a storekeeper with a delivery driver waiting, a supervisor on a factory floor and an engineer on a scaffold. If the screen is not usable in those three places, the record is made on paper and typed in later — and once that happens the system is a reporting tool again.
Per-seat pricing makes it rational to keep storekeepers and site engineers off the system. That is precisely the wrong economy: they are the people whose records make every downstream number true.
Take a purchase order for 500 profiles. To the ERP that is a financial commitment, and a goods receipt is the event that lets an invoice be matched and paid — three hundred received, book it. To the operation, that same receipt has to do four more things: raise stock as a batch carrying the supplier’s batch reference, leave 200 outstanding on the order, put the material in front of quality control before anyone can issue it, and allow that batch to be quarantined, split or returned with the balance reopening if it goes back. Both systems are recording the same delivery. Only one of them is answering “can the factory use this yet?”
If your finance function is the bottleneck — statutory compliance, payroll at scale, an audit you are behind on — fix that first and do not let anything distract from it. If your losses are between the factory and the site, and the recurring question in your office is “where is it?”, the operational layer is where the money is.
Today the two are connected by export rather than by integration: registers to Excel, and a full-workspace export any administrator can run. There is no automatic ERP integration and no API yet, and we will not imply otherwise. If day-one two-way posting into your ERP is a hard requirement, we are not your vendor yet — and that is a straight answer rather than a roadmap promise.