What Happens When You Can't Connect to MyInvois? Offline E-Invoicing Explained

The reality of API availability

Any system that relies on an internet connection to a government server will experience downtime. This is not a criticism of LHDN — it is a fact of networked computing. The MyInvois API can become unavailable due to:

• Scheduled maintenance — LHDN periodically takes the system offline for updates
• Peak load — High submission volumes can cause slowdowns or timeouts, and the first seven calendar days of each month may be busier because that is the consolidated e-invoice submission deadline
• Network issues — Your internet connection, your ISP, or any point between your device and LHDN's servers can fail
• Unexpected outages — Server failures, infrastructure problems, or other unplanned incidents

For businesses that issue invoices throughout the day — restaurants, retail shops, service providers with on-site billing — even 30 minutes of downtime is a problem. You cannot tell a customer to wait while the tax system comes back online.

What LHDN expects during downtime

LHDN's guidelines acknowledge that disruptions will occur: where the system is down and you can show evidence of your compliance efforts, the Director General evaluates the case individually (General Guideline section 2.5.4). In practice:

1. Continue issuing invoices to customers — Do not stop business operations because MyInvois is unavailable
2. Keep the documents safely until you can submit — Store them in your system so nothing is lost
3. Submit once the system is available — LHDN's General FAQ (Question 143) gives suppliers 72 hours to issue the e-invoice once the system is available, and expects your system to retry automatically; if you use the portal, check it periodically
4. Mind the issuance timestamp — For ordinary submissions, the invoice specification describes IssueDate and IssueTime as the issuance date and time and requires the current UTC date and current time. Keep the actual transaction time on your receipt and in your records. Qualifying SVDP disclosures have separate historical-date rules.

The key point: you are expected to keep doing business. The relief LHDN describes concerns the timing of transmission and validation, not whether the e-invoice is required.

The problem with the MyInvois portal approach

If you use the MyInvois portal (the web-based interface) for manual submission, you have zero offline capability. When the portal is down:

• You cannot submit e-invoices
• You cannot check the status of previous submissions
• You cannot cancel or manage existing e-invoices
• You have no queue — invoices that need to be submitted simply wait until you can access the portal again and enter them manually

This is one of the strongest arguments for using a third-party e-invoicing app with offline support, rather than relying solely on the portal. The MyInvois portal versus third-party apps compares the two more broadly.

How offline queuing works, in systems that do it

This section describes the general design. It is worth understanding because it is what people usually mean when they ask whether a tool "works offline", and because the shape of it explains why the answer matters less than it sounds — the failure that actually bites is LHDN being unreachable, not you being disconnected.

A system built for offline capture works like this:

Step 1: Create the invoice normally

When you create an invoice — whether you are online or offline — such a system generates a complete e-invoice document with every required field populated, formatted in UBL 2.1. The document is stored locally on your device.

Step 2: Attempt submission

It tries to submit the e-invoice to the MyInvois API. Three outcomes are possible:

Track accepted documents using the submission UID and document UUID until their initial validation result is Valid or Invalid. A document can later have another status, such as Cancelled. Remove it from the pending workflow according to your documented status policy.

Step 3: Queue management

E-invoices in the offline queue are:

• Stored on your device — Good systems encrypt the stored data, which reduces the exposure if a device is lost, but no encryption guarantees protection against every compromised-device scenario
• Marked with a pending status — So you can see exactly which invoices have not yet been submitted to LHDN
• Ordered chronologically — First in, first out. Earlier invoices are submitted first when connectivity resumes

Step 4: Automatic retry

When connectivity is restored, such a system automatically:

1. Detects that the MyInvois API is reachable
2. Processes the offline queue in order
3. Submits each pending e-invoice
4. Updates the status of each invoice (validated, rejected with errors, etc.)
5. Notifies you of the results

Automatic retry reduces manual work, but it does not remove it: validation errors need correcting, and a document that keeps failing needs a person. A good system limits its retries and shows you which invoices are still pending.

The circuit breaker pattern

Sophisticated e-invoicing apps use a circuit breaker to handle API instability intelligently. Here is how it works:

Normal operation (circuit closed)

Every e-invoice submission goes directly to the MyInvois API. If it succeeds, great. If it fails, the failure is noted.

Detecting a problem (circuit opens)

If multiple consecutive submissions fail (for example, 3 failures in a row), the circuit breaker opens. This means:

• The app stops trying to submit to the API immediately
• New invoices go directly to the offline queue
• The app periodically sends a small test request to check if the API is back

Recovery (circuit half-open)

When a test request succeeds, the circuit enters a half-open state:

• The app tries submitting one real e-invoice
• If it succeeds, the circuit closes (back to normal) and the queue starts processing
• If it fails, the circuit stays open and waits before trying again

Why this matters

Without a circuit breaker, every invoice submission during an outage would:

1. Try to connect to the API
2. Wait for a timeout (could be 30+ seconds)
3. Fail
4. Make your app feel slow and unresponsive

A well-built client stops retrying for a while once it has seen the API fail, instead of making every subsequent action wait for a timeout — so the screen stays responsive while LHDN is down. Whether it also holds the invoice for later submission depends on the product: some keep it as a saved record in your account and leave you, or a status checker, to retry later, while others keep a local queue. Check which one your tool does.

What about the 72-hour window?

A common concern: if an e-invoice is queued offline for several hours before being submitted, does that eat into the 72-hour cancellation window?

No. The 72-hour window starts from the time of LHDN validation, not from the transaction time or the submission time. If you create an invoice at 10:00 AM, queue it offline, and it gets submitted and validated at 3:00 PM, the 72-hour window runs from 3:00 PM.

The document's IssueDate and IssueTime are separate from the cancellation window. For ordinary submissions, the invoice specification calls for the current UTC date and current time; the SDK FAQ also explains how to address an issuance timestamp rejected as too old or in the future. Preserve the actual transaction date and time in your receipt and records. Qualifying SVDP disclosures have separate historical-date rules.

Three different 72-hour limits are easy to confuse: the cancellation and rejection window (from validation), the SDK's issuance-timestamp check (before submission), and the outage relief — LHDN's FAQ gives suppliers 72 hours to issue the e-invoice once the system is available again. They are separate rules: none of them waives the others, and LHDN's FAQ does not say the outage relief relaxes the SDK's timestamp validation.

How long can invoices stay in the queue?

There is a practical limit, and it is short:

• A few hours is common during scheduled maintenance windows
• A day or more could happen during major outages or if your device is offline (e.g., working in an area with no internet)
• Beyond 72 hours, an ordinary API submission may be rejected because its issuance timestamp is too old. If an unsent document needs a lawful timestamp correction, regenerate the affected payload and submission hash; if signed content changes, regenerate the signature as applicable. Preserve the original transaction records, and check the status of any uncertain earlier submission before retrying. Being within 72 hours does not by itself satisfy all timestamp requirements, and outage relief does not automatically waive them.

LHDN's FAQ gives suppliers 72 hours once the system is available again, and its guideline evaluates genuine outages case by case where you can show your compliance efforts; it does not set a general allowance for longer delays.

Practical tips for handling outages

1. Always have an offline-capable tool

Do not rely solely on the MyInvois portal. Use an app that can create and store e-invoices and retry their submission. This is your safety net — check what your tool actually does when it cannot reach LHDN, rather than assuming.

2. Check your queue regularly

Most apps show a badge or counter for pending offline submissions. Glance at it periodically. If the number keeps growing and nothing is being submitted, investigate the connection.

3. Keep your device charged and connected

If your e-invoicing app is on a mobile device, ensure the device has enough battery and a stable internet connection (or at least periodic connectivity) to process the queue.

4. Do not duplicate submissions

If an e-invoice is in your offline queue, do not try to submit it again manually through the portal. That could report the same sale twice. LHDN's validation flags a document that matches an earlier one on type, issuance date and time, invoice number and supplier TIN within a 2-hour period (error DV302) and an identical submission within 10 minutes (DuplicateSubmission), but a re-keyed invoice with a different number or time is not caught.

5. Monitor LHDN announcements

LHDN announces some scheduled maintenance, for example in the SDK release notes. If you know the system will be down during your business hours, plan accordingly — a queue or retry mechanism will help, but it is worth setting expectations.