Date and time shown in the document are based on UTC (Coordinated Universal Time), which may differ from your local time zone.
Did this difference cause any issues during validation or when submitting the document?
Just a slight disturbance and some confusion, but not a major one, we can still cope with it.
Given Malaysia has only 1 time zone and no daylight saving (so constant time difference from UTC), is there are reason the Malaysia localisation does not use Malaysian time (hard coded difference)? Such as a requirement of the tax authority in Malasia
I’m not sure, I’m just following the official guidelines from the MyInvois SDK Portal.
Hi. May I know the status/progress for this project? is it now completed/stable. I’m personally not yet test the integration.
I’m really thankful and appreciate all of the members effort to make this project complete. Thanks a lot to @Mabaega and other contributors in this projects. You are all really great.
Thank you very much for your kind words and support 
.
The project is still ongoing — I will continue to work on it and improve step by step.
The extension is already available to try, and I encourage you to test it in your environment.
If you encounter any issues, or if you have new ideas that could make the project better, please feel free to share your feedback here. Every input will help us refine and stabilize the integration further.
It’s not complete, but it’s stable. No problems so far, except that digital signature v1.1 requires another certificate.
I’m currently developing an extension that can convert a TaxPayer QR Code into a Customer record, so that customer data in Manager will match exactly with the information registered in the MyInvois portal.
@wazhanudin kindly provided me with an example of a real TaxPayer QR Code, but since I am working only in the Sandbox environment, it looks like I cannot access the data behind it.
If anyone has experience with this, or knows how to test TaxPayer QR Codes in Sandbox, I would really appreciate your help.
Hi @Mabaega
In the LHDN mytax einvoice, there is an option whether the taxpayer can appoint intermediary or register erp.
My preference is to register My company as intermediary since I’m using manager as whitelabel to handle all my client with multiple different company database. Meaning using my company own digital cert to cover all the digital cert of other company under me as administrator. This is like other acc system provider where they guide the user to just appoint them as intermediary/erp with no requirement to add on cost for digital cert.
It looks like the requirement is there to register as intermediary and generally as long as my company registered with SSM and LHDN it is ok to register. But Please check this @Mabaega https://sdk.myinvois.hasil.gov.my/api/08-login-as-intermediary-system/ this is the guidence when login as intermediary.
My question is whether the existing system manager.io and invoisegs comply this requirement as intermediary or there is an obstacles to comply. The goal is to pool the digital cert cost under 1 intermediary for all company database.
I’m so sorry, I have no programming background. Maybe some of other administrator level of user can give feedback on this. I’m sure most of them provide same service as me.
Thanks guys
Hi @zmm, thank you for your explanation and references.
To be honest, I do not yet fully understand how the intermediary mechanism works, either technically or procedurally. I am still studying the documentation and authorization flow, especially how the digital certificate is used by the intermediary on behalf of the taxpayer.
I also do not have a clear picture because I have never seen the portal view of a taxpayer acting as an intermediary. So far, I have not found any concrete examples or specific explanations regarding intermediaries, apart from the requirement that the entity must be a Malaysian taxpayer and must hold a digital certificate issued by a registered Malaysian authority.
If anyone can provide a more detailed explanation (end-to-end flow, roles/permissions, who signs, delegation scheme, which endpoints are used, etc…), or share screenshots, sample payloads, or document links, I would be very grateful. I will continue developing this extension so that it can be used by intermediaries as well as directly by taxpayers without intermediaries—once the architecture and official requirements are clearer, both modes will be supported.
This intermediary-based e-invoicing model is not unique to Malaysia; it is also applied in other countries such as FBR (Pakistan), ZIMRA (Zimbabwe), and Egypt, where third-party or certified service providers play a similar role in transmitting invoices on behalf of taxpayers.
Thanks for your kind effort @Mabaega . I really appreciate that.
For now I will try to aply as intermediary and will get the feedback from LHDN on all aspect requirement to be intermediary. Then I will update you for clearer picture on this issue.
Hopefully it will help to fully complete this project.
Thank you so much @Mabaega and all other members for your effort.