Document Lifecycle
AECloud records several stages between document preparation and the final business outcome. Not every source uses every stage, and the exact available action depends on the document family, submission mode, current status, and user authorization.
Conceptual lifecycle
Self-Service only: Draft or Imported
|
v
Accepted and stored in AECloud
|
+--------+---------+
| |
v v
Non E-Invoice Pending Submission
|
v
Preparing / Uploaded / Submitted
|
v
InProgress
|
+----------+----------+
| |
v v
Valid Invalid / Error
|
v
Eligible cancellation -> Cancelled
Eligible record before active LHDN processing -> Voided
This diagram is conceptual. Do not force a document through an action solely to make it match the diagram; use the actions available for its actual recorded state.
Preparation states
Draft or imported
These states belong to Self-Service preparation. The merchant can complete or correct the document while the corresponding action remains available. A draft has not yet become a validated e-Invoice.
Integrated documents do not normally begin as Self-Service drafts. The connected system is their preparation source.
Accepted and stored
AECloud has passed the initial request checks sufficiently to record the business document. This confirms neither external submission nor final LHDN validation.
The integration or user should retain the document number, AECloud sale GUID where available, source identifiers, request time, and initial response.
Processing states
| Displayed status | Meaning and required response |
|---|---|
| Pending Submission | Stored for later processing. Wait for the applicable schedule and monitor status. |
| Preparing | AECloud is preparing the e-Invoice representation. Do not resubmit. |
| Uploaded or Submitted | The document has entered the submission path, but final validation is not established. Continue monitoring. |
| InProgress | Processing is active. Do not resubmit or attempt a void. |
| Valid | Final validation succeeded. Preserve the LHDN identifiers and reconcile the business document. |
| Invalid | Validation did not succeed. Review the validation detail and correct the authoritative source before a controlled resubmission. |
| Error | Processing encountered an error. Classify the failure and check current status before deciding whether a retry is safe. |
| Non E-Invoice | The record was stored with LHDN submission disabled. |
| Voided | The AECloud business record was stopped before eligible LHDN completion and will not proceed through the normal submission path. |
| Cancelled | Cancellation of a previously submitted eligible e-Invoice is recorded as completed. |
Some lists or responses can show additional intermediate text. Use the complete message and identifiers shown for the specific document rather than mapping an unfamiliar value to a final result without evidence.
Initial response versus final result
Keep these outcomes separate:
- Request transport result — whether the HTTP request reached the service.
- AECloud business response — whether initial validation and storage succeeded or failed.
- Submission result — whether the document entered MyInvois processing and received submission identifiers.
- Document validation result — whether the submitted document ultimately became valid or invalid.
A reliable integration evaluates both the HTTP result and response body, stores identifiers, and reconciles later status. A merchant user performs the equivalent review in the LHDN Submission workspace.
Void, cancellation, and adjustment
- Void stops an eligible AECloud record before it becomes valid or enters active LHDN processing. A successful void locks the record against normal submission.
- Cancellation applies to an eligible previously submitted e-Invoice. The permitted period and external rules are determined by current MyInvois requirements. Consolidated e-Invoices cannot be cancelled through the current integration cancellation endpoints.
- Credit note, debit note, or refund note records a business adjustment using the appropriate document family and original-invoice reference.
Do not automatically substitute one operation for another. Their accounting and regulatory effects differ.
Correction ownership
- Correct an integrated document in its downstream source system unless an explicitly authorized operational screen permits the change.
- Correct a Self-Service draft or its master data while editing remains available.
- Ask the merchant to correct an incorrect receipt transaction; customer-entered information should cover buyer details, not rewrite the merchant's sale.
- Correct invalid data before resubmission. Repeating an unchanged request can create confusion and does not resolve a validation failure.
For endpoint-specific retry, reconciliation, void, and cancellation rules, see the API Integration Developer Guide. For console actions, see the matching chapter in the Merchant Console User Guide.