When a mandate is coming, the instinct is to treat it as a compliance task and buy the cheapest thing that satisfies it. That instinct produces a business case built almost entirely on financials, and financial-only cases have a poor record in front of executive committees.
The failure mode is predictable. A high-level case carries unvalidated ROI claims, which produces low executive confidence and a low chance of approval. Worse is when it is approved: software gets implemented, processes do not actually change, and the promised return never appears. The case that was easiest to write becomes the project that is hardest to defend a year later.
What a case has to establish
Three things, before it discusses money at all:
- Trust. Well enough researched that both you and the executives believe you know the subject.
- Honesty. An honest assessment of what will speed the project up and what will slow it down, with the financial and delivery assumptions stated rather than buried.
- Governance. A clear path with monitoring and evaluation points, transformation metrics, and the corrective action available when a metric moves the wrong way.
Four sections that earn approval
1. A change management assessment
Start with the people, not the platform. What supports this project and what obstructs it:
- The current culture and value system
- Capacity for change — how much change is already underway or planned
- Leadership styles and where power actually sits
- How previous changes landed, and how they are remembered
- Middle management's attitude, since they drive end-user adoption more than anyone
- Employee readiness, and the executive sponsorship the change will need
2. Alignment to strategic goals
There has to be a clear line from a named strategic goal to e-invoicing, and "it aligns with our digital transformation goal because it is a digital project" is not that line.
Read the corporate and departmental strategic plans; if none exist, meet the executive team and find out what the priorities actually are. Identify the specific outcomes of e-invoicing that support them, and align your success metrics and timelines to the corporate plan's. Test the findings with a couple of stakeholders before you write them up — it sharpens the argument, and it plants the project with the people who will be asked about it.
3. Risk, including the two everyone skips
Three categories, each with likelihood, impact, rating and mitigation:
- Project risk — what could go wrong in implementation
- Risk of inaction — what happens if you do nothing
- ROI risk — what stops the expected return arriving
The last two are the ones that get left out, and they are the ones executives probe. Risk of inaction is not only the compliance exposure: it is the fraudulent invoice you pay because nothing checks, the duplicate you pay twice, and the tax position you cannot evidence. Those are live costs today, not hypotheticals that begin on a mandate date.
4. Financials, built bottom-up
Financials matter. They are the fourth section rather than the whole document because a number without the three sections above it is a number nobody trusts.
Build the as-is cost honestly, from what processing an invoice actually costs you today, and the to-be from what it will cost once the process has changed — not from a vendor's benchmark. A case that shows its working survives questioning. One that arrives at a round percentage does not.
The test
Before you submit it, ask whether a sceptical executive could take any single claim in it and trace it back to something concrete. If most claims pass that test, the case will probably be approved and the project will probably deliver. If most do not, you have written a document that is asking to be believed rather than one that has earned it.
Malaysia's current phases and thresholds → · Talk to us about scoping one →