Country
Malaysia
Article type
Platform explainer
Last checked
2026-08-30
A common integration mistake is to treat the response from Submit Documents as the end of the process. MyInvois deliberately separates initial acceptance from full validation: a successful submission returns HTTP 202 and identifiers, while the document may still be Submitted before becoming Valid or Invalid.
Platform explainer · MyInvois
MyInvois processing model
Imagine an SAP billing document has been posted and transformed into the required MyInvois JSON or XML. Before transmission, the enterprise should already know the issuing taxpayer, buyer identity, document type, tax treatment, totals and any original-document reference. MyInvois does not replace those business decisions.
Submit Documents performs structural and submitter checks. Documents that pass this initial gate receive a submission UID and document identifiers for further processing; the HTTP response is 202 because full validation is not yet complete.
The integration then uses Get Submission at a controlled polling interval. Finance should see the resulting business state—not a raw HTTP code—and the source invoice must remain linked to the MyInvois UUID, submission reference and validation evidence.
Section references: MyInvois Submit Documents API · MyInvois Get Submission API · MyInvois integration practices
Five principal processing stages
Ready to submit
Required business facts and document-version choice are complete. Missing identity, amount or original-document data blocks the flow before transmission.
Accepted for processing
MyInvois returns HTTP 202, a submission UID and initially accepted or rejected documents. This is transport progress, not final legal status.
Validation completed
Polling resolves each document to Valid or Invalid. Invalid details must be routed to the responsible team with the original platform response.
Customer and ERP aligned
A valid platform document, the customer-readable representation and the ERP document are connected. Platform validity alone does not prove customer delivery or accounting reconciliation.
Adjusted and closed
Cancellation, buyer rejection requests, credit, debit or refund notes preserve the relationship with the original invoice and reach a reconciled terminal state.
Section references: MyInvois Submit Documents API · MyInvois Get Submission API · MyInvois integration practices
Operational meaning of the principal statuses
Submitted
Full validation is still running.
Keep polling as recommended; do not issue an uncontrolled duplicate.
Valid
The document passed MyInvois validation.
Persist the identifiers and validation link, complete customer delivery and reconcile the ERP state.
Invalid
One or more validation steps failed.
Retrieve the detailed errors, correct the authoritative source or approved mapping, and decide whether a new submission is required.
Cancelled
The issuer cancelled a previously valid document through the permitted process.
Retain the cancelled document and its reason; do not overwrite the original history.
A controlled SAP/ERP-to-MyInvois architecture
The integration is complete only when business facts, submission state and financial evidence remain connected from source invoice through correction.
Authoritative invoice facts
Read approved customer, supplier, tax, amount, currency, classification and original-document references from governed SAP/ERP sources.
Deterministic transformation
Map each business scenario to one document type and version. Reject missing facts; do not silently substitute tax identifiers, classifications or references.
Submission and idempotency
Create a stable business key, prevent duplicate submission, retain the exact payload and distinguish a safe retry from a new legal document.
Status and exception workbench
Poll final status, expose validation details to an owner, control cancellation windows and prevent invalid records from being marked complete.
Reconciliation and archive
Tie the ERP document to the MyInvois UUID, status history, customer representation, credit or debit correction and period-close reconciliation.
Common control deficiencies
Using HTTP success as a finance status
It hides the period between submission and final validation and makes unresolved invoices look complete.
Retrying without checking the submission
MyInvois detects identical submissions and can return duplicate or throttling responses. Query first, then retry under an idempotent rule.
Archiving only the customer PDF
The evidence chain also needs the source facts, submitted structured document, MyInvois response, identifiers, final state and later adjustments.
Frequently asked questions
Why is HTTP 202 not the end of the process?
It confirms acceptance of the submission request for processing. Final document validity is learned from subsequent submission and document status results.
How should retries be handled?
Use the original business key and recorded platform response to decide whether to poll, retry safely or create a new correction. Blind resubmission can create duplicates.
What should SAP/ERP store?
At minimum: business identity, submitted payload reference, submission UID, document UUID where issued, validation status, timestamps, errors and correction relationship.
When can the customer document be released?
The release point should be a documented policy tied to the applicable scenario and final platform status, not merely to transport acceptance.
Integration control requirements
The integration must provide finance users with the current invoice status, the required follow-up action and a complete audit trail from ERP posting to platform result and customer document. These controls are required in addition to technical connectivity.
Official sources
Last checked: 2026-08-30