Contact Info
What does a Malaysian ERP requirements specification need to include?
A Malaysian ERP specification is the signed reference that implementers price and testers verify. It holds process chapters for sales, purchasing, stock and production, acceptance lines for MyInvois submission and SST codes confirmed by your tax advisor, hosting, access control and audit-trail expectations, interfaces to payroll, banks and the e-invoicing route, migration rules and priority tags traced to test cases. I write it remotely and independently.
Last reviewed by Vikas Saroj
E-invoicing has pushed many Malaysian companies into ERP conversations sooner than planned, and the first document on the table is frequently an implementer's own quotation. Without a specification of your own, there is nothing to compare that quotation against. As an ERP requirements consultant, I produce that specification: numbered lines, an owner and priority for each, and acceptance conditions a tester can check.
I work remotely from India, with live sessions placed in the shared part of our working days and drafts reviewed online between calls. A visit to a plant or warehouse can be planned by arrangement. The engagement runs in English; Malay or Chinese wording on invoices, labels and delivery orders is drafted or reviewed by fluent colleagues of yours or by a local firm you appoint.
No platform or implementer pays me anything, so the document can go to every bidder on the same terms.
Each part below becomes a chapter or a column in the specification, so nothing important depends on someone's memory of a meeting.
Every company, plant, warehouse and branch in scope, including any East Malaysia locations or licensed warehouse sites, with the chapters that apply to each so bidders price the same footprint.
Submission, rejection handling, resubmission, cancellation approval and inbound document handling written as pass-or-fail lines, with the scope that applies to you settled by your tax advisor.
Each SST tax code in the specification points back to a row of the treatment matrix your advisor approved, so testers can prove that the configured system applies the agreed answer.
Data location questions, personal data controls, roles by company and site, approval rules for bank detail changes, audit trail, month-end performance and access for plants on unstable connections.
Lines for the e-invoicing route, payroll journals, bank files and marketplace orders, plus a migration chapter covering what leaves AutoCount, SQL Account or another package, and how it is reconciled.
A response sheet that forces each implementer to classify every line, and a clean signed version for the contract, so scope disputes are resolved against text.
Collect inputs and set structure
Make every line testable
Sign and protect the baseline
The business analysis decides how processes should run; the specification records what the system must do so that a contract can depend on it. For a Malaysian company the document I prepare usually contains:
Each line has an ID, a plain statement, an owner, a priority and room for trace links. Workshop and mapping work that feeds it is a separate service: ERP business analyst in Malaysia. For the BRD format that often precedes a specification, see ERP BRD consulting.
Because the e-invoicing rollout and SST scope have both been changing, the register holds statements your advisor has confirmed, not my interpretation of the law. My job is precise wording. Examples of the style I use:
Most of these carry a must tag. If submission is handled by middleware outside the ERP, that fact is written down and a named party is made responsible for keeping the link working.
Malaysian specifications often describe screens in detail and say little about how the system must behave. Those are the requirements that hurt most when they are discovered after signing. I write each one as a question every bidder must answer:
Each bidder's yes, no or partial answer is kept on file with its explanation.
Interfaces are written as their own lines, not buried in process text. Typical Malaysian entries cover the e-invoicing route, journals from the payroll product that handles EPF, SOCSO, EIS and PCB deductions, bank payment files and statement imports, and marketplace or webstore orders. Each line states direction, frequency, data owner and the behavior when a transfer fails.
The migration chapter states what moves from the outgoing package: masters, open receivables and payables, stock by location and batch, and how much history. It also states who signs off the reconciliation. More detail is on ERP data migration.
Priority uses four plain tags. Must means go-live cannot happen without it. Should has a short-term workaround. Could is a worthwhile improvement. Later is parked for a future phase. A must needs a written reason, which stops every department marking everything as essential.
Trace columns then connect each line to the demo script step used in selection, the implementer's response, the design document, the test case and its UAT outcome. That chain is what lets a project manager answer, months later, whether a gap was in the requirement, the proposal or the build.
In an ERP RFP, each bidder states for every line whether it is handled out of the box, by setup, by custom development, through an add-on, or not at all. Proposals that arrive framed as an e-invoicing upgrade are compared against the full specification, not only the e-invoicing lines. After the decision, the signed version and the winning response become a contract annex, and changes follow a numbered request with impact noted. The ERP selection consultant page for Malaysia covers scoring.
Gaps that weaken Malaysian specifications, and that I check for when reviewing an existing document, include:
For a wider view of my remote work here, see the Malaysia hub and the Malaysia ERP consulting page.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
If the project will touch more than e-invoicing, yes. A proposal describes what the implementer plans to deliver; a specification describes what your business needs. Placing one against the other shows what is covered, what is assumed and what is missing. If the scope truly is limited to an e-invoicing connector, a shorter specification focused on that interface may be enough.
Every SST line points to a row of the treatment matrix your advisor approved. When guidance changes, your advisor updates the matrix, and the linked requirements, tax codes and test cases can be found and revised together. I can maintain those links during the project; afterwards, ownership normally moves to your finance team.
Yes, if each line is flagged with the entities it applies to and each country has its own statutory register. Shared processes are written once, and local tax, invoicing and payroll interface lines are kept separate. Each entity's accountant confirms its own register, and bidders can quote the rollout in stages without the scope becoming unclear.
It becomes the scope baseline. Design documents reference its IDs, test cases are written against its lines and UAT sign-off is recorded per requirement. Any change goes through a request with reason, impact and approver, producing a new numbered version, so everyone always works from the current text.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.