Overview

AECloud provides a business-integration contract and centralized e-Invoice operations. It is not a generic proxy for every MyInvois endpoint. A merchant can integrate directly with MyInvois, but then the merchant or its solution provider must implement and maintain the applicable regulatory document model, authentication, submission orchestration, status handling, and lifecycle operations.

Intended audience

This guide is for developers and technical teams integrating a merchant-controlled downstream system with AECloud. Readers should be comfortable with HTTPS, OAuth2, JSON, HTTP headers, status codes, secure secret storage, and asynchronous processing.

Responsibilities

The downstream system is responsible for:

  • collecting accurate transaction, buyer, supplier, tax, and item information;
  • assigning stable document numbers and QR GUID values;
  • choosing the correct document family and submission timing;
  • sending valid JSON over HTTPS;
  • storing AECloud and LHDN identifiers returned or retrieved later;
  • polling responsibly and reconciling final status;
  • preventing duplicate business documents; and
  • protecting credentials and personal data.

AECloud is responsible for:

  • authenticating the API client;
  • validating the AECloud request structure;
  • resolving the merchant and outlet;
  • storing the uploaded document;
  • converting the business payload into the applicable e-Invoice structure;
  • submitting immediately or scheduling processing according to the requested mode;
  • recording LHDN submission results; and
  • exposing status, void, cancellation, TIN, and reference-data services.

The merchant remains responsible for accurate source transactions, classifications, party details, totals, and tax treatment. AECloud centrally maintains the supported technical conversion and MyInvois integration, reducing duplicated implementation and maintenance work in connected merchant systems.

Two processing stages

Treat upload acceptance and LHDN validation as separate outcomes.

  1. AECloud acceptance confirms that the payload passed the initial AECloud checks and was stored.
  2. LHDN processing produces submission identifiers and a document status such as Valid, Invalid, or Cancelled.

A successful upload that is scheduled for later will not yet have a submission UID or accepted UUID. Even an immediate submission can return before every downstream action is final. Always implement status reconciliation.

AECloud API versus the MyInvois API

Your system calls AECloud endpoints and sends the AECloud business JSON described in this guide. AECloud resolves the merchant and outlet, validates and enriches the supported data, converts it into the applicable regulatory representation, and communicates with MyInvois using its separate intermediary connection and the taxpayer's required permission.

By contrast, the MyInvois Submit Documents operation expects a supported UBL document represented as JSON or XML inside a documents submission wrapper, including encoded document content, a document hash, and a reference number. Do not wrap an AECloud request in that MyInvois structure and do not base64-encode the AECloud business payload.

Concern AECloud Integration API Direct MyInvois integration
Input Business-oriented AECloud JSON Supported regulatory UBL document and submission wrapper
Authentication Merchant system authenticates to AECloud Taxpayer or intermediary authenticates to MyInvois
Conversion Performed by AECloud for supported data Implemented by the direct integrator
Scheduling and consolidation Coordinated through AECloud merchant settings and requested mode Implemented and operated by the direct integrator
Operational visibility Central Merchant Console and AECloud status services Must be provided by the direct solution
Technical change management Centrally maintained in AECloud; source-contract changes are communicated when required Maintained separately by the direct integrator

Direct MyInvois integration is possible; AECloud is not legally mandatory. Use one authoritative route for each source document. Sending the same transaction through both paths can create duplicates, split operational records, and incomplete AECloud reporting. A document submitted directly to MyInvois may not automatically appear in AECloud unless a separately approved synchronization process exists.

The official MyInvois documentation remains the authority for regulatory document definitions and external validation rules. Useful references include:

For a non-technical explanation, see AECloud and MyInvois.

Current and historical documentation

The endpoint names in this guide come from the current exported service and live API catalogue. Endpoint names shown on the previous AECloud website, including paths ending in invoice_upload, invoice_cancel, or invoice_reject, are historical and must not be used for a new integration unless AECloud explicitly provisions that legacy interface.