The short version: an e-invoice is not a PDF you email
A common misunderstanding is that an e-invoice means sending the customer an electronic file. It does not. An e-invoice is invoice data uploaded to Taiwan's Ministry of Finance e-invoice platform. The image the customer receives is only a notification.
So compliance is not judged by whether you sent something to the buyer. It is judged by whether the data arrived at the platform.
Who has to issue them
Broadly, any business operating in Taiwan that must issue uniform invoices. In practice you will meet three forms:
| Form | Buyer | Typical setting |
|---|---|---|
| B2C e-invoice | Individual consumer | E-commerce, retail; stored on a carrier, no paper |
| B2B e-invoice | Company with a tax ID | Wholesale, corporate purchasing |
| Donation | A registered institution | Consumer donates the invoice |
B2C and B2B require different fields, so a system has to handle both rather than just one.
Carriers, and why they get mishandled
A carrier is how an invoice is attributed to a person, so consumers can check prize draws without paper. The common ones are the mobile barcode, the Citizen Digital Certificate, and various cards.
The most frequent mistake is treating the carrier as optional. If a consumer gives a mobile barcode and you do not upload it, the invoice never lands in their account and cannot be found at prize time — which becomes a support ticket.
The second is format validation. The mobile barcode is a fixed eight characters with rules; submit it unvalidated and the platform rejects it.
Voiding and allowances are different things
This is where implementations most often fall short.
- Void: the invoice is treated as never having existed. Time-limited to the same invoice period, and a reason is required.
- Allowance: the invoice stands, but part of the amount is returned. Partial returns and after-the-fact discounts use this.
If a system implements voiding but not allowances, partial returns can only be handled by voiding and reissuing the whole invoice — which is impossible across periods. The work then moves outside the system and the books scatter.
Direct integration or a service provider
Integrating with the government platform directly carries real technical and compliance load: certificates, formats, invoice number track allocation, retry on failure. Most companies therefore go through a value-added service provider such as Amego or ECPay.
The provider handles number track management, format conversion and upload, retries, carrier attribution, and filing of voids and allowances.
Your system only needs to talk to their API. What to ask when choosing: is B2B supported? Is there an allowance API? Will you be warned before a number track runs out? Is the test environment usable?
What is actually worth automating
The labour in invoicing is not issuing. It is reconciling.
If invoices are issued in one piece of software while sales data lives in your ERP, someone checks both every month for missed invoices, wrong amounts and voids not reversed in the books. That work exists purely because the data exists twice.
The simpler arrangement is for the sales order itself to produce the invoice — number, buyer and line items all drawn from the original transaction. No re-entry, therefore no reconciliation. SynERP's Amego integration is built this way: issue directly from the confirmed sales order, without switching software.