21/7/2026

Bug-Fixes

#1 Resolved an issue where non-consolidated invoices were incorrectly tagged as "Consolidated" by strictly verifying invoice types during API auto-conversion.

1. Overview

Resolved an issue where standard, non-consolidated invoices were incorrectly labeled with a "Consolidated" tag in the UI when workspace auto-convert settings were enabled.

2. What Has Changed

Previous:

When a workspace enabled the "Auto Convert New Consolidated Invoices" setting (e.g., for API integrations), the system universally applied the conversion flag to all incoming invoices.
Because of this broad application, standard non-consolidated invoices were incorrectly tagged and displayed as "Consolidated" in the invoice list.

Now:

The API submission logic has been enhanced to strictly verify the actual invoice type before applying the auto-convert action.
The system now successfully differentiates between the types, ensuring the "Consolidated" tag is exclusively applied to legitimate consolidated invoices.
Non-consolidated invoices remain properly untagged.

3. Impact

Data Accuracy: Ensures that UI tags accurately reflect the true nature of the invoice.
Reduced Confusion: Prevents users from mistakenly believing standard sales invoices were generated through the consolidation process.
Reliable Reporting: Restores the accuracy of workspace filters, sorting, and reports that rely on precise invoice-type data.

#2 Resolved an issue where converted invoices automatically submitted to LHDN by ensuring they remain as drafts until you are ready.

1. Overview

Resolved an issue where invalid non-consolidated invoices that were converted into consolidated invoices were incorrectly auto-submitting and validating individually, rather than remaining as drafts for bulk processing.

2. What Has Changed

Previous:

When a user converted an invalid non-consolidated invoice (e.g., due to an invalid Buyer TIN) into a consolidated invoice, the background submission process did not properly halt.
Once the rate limiter allowed the submission to proceed, the system would automatically submit the individual invoice to LHDN using "General Public" buyer info.
This caused the individual child invoice to bypass the bulk consolidation process and appear as "Valid" under the Consolidated tab.

Now:

When an invalid non-consolidated invoice is converted, it is correctly routed to the Consolidated > Unprocessed tab and strictly held in a Draft status.
The buyer information is updated to General Public, but any subsequent edits to the invoice will only overwrite the local data without triggering an unintended submission to LHDN.
The invoice safely remains in the unprocessed queue until the user intentionally includes it in a bulk consolidation action.

3. Impact

Workflow Integrity: Ensures converted invoices properly halt their individual submission lifecycle and strictly follow the consolidation workflow.
Data Accuracy: Prevents individual child invoices from erroneously validating on their own and cluttering the Consolidated Valid tab.
User Control: Allows users to safely edit and prepare converted drafts without the risk of accidentally triggering premature LHDN submissions.

#3 Fixed an issue where stuck submissions blocked invoice numbers, allowing you to easily resubmit them without errors.

1. Overview

Resolved an issue in the API ingestion pipeline where invoices stuck in a "pending" state permanently blocked users from resubmitting the same invoice number via the API.

2. What Has Changed

Previous:

If an API invoice submission failed to process correctly due to a system delay, it could become permanently stuck in a "pending" state.
The system’s automated cleanup process only checked for and recovered invoices stuck in "processing," ignoring those that were "pending."
Because the system treated these stuck pending invoices as active submissions, users were blocked from resubmitting the same invoice number for up to 30 days.

Now:

The automated cleanup process has been updated to monitor for both "processing" and "pending" statuses.
If a pending API submission sits inactive for longer than 10 minutes, the system automatically marks the attempt as "failed."
This immediately frees up the invoice number, allowing the user to successfully resubmit the invoice via the API without needing manual intervention from support.
Note: This issue only affected API submissions; manual portal submissions were not impacted.

3. Impact

System Resilience: Ensures temporary processing delays do not create permanent blockers for users.
Automated Recovery: Eliminates the need for manual support interventions to free up stuck invoice numbers.
Seamless Resubmission: Allows users to easily retry failed API submissions without encountering false "Invoice is already being processed" errors.

#4 Fix for Outdated Data During Invoice Resubmission

1. Overview

Resolved a data-persistence issue where resubmitting a previously invalid invoice via SFTP/Upload incorrectly reused the original, cached payload data instead of capturing the new, updated data from the source file.

2. What Has Changed

Previous:

When a user uploaded a file (e.g., via SFTP) and the invoice hit an "invalid" status with LHDN due to incorrect data (like a wrong classification code).
If the user corrected the data in the source file and re-uploaded the exact same invoice number, the system occasionally failed to clear the cached transaction data.
Instead of parsing and sending the newly corrected data to LHDN, the system would silently reuse the old, invalid data from the first attempt, causing a continuous loop of rejections.

Now:

The system now enforces a strict overwrite protocol during resubmission.
Whenever an invoice number is resubmitted across any channel (SFTP, Direct Upload, API, or Manual Create), the system correctly clears the unused/cached data from previous failed attempts.
The payload sent to LHDN strictly uses the latest buyer details and transactional data provided in the most recent source file.

3. Impact

Data Integrity: Ensures that LHDN always receives the exact, updated information the user intended to send during a retry.
Workflow Efficiency: Eliminates the confusing "rejection loop" where a user has fixed their file but the system keeps sending old data, drastically reducing support tickets for "stuck" invoices.
Global Reliability: This fix is applied consistently across all modules (Sales and Self-Billed) and all submission channels.

#5 Prevent Buyer Data Loss in Child Invoices After Consolidation Cancellation

1. Overview

Resolved a critical data loss issue where child invoices within a consolidated batch were losing their buyer information if the parent consolidated invoice was cancelled or edited after an invalid submission.

2. What Has Changed

Previous:

When a consolidated invoice was marked invalid, edited, saved as a draft, and subsequently cancelled, the associated child invoices reverted to a Draft status.
During this reversion process, the system incorrectly stripped out the buyer ID from the child invoices.
If a user attempted to re-consolidate, or if an API resubmission occurred for these hidden-status invoices, the system generated a payload missing crucial buyer data, leading to an automatic LHDN validation failure.

Now:

The system's cancellation and API resubmission logic for the new API structure has been updated to mirror the protections previously deployed for the old API structure.
The duplicate error path check now properly guards all hidden child invoices.
When a consolidated parent invoice is cancelled, the child invoices safely revert to their unprocessed state while fully retaining their original buyer information and relational database data.

3. Impact

Data Preservation: Ensures child invoices never lose their core buyer information during complex cancellation or draft-reversion workflows.
Workflow Recovery: Allows users to successfully re-consolidate and resubmit previously cancelled batches without encountering missing buyer data errors from LHDN.
API Stability: Prevents API payloads from being corrupted when interacting with child invoices that have transitioned through hidden or draft states.

#6 Fix for Validated Invoices Incorrectly Displaying as Invalid

1. Overview

Resolved a synchronization issue where invoices successfully validated by LHDN were incorrectly retaining an "Invalid" status in the system, leading to duplicate submission errors when users attempted to resubmit them.

2. What Has Changed

Previous:

When an invoice was submitted and validated by LHDN, the system sometimes failed to reflect the Valid status.
If a user attempted to resubmit the invoice, LHDN would reject it with a duplicate UUID error.
The system would incorrectly update the local record with the new rejected UUID while keeping the status as Invalid, creating a continuous loop of failed resubmissions despite the invoice already being valid on LHDN's side.

Now:

The system properly synchronizes the latest status and valid UUID directly from LHDN.
If an invoice is confirmed as already validated by LHDN, the system automatically blocks any further attempts to resubmit it.
If an invoice is currently in a Queue or active processing state, the system correctly ignores duplicate submission triggers instead of overwriting the active process.

3. Impact

Data Synchronization: Ensures the system's invoice status and UUID perfectly match LHDN's records, eliminating false Invalid statuses.
Error Prevention: Prevents users from accidentally spamming resubmissions for invoices that are already valid or actively processing, completely resolving the duplicate UUID error loop.
System-Wide Reliability: This fix applies globally across all environments (SME, Prod, UAT), submission channels (Create, SFTP, API, Direct Upload), and modules (Sales, Self-Billed).

#7 Optimized UAT submission queue processing to automatically skip stuck invoices and prevent processing bottlenecks.

1. Overview
Improved the submission queue processing in the UAT environment to prevent invoices that are stuck at the intermediary stage from blocking subsequent invoice submissions.

2. What Has Changed
Previous:
An invoice stuck at the intermediary stage would stop the submission queue.
Remaining invoices could not be processed until the blocked invoice was resolved.

Now:
During queue processing, invoices with an intermediary-stuck status are automatically skipped.
The queue continues processing the remaining invoices without interruption.
Basic logs are generated for skipped invoices to support troubleshooting.
This enhancement is applied to UAT only and does not affect Production.

3. Impact
Prevents submission queue bottlenecks in UAT.
Improves testing efficiency by allowing other invoices to continue processing.
Makes it easier to identify skipped invoices through system logs.
No impact on Production behaviour.

What’s New

#1 Enhanced API invoice submissions to support multiple CC email recipients, automating notifications for secondary stakeholders.

1. Overview

Enhanced the API invoice submission capability to allow multiple "CC" email recipients for buyers and suppliers, aligning API functionality with the existing web portal's email notification feature.

2. What Has Changed

Previous:

The API structure only accepted a single, primary email address for the buyer and supplier when submitting invoices.
Integrations could not automatically send e-invoice notifications to additional email addresses without manual intervention in the portal.

Now:

The API now allows users to include a list of "CC" email addresses for buyers and suppliers during invoice submission.
These CC addresses are automatically saved to the customer's or supplier's profile as secondary email recipients.
Once the invoice is validated, notifications are delivered to both the primary email and all specified CC addresses.
The system automatically ignores invalid or duplicate emails and safely preserves any existing CC addresses already set up in the portal.

3. Impact

Enhanced Automation: Allows clients to fully automate notifications to multiple stakeholders directly through their system integrations.
Feature Consistency: Aligns API capabilities with the existing web portal features.
Data Preservation: Ensures that automated API updates do not overwrite or delete existing CC emails manually configured in the portal.