The right way to scope a first app with an app developer Malaysia in late 2024 is to assume MyInvois integration from day one, design your data model around the LHDN JSON schema, and budget for digital signing and an IRBM sandbox cycle before you write a line of UI code. Phase 1 of e-Invoice went live on 1 August 2024 for companies with turnover above RM100 million, and Phase 2 (RM25M to RM100M) follows on 1 January 2025 — so the SMEs commissioning new apps this quarter are building directly into an already-live tax infrastructure.
Advisory Apps has been an app developer in Kuala Lumpur for 12 years. Across 200+ projects and 80+ shipped mobile apps, we have watched a clear pattern emerge since August: clients who bolted e-Invoice on as an afterthought are paying twice. Here is how to scope it correctly the first time.
Why does e-Invoice change how you scope a new app?
Because invoicing is no longer a private matter between you and your customer. Every valid invoice now needs to be submitted to MyInvois, validated by IRBM, assigned a Unique Identifier Number, embedded as a QR code, and then issued to the buyer — all before you can legally treat it as a tax invoice. That flow has hard implications for any app that touches billing:
- Data model. Every invoice record needs fields for IRBM UIN, validation status, submission timestamp, and error reasons if rejected.
- State machine. Invoices now have states:
draft,submitted,validated,rejected,cancelled. Your app has to model all of them. - Failure handling. IRBM rejects invoices. Your app must show the user why and allow correction without losing the original draft.
- Offline tolerance. Rural branches and spotty 4G still exist. Your app cannot assume MyInvois is reachable the moment the user hits Save.
Trying to add these after the fact is roughly three times the work of baking them in at kickoff.
What does the MyInvois integration actually look like?
LHDN’s MyInvois API accepts JSON or XML over HTTPS, requires OAuth2 client credentials, and mandates digital signing using a certificate issued by a licensed Malaysian Certification Authority. The high-level flow for a submitted invoice:
- Authenticate. Obtain a short-lived access token via client credentials.
- Construct the document. Build a UBL 2.1-compliant JSON payload with supplier, buyer, line items, tax breakdown, and totals.
- Digitally sign. Apply an XAdES-equivalent signature using your CA-issued certificate.
- Submit. POST to the MyInvois submission endpoint. Receive a submission UUID.
- Poll or webhook for status. Validated, invalid, or rejected. Store the UIN on success.
- Present. Render the validated invoice with the IRBM QR code to the buyer.
The sandbox environment is essential. Expect to spend at least two sprints cycling through test payloads before you hit a clean submission rate. A good system integration engineer will have already done this for other clients and will save you weeks.
How should SMEs scope the app itself?
Separate the concerns. In our experience, a solid first-app scope for an SME entering the e-Invoice era looks like this:
| Layer | Responsibility |
|---|---|
| Mobile UI (Flutter 3) | Capture orders, issue receipts, show invoice status |
| Backend API | Business logic, user management, invoice state machine |
| MyInvois integration service | Signing, submission, polling, retry, error normalisation |
| Accounting connector | Sync validated invoices into SQL / AutoCount / Xero |
| Reporting dashboard | Daily submitted, rejected, outstanding volumes |
Scoping in layers gives you something else valuable: you can swap the UI in future without touching the MyInvois code, and vice versa. When LHDN issues a schema update — and they will — you only change the integration service.
A typical timeline for this shape of app is 4 to 6 months for the MVP, with a further 4 to 8 weeks of hypercare after go-live. Budgets vary with complexity, but a realistic range is RM180,000 to RM420,000 for an SME-scale build. Lighter scopes exist — see our mobile app development page — but anything touching e-Invoice has an irreducible floor of integration work that cannot be wished away.
What tooling is the team actually using in 2024?
A snapshot of what our engineers are using right now:
- Flutter 3 for cross-platform mobile. One codebase, iOS and Android, native-quality animations.
- Node.js and .NET on the backend, depending on the existing client stack.
- Claude 3 and GPT-4o for code review, boilerplate generation, and documentation drafting. Neither touches production customer data — the governance matters.
- GitHub Actions for CI and automated deployment to staging and production.
- Sentry and Firebase Crashlytics for post-launch monitoring.
The AI tools are genuinely making small teams more productive. They are not replacing the human judgement calls — architecture, data modelling, integration strategy — and they are not a substitute for someone who has already been through an IRBM sandbox cycle and knows where it hurts.
What should you ask an app developer Malaysia right now?
Before you sign anything in September 2024, ask:
- Have you shipped a MyInvois-integrated app to production? Can we see it?
- How do you handle IRBM rejections and partial submissions?
- Where do digital signing certificates live, and who manages key rotation?
- What is your approach to offline invoice creation and late submission?
- What is included in post-launch support when LHDN changes the schema?
A vendor who cannot answer these clearly in September 2024 should not be the one building your first e-Invoice app.
Talk to Us
If you are an SME scoping your first app and trying to get MyInvois integration right the first time, we would rather help you plan properly than fix it later. We have been an app developer Malaysia since 2012, we have shipped 80+ mobile apps, and we have live MyInvois integrations running for Phase 1 clients today. Book a free consultation and we will walk through your specific scope before you commit to a spec.
