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.