Taiwan eGUI MIG Format: What an ERP Team Must Build

The MIG, short for Message Implementation Guideline, is the Ministry of Finance's specification of the XML messages that carry a Taiwan eGUI to the E-Invoice Platform. Your ERP has to produce it, sign it and send it through Turnkey or a value-adding centre. From 1 January 2026 the version that applies is MIG 4.x. This page sets out what the MIG is, what the Ministry requires around it, and where it stops and Peppol starts.

We do not reproduce the specification, and we do not produce MIG files. GoRoute carries the Peppol leg only. The MIG is published on the Ministry's platform and revised there, so it is the source for field names and message codes. What follows is the part that is stable and sourced: what your system must do around the file.

What is the MIG?

It is the standard the Ministry announces for e-invoice data exchange. The Ministry's Directions for the Implementation of Electronic Uniform Invoices Operations say, in Point 4, that an e-invoice system "shall comply with the Message Implementation Guideline (MIG) for the implementation of E-Invoice-based Electronic Data Interchange (EDI) standards announced by the MOF". That sentence makes the MIG a requirement, not a convention.

In practice it is an XML message set. One message type exists for issuing an invoice and others exist for the follow-on events, such as a cancellation or an allowance. We have not listed their codes here for the reason given at the end of this page.

Which MIG version applies?

MIG 4.x. GoRoute's Taiwan page records two dates against the Ministry's platform: MIG 4.0 became the standard message format on 1 January 2024, and the transition in which MIG 3.1 and 3.2 files were still accepted ended on 31 December 2025. From 1 January 2026 a file in the 3.x layout is no longer in the accepted set.

You will see "MIG 4.1" in vendor material. We have not confirmed the release number the Ministry currently publishes, so we do not state one. The Platform publishes the current release and the Turnkey build that goes with it. Read the release notes there, and treat any date or number on a vendor page as unconfirmed until you have.

We also do not describe the differences between 3.2 and 4.x field by field. That needs the guide itself, and a wrong field mapping fails an upload.

What does an issuance message carry?

The particulars that the law requires on the invoice. Article 9 of the Regulations Governing the Use of Uniform Invoices lists them: the alphabetical letters and numbers of the invoice, the actual date, item name, quantity, unit price, item subtotal, sales amount, tax classification, tax, and the total amount of the transaction.

Two buyer rules shape the message:

• A business using triplicate or computerised invoices provides the name and uniform serial number of the purchaser. If the name cannot be printed, the serial number suffices.
• Where the buyer is not a business, the invoice is issued at the list price, and the purchaser's name and address are needed only in some cases, such as a manufacturer or importer selling to a non-business buyer.

It is reasonable to expect the MIG to hold those particulars in named elements. That is inference from the Regulations, not a quotation from the guide. Map your ERP fields against the guide's element list, not against this page.

Invoice numbers come from the Ministry. Our Taiwan page explains the two-month allocation periods, and the Directions require a business to upload the number-range data for its head office and branches within the Act's time limit.

What must a system do before it uploads anything?

Four things, each from the Directions:

1. Sign. Use a certificate issued by the Government Certification Authority, or an electronic signature the Ministry approves (Point 5).
2. Self-test. Before the first electronic uniform invoice, run the Ministry's "Self-test Table of E-Invoice Issuing System" and keep the records. The same applies to a program update that touches test items (Point 4).
3. Test Turnkey. If you transmit with the Platform's Turnkey software, complete the "E-Invoice Self-Test before Turnkey Goes Online" first (Point 4).
4. Check for gaps. The system must have a function to prevent errors or duplicated invoice numbers and any failure to upload (Point 4).

Retention follows. The Directions require the purchaser's consent message, or other evidence, to be kept for at least five years for any issuance, correction, nullification, return or allowance (Point 9).

How does the MIG reach the Ministry?

Through Turnkey or a value-adding centre, within the upload windows: 2 days for a consumer invoice and 7 days for a business invoice, as set out on our Taiwan page. A value-adding centre, defined in the Directions as a business that provides an E-Invoice system to others after approval by the tax authority, forwards in real time. GoRoute is not one.

Corrections travel the same way. Voids and allowances covers which event needs which message, and why we do not print the codes.

Where does the MIG stop and Peppol start?

At the border. The MIG file is for the domestic upload. A sale to a buyer abroad does not need it, as exporting from Taiwan explains, and a Peppol invoice is a different document in a different format that travels through an access point. A foreign supplier selling to a Taiwanese business has no MIG duty either, which invoicing a Taiwanese business from abroad covers. Peppol BIS 3.0 versus PINT shows how the international formats differ.

What should an implementation plan include?

A short list is enough to start. Name the MIG release your ERP module produces and the date the vendor last updated it. Name the certificate holder and the renewal date, because an expired signing certificate stops every upload. Decide who watches the upload queue, since a file that fails to reach the Platform inside its 2-day or 7-day window is the failure the Ministry penalises. Record the self-test results the Directions ask you to keep. Keep a separate, clearly labelled test environment.

None of that needs the field list. All of it needs an owner.

Why are there no message codes on this page?

Because the Ministry's guide is the authority for them, and we could not read the current release on the day we wrote this page. The codes and element names changed between versions, and a code copied from an old guide fails a real upload. Take them from the Platform, not from us. When we have read the current guide, this page gets updated.

What to do next

Ask your ERP vendor three questions: which MIG release does the module produce, which signing certificate does it use, and does it keep the five-year consent record. Then compare the answers with the release notes on the Ministry's platform.

For the cross-border leg, the Taiwan page shows how Peppol sits beside the eGUI. The documentation covers the API, and the tutorials show an invoice going out. To talk it through, book a demo. For the next read, what a Peppol access point is.

GoRoute is a certified Peppol Access Point (POP000991).

Primary sources: Directions for the Implementation of Electronic Uniform Invoices Operations, Ministry of Finance, amended 22 April 2026, Points 4, 5 and 9; Regulations Governing the Use of Uniform Invoices, Article 9; Ministry of Finance E-Invoice Platform.