One validation, one immutable record
Once MyInvois validates an e-Invoice and assigns it an IRBM Unique Identifier Number, the document becomes part of the formal record HASiL holds. HASiL's e-Invoice guideline allows the supplier to cancel the document, or the buyer to request its rejection, only within 72 hours of that validation timestamp. After the window closes, neither party can cancel or reject the original document through MyInvois: any later correction has to be issued as a new, separately validated e-Invoice, in the form of a credit note, debit note or refund note, referencing the original document's Unique Identifier Number under what HASiL calls the Original e-Invoice Reference Number, sometimes shown as the Preceding Invoice Reference.
This article maps those three correction types onto the document types SCSB actually configures inside Dynamics 365 Business Central, and sets out where the mapping is straightforward and where it needs a deliberate design decision.
The referencing requirement is not optional or free-text: the correction document has to carry the original invoice's actual validated identifier, not a description, a manual note or an internal Business Central invoice number. A correction that omits it, or references the wrong original document, does not properly link back to the transaction it is meant to adjust.
What the three correction types actually mean
HASiL's guideline distinguishes the three by direction and by whether money physically moves. A debit note increases the amount payable on a previously validated e-Invoice, additional charges discovered after the original was issued. A credit note decreases the value of a previously validated e-Invoice without a return of money to the buyer, a price adjustment or an agreed discount applied after the fact. A refund note also decreases the value, but specifically where money is actually returned to the buyer. Taxpayers may also issue a single credit note, debit note or refund note that adjusts more than one original e-Invoice, provided each is properly referenced.
The direction test matters because it decides which document type has to be prepared, and preparing the wrong one, a credit note where a debit note was needed, does not simply understate or overstate an amount; it submits the wrong instrument for what actually happened to the transaction.
The half that already fits: decreases
Business Central's document model already has a natural home for two of the three correction types. A posted sales invoice can be corrected or cancelled directly, with a corrective sales credit memo created automatically, only where the invoice is unpaid and not fully shipped. Once it has been paid, or shipped in full, Microsoft's own documentation is explicit that the only route is a manually created sales credit memo applied against the original invoice. That posted sales credit memo maps directly onto HASiL's credit note: a decrease in value, evidenced by a document that already exists in Business Central's standard sales cycle.
Where the decrease also involves money actually going back to the buyer, rather than simply reducing what they owe, Business Central's mechanism is to post the sales credit memo and then create a payment journal entry with a Refund document type, applied against that credit memo, so the customer ledger and the bank or cash account both reflect the money leaving the business. That combination, a posted sales credit memo plus an issued refund, is the natural Business Central equivalent of HASiL's refund note. The distinction that matters for MyInvois submission is exactly the one Business Central already models internally: was the customer's balance reduced, or was cash actually paid out.
The half that doesn't: increases
Business Central has no native sales debit memo. Its standard sales document types are Sales Quote, Sales Order, Sales Invoice, Sales Credit Memo and Sales Return Order; there is no equivalent document for billing an additional amount against an invoice that has already been posted. The established practice for recording an upward correction inside Business Central is to post a new, additional sales invoice for the extra amount, because the standard sales cycle has no other document built for that purpose.
That gap does not exist on every Microsoft platform: Business Central's India localisation reports debit notes as a distinct category to India's GSTR-1 return, showing that Microsoft models the concept where a market's tax authority requires it. Malaysia is not one of those markets, so the standard Business Central sales cycle available to a Malaysian implementation carries no comparable field.
The reconciliation consequence
This is where a debit-note correction can quietly go wrong. MyInvois expects a debit note: a distinct document type, referencing the original invoice's Unique Identifier Number, representing one commercial adjustment. Business Central, left to its standard behaviour, records the increase as a second, independent sales invoice, with no field that ties it back to the original posted invoice the way a sales credit memo is naturally understood as reversing one.
Two things can go wrong if that gap is not designed around. First, if the e-Invoice submission step defaults to treating the new sales invoice as an ordinary invoice submission rather than deliberately selecting the debit note document type and populating the Preceding Invoice Reference, the submission fails to carry the required linkage back to the original transaction. Second, even where the submission is correctly tagged as a debit note at the point of transmission, Business Central's own ledger still shows two unrelated posted sales invoices unless something in the configuration explicitly records that the second one is an adjustment to the first. A reconciliation that reads one debit note on the MyInvois side has to map to one additional sales invoice, linked to a specific original invoice number, on the Business Central side, and that link has to be built deliberately, for example as a field or dimension on the sales invoice recording the original invoice number, rather than left to a free-text description or a preparer's memory.
Multiple original invoices, one correction document
HASiL's guideline also permits a single credit note, debit note or refund note to adjust several original e-Invoices at once, provided each is properly referenced. Business Central's own credit memo application logic is built around applying one credit memo to one posted invoice through the Applies-to Doc. No. field. Where an organisation actually needs a many-to-one correction, covering several original invoices in a single adjustment, that pattern needs deliberate design against Business Central's application model rather than an assumption that the standard one-to-one credit memo behaviour will simply extend to cover it.
Reconciliation: proving the correction population matches
A defensible correction workflow reconciles two populations for any given period: the credit notes, debit notes and refund notes actually submitted to and validated by MyInvois, and the corresponding sales credit memos, additional sales invoices and issued refunds posted inside Business Central. Every MyInvois correction document should trace to a specific Business Central posting, and every Business Central correction that was meant to reach MyInvois should appear there, referencing the correct original invoice. A correction recorded in one system but not the other is the point at which a ledger and a regulator's record start to disagree with each other.
Decisions to settle before configuration starts
- How a debit-note increase is recorded inside Business Central, and how that record is linked back to the original posted invoice it adjusts.
- Which combination of a posted sales credit memo and an issued refund represents a HASiL credit note versus a refund note, and how that distinction is captured at the point of correction.
- How the Preceding Invoice Reference is populated for every correction document, so it always carries the original invoice's actual Unique Identifier Number.
- Whether the organisation ever needs one correction document to cover several original invoices, and how that is handled against Business Central's one-to-one credit memo application model.
- What standing reconciliation ties every MyInvois correction document back to its Business Central posting, and flags anything recorded in one system but not the other.
An organisation that rarely corrects a posted invoice upward, issues few refunds, and can trace each correction back to its original invoice without difficulty, may be able to manage this directly from HASiL's guideline and Business Central's standard sales cycle. The case for outside implementation support grows with correction volume, multiple entities or systems feeding the same MyInvois submission, or a pattern of upward corrections that has so far been handled as an ad hoc new invoice with no documented link back to the original.
What to do next
Confirm the current correction rules, referencing requirements and any timing conditions directly against HASiL's e-Invoice guidelines before relying on this article or any other secondary summary. Where the organisation has confirmed it needs credit note, debit note or refund note handling configured inside Dynamics 365 Business Central, the SAC E-Invoice App can be discussed within an agreed implementation scope.
General-information limitation
This article is general technical information about correcting validated e-Invoices and mapping HASiL's credit note, debit note and refund note concepts onto Dynamics 365 Business Central's document types. It is not tax, legal or accounting advice, does not determine any organisation's correction obligations, and does not confirm that a particular configuration meets HASiL's current requirements. HASiL's guidelines, MyInvois platform behaviour and Business Central's own functionality are set by their respective publishers and change over time. Confirm the current position against HASiL's published material and Microsoft's current Business Central documentation before implementation.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.