Malaysia MyInvois E-Invoicing

Malaysia's phased e-invoicing mandate changes what an invoice is. A document is no longer finished when it is posted and printed — it is finished when the Inland Revenue Board's MyInvois system has validated it, returned a unique identifier, and the buyer has received a document carrying a QR code that links back to that validation. Cancellation is possible only inside a short window measured in hours. Buyers who never asked for an invoice still have to be covered, monthly, by a consolidated submission. Purchases from suppliers who cannot issue an e-invoice have to be covered by a self-billed one issued by you.

The common workaround is to key documents into a portal or upload spreadsheets. That severs the link between the tax document and the F&O source document, which means nobody can answer the only question that matters during an audit: which posted invoice does this validated e-invoice correspond to, and can you prove it. It also does not scale past a few dozen documents a day.

This is a build-to-order extension. Nothing is pre-built and nothing installs instantly. ECOSIRE builds it against your document types, your tax setup and your legal entity structure, then installs it into your sandbox first and production second.

What ECOSIRE builds

### Master data the submission actually requires The mandate demands identifiers that a standard F&O setup does not carry. We extend the legal entity record, CustTable and VendTable with tax identification number, business registration number, SST registration number and MSIC industry code, along with any additional identifiers your document mix requires. State and country codes on LogisticsPostalAddress are mapped to the code list the tax authority expects rather than to whatever free text was typed years ago. Released products gain a classification code — and, where relevant, a tariff code — through an InventTable extension with defaulting by item group so nobody maintains thousands of items by hand. Validation runs at document level: a submission cannot leave F&O missing a mandatory field, because a rejection two hours later is far more expensive than a warning at the point of posting.

### Documents generated from the posted source, never re-keyed The document builder reads posted F&O records directly: sales order invoices and free text invoices from CustInvoiceJour, project invoices from ProjInvoiceJour, and credit notes, debit notes and refund notes mapped to their correct tax document types. Self-billed documents are generated from VendInvoiceJour for the purchase categories that require them. Each document carries line-level classification, tax type, rate and exemption reason, line and document discounts, currency with the exchange rate used, and the buyer and supplier identifiers from master data. Because generation is driven from the posted document, the tax document and the financial document can never drift apart.

### Submission, status and the cancellation window A batch service submits documents to the MyInvois interfaces — taxpayer authentication, document submission, and document status retrieval — and stores the returned unique identifier, long identifier, validation status, validation link and any rejection detail on an extension table joined to the source document. A polling batch job resolves submissions still in progress and writes per-document rejection reasons in plain language against the field at fault. Cancellation is exposed as an action in F&O that enforces the statutory window and requires a reason; once the window has closed the action blocks and directs the user to raise a credit note instead. That is the correct accounting outcome and it stops well-meaning users creating a compliance problem by pressing the wrong button.

### QR code and print The validated QR code and validation link are rendered on an SSRS report design that extends the standard invoice report rather than replacing it, so your existing layout, logo and language settings survive. Documents that have not yet been validated print in a clearly marked pending state rather than with a blank or misleading code.

### Consolidated e-invoices A monthly consolidated run selects transactions with buyers who did not request an individual e-invoice, aggregates them to the required structure, submits them, and writes the resulting identifier back against every underlying invoice. If a buyer later asks for their own e-invoice, the trail from their transaction to the consolidated submission is already recorded.

### Workflow, permissions and exception handling Submission and cancellation are controlled by dedicated security duties and privileges, and can optionally require workflow approval before a document leaves the building. An exception workspace lists rejected and failed documents with the authority's validation message, the offending field and a direct link to the source document, so correction and resubmission is a two-minute task rather than an investigation. Alerts notify named owners when failures accumulate or when documents age past a threshold without validation.

### Volume, throttling and audit All submission and polling runs as SysOperation batch classes with configurable bundling, concurrency limits and rate throttling so high-volume days do not trip API limits. Every request and response payload is retained in a submission log with a correlation identifier, which is the artefact that makes an audit conversation short.

### Multiple legal entities in one instance Each Malaysian legal entity carries its own taxpayer profile and credentials reference; entities in other countries are untouched by the extension. A regional F&O instance can therefore run Malaysian compliance without imposing anything on its neighbours.

## Who it is for Malaysian entities of groups running F&O who need submission driven from the ERP rather than a portal. Finance and tax teams already inside a rollout phase who are keying documents manually and cannot sustain it. Shared service centres issuing invoices for several Malaysian legal entities from one instance, who need per-entity credentials and per-entity reporting.

## How delivery works 1. Scoping call. We review your document types and volumes, tax and SST setup, item classification strategy, whether self-billed and consolidated submissions apply to you, your legal entity list and your rollout phase. 2. Fixed quote. A written scope naming the document types covered, the master data extensions, the report design changes and the exception handling. The price is fixed against that scope. 3. Build. Typical lead time is two to four weeks depending on document type coverage and the number of legal entities, with a checkpoint where a real posted invoice produces a complete submission payload for your review. 4. Install in test. The deployable package goes into your sandbox through your LCS pipeline and is connected to the authority's sandbox environment for end-to-end submission, validation, rejection and cancellation testing. 5. Production. Installed to production, live credentials configured under your control, batch schedule enabled, alerts routed, first live documents supervised. 6. Support window. An agreed post-go-live period covering defects and correction of mapping or classification issues surfaced by real traffic.

## Scope notes Everything is delivered as extensions with no overlayering, so platform updates continue to apply. Your taxpayer registration, credentials and any digital certificate remain in your name and under your control — ECOSIRE builds against the published MyInvois interface specification and is not a certified intermediary, a tax adviser or a government body. Determining which documents and categories are in scope for your business is a tax decision that stays with you or your advisers; we build to the determination you give us. Where the authority changes the specification during the phased rollout, mapping-level changes are handled as configuration and genuine interface contract changes are quoted as change requests.