Malaysia MyInvois E-Invoicing

The problem

Under the Malaysian e-invoicing model, an invoice is not finished when you post it. It has to be rendered as a UBL 2.1 XML document, submitted to MyInvois, validated, and returned with a UUID and a QR code — and only that validated version is the one your buyer is entitled to receive. There is also a rejection window during which the buyer can push back, and a cancellation window during which you can withdraw. Miss the sequencing and you have handed over a document that does not officially exist.

SAP Business One has none of this. OINV and INV1 hold the commercial content — Business Partner, TIN, line items, quantities, unit prices, tax codes, totals — but B1 produces no UBL, has no MyInvois client, and has nowhere to put a returned UUID or QR. Nor does it distinguish a submitted invoice from a validated one, which is the distinction that actually matters.

The manual workaround is portal entry, which caps out quickly. And because the mandate is phased, an organisation that is comfortably outside it this year is inside it next year, usually along with its subsidiaries — so the workaround has an expiry date.

What ECOSIRE builds

We build a SAP Business One add-on that makes MyInvois validation part of the invoice lifecycle instead of a parallel manual process.

UBL 2.1 document construction

The add-on maps posted A/R Invoices, A/R Credit Memos and A/R Down Payment Invoices into UBL 2.1 Invoice, CreditNote and related document types. Supplier and buyer parties are built from the Business Partner master (OCRD) and your company details — TIN, registration identifiers, MSIC classification, and the address structure MyInvois expects. Lines come from INV1: item classification code, description, quantity, unit of measure, unit price, discount, tax type and rate, and the tax subtotals that must reconcile to the document total. Currency and exchange-rate handling follows the rate held on the B1 document, so a foreign-currency invoice carries both the transaction currency and the ringgit equivalent.

Submission and the validation lifecycle

Submission runs through the Service Layer (REST) for read and write-back and through a dedicated MyInvois client for the API calls themselves. Documents are batched to the submission endpoint, and the returned submission identifier is retained. Because validation is asynchronous, a poller re-checks each submission until every document within it resolves to valid or invalid, then writes the outcome back.

What lands on the B1 side: UDFs on the invoice holding the MyInvois UUID, the validation status, the validation timestamp, and the QR payload; and a User-Defined Table holding the full submission history, including the exact UBL sent and the validation errors returned. That history is what you use when a document is disputed or an auditor asks what was actually transmitted.

Rejection and cancellation windows

The add-on tracks the buyer-rejection window and the supplier-cancellation window against each validated document, so the finance team can see which invoices are still inside a window and which have passed out of one. Cancellation is exposed as an explicit action with a mandatory reason, written to the submission history, and reflected in the document's status UDF. Post-window corrections are steered toward a credit note rather than a cancellation, because that is the only route left once the window closes.

Validation before submission

A pre-flight validator runs the document against the structural rules before anything is sent: buyer TIN present and well-formed, classification codes assigned on every line, tax subtotals reconciling to the header, mandatory party fields populated, currency and rate consistent. Failures are reported against the specific line or field, on screen, at the moment of posting or submission — not as an opaque rejection an hour later.

Classification codes

MyInvois requires classification on every line. We add UDFs on the Item Master (OITM) for the classification code and a User-Defined Table holding the catalogue, with a bulk-maintenance path so the whole item master can be classified without touching items one at a time. Item groups can carry a default that individual items override.

Delivery to the buyer

Only the validated document goes out. We build a Crystal Report layout bound to the A/R Invoice that renders the QR and the MyInvois UUID, and gate the send action so it is unavailable until the document has come back valid. Where you want automated distribution, the send is driven off validation status rather than posting status.

Operational surfaces

A UDO-based cockpit gives finance a single worklist: awaiting submission, awaiting validation, invalid with reasons, valid, cancelled. It includes a retry action, a cancellation action with reason capture, and a reconciliation view comparing posted A/R documents in a period against validated MyInvois documents.

Who this is for

Companies running SAP Business One in Malaysia that are inside the mandate now or expect to be in the next phase. It suits businesses with enough invoice volume that portal entry is already painful, groups with several Malaysian entities on one B1 landscape, and organisations issuing foreign-currency invoices or a meaningful volume of credit notes — the cases where the sequencing rules bite hardest.

Compatibility

Built for SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted, using the Service Layer, the DI API, and UDF/UDT/UDO extensibility. Delivered per tenant and installed into your own company databases.

How delivery works

1. Scoping call. We review your B1 version and platform, the entities and document types in scope, your tax code setup, currency handling, item classification state, and how you currently deliver invoices to buyers. We agree the first release scope explicitly.

2. Fixed quote. A written scope and a fixed price, issued before development starts.

3. Build. We develop against your configuration — your tax codes, your item master, your entities. Typical lead time is two to four weeks depending on scope. This app is built for you on order; it is not an existing product waiting to be downloaded.

4. Install in test, then production. Installed first into your test company database and exercised against the MyInvois sandbox with your own documents. Production installation follows your sign-off.

5. Support. A support window from go-live covering defects, configuration questions, and classification-catalogue maintenance as your item master changes.