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 explains the design questions when mapping those three correction types to Dynamics 365 Business Central postings. The installed app’s mapping must be demonstrated in the target environment; a familiar accounting document does not prove the MyInvois document type selected by a connector.
For an adjustment to a previously validated e-Invoice, preserve its validated identifier and internal document number. The MyInvois Debit Note v1.1 specification describes both reference values where applicable. A free-text description is not a substitute for the required structured references. Check the current document specification and any applicable exceptions for the actual correction.
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. After a posted invoice is partly or fully paid, Microsoft requires a manually created sales credit memo to reverse it, optionally using a sales return order. For other cases outside direct correction or cancellation, check the documented corrective-credit-memo route. A posted sales credit memo can provide the accounting record for a decrease. The chosen MyInvois correction type and original-document references still need to be mapped and tested separately.
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. Use the approved adjustment and refund facts to select the MyInvois document type. Test how the app links the credit memo, any cash refund and the original e-Invoice.
Design upward corrections explicitly
An increase to an earlier validated invoice needs an agreed accounting record and the appropriate MyInvois correction type. One possible Business Central design records the extra charge as an additional sales invoice, then maps the submission to a debit note with the required original-document references. Treat that as a design to verify, not a universal description of every localisation or installed app.
Check which pages, fields, document types and posting routines the organisation’s version and extensions provide. Do not infer a missing capability across all Malaysian implementations from the standard sales-document list. The test is whether the actual configuration records the approved adjustment, transmits the intended MyInvois document type and retains the link back to the original.
The reconciliation consequence
Keep the accounting posting and the MyInvois correction linked through identifiers that a reviewer can follow. For an upward adjustment, record the original posted invoice, its validated identifier, the additional accounting document, the outgoing correction type and the validated correction identifier. If a correction covers several originals, retain each applicable reference and reconcile the total to the related ledger applications.
A user entering “debit note” in a description does not establish the submitted type or reference mapping. Inspect the actual output and submission outcome in a controlled test. Where a field, extension or report is needed, include it expressly in the agreed design.
Multiple original invoices, one correction document
A correction covering multiple original e-Invoices needs the applicable MyInvois references and a reconciliation to the underlying Business Central entries. Business Central is not limited to one-to-one credit memo application: Microsoft documents applying a sales credit memo to multiple customer ledger entries using Apply Entries and Set Applies-to ID. Ledger application and e-Invoice reference mapping are separate controls; test both against the intended adjustment.
Reconcile correction documents and postings
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.
One illustrative correction acceptance test
For a customer credit, begin with an approved adjustment to a previously validated invoice. Record the original Business Central number and MyInvois identifier, expected adjustment amount and currency, whether money will be returned, and the approved correction type. After the test, compare the posted ledger entries, original-document references, outgoing payload, validation outcome and any cash entry. Have the process owner confirm that the observed result matches the approved treatment.
Repeat for an upward adjustment, a refund and a multi-invoice correction if those occur in the organisation. Record the app version and test evidence. These are proposed acceptance cases, not a claim that the SAC app has already passed them in every environment.
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 one correction document needs to cover several original invoices, and how its MyInvois references reconcile to the relevant Business Central ledger applications.
- 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.