Do we have to use a service provider for e-invoices, or can we integrate directly?

Both routes exist. If you work through a value-added service center or another provider with issuance capability, the formats, transmission, and downstream procedures are handled on their side; your system simply sends the transaction data to their interface, and they track regulatory changes for you. Integrating directly means handling data formats, invoice number range allocation, and upload and archiving yourself, which suits teams with high transaction volumes, an accounting system, and the capacity to maintain it long term. Most small and mid-sized e-commerce operations choose the first route, because what has to be maintained is not the initial integration but every subsequent change in the rules. For the actual requirements, rely on the current official guidance from the Ministry of Finance and from your chosen provider.

When a customer returns an order, do we void the invoice or issue an allowance?

In principle it depends on when the transaction took place and how much of the order is being returned. The two apply to different situations and each has its own time limits, so base the actual decision on current official guidance from the Ministry of Finance and your provider, and consult your accountant. From a system design perspective, what matters is that both paths must be supported in software and tied to order status: which path a full refund takes, which path a partial refund takes, and how repeated partial returns against one order accumulate all need to be defined during requirements. Without that design, the usual outcome is accounting issuing documents by hand, which defeats the automation entirely.

How do we handle carriers, mobile barcodes, and donation codes?

From the system's point of view, these are all ways of assigning an invoice that the customer chooses at checkout. Different choices send different fields, and they are mutually exclusive. A few things to watch when designing: issuing to a company requires a unified business number, which generally cannot be combined with a personal carrier; donation requires a selectable recipient organization; and a mobile barcode has to be format-checked, because an invalid one causes issuance to fail. Also account for customers changing their choice midway, or wanting to supply the detail after checkout. In practice these are the largest sources of customer service volume once a site is live.

E-Invoice Integration in Taiwan: A Guide

When a website needs to take money, most people think about payments first. What actually gets discovered right before launch, and generates the overtime, is usually invoicing.

The reason is simple: issuing an invoice is not a single action but a whole set of scenarios. Straightforward issuance is only the happiest of them. Returns, exchanges, partial refunds, a customer mistyping their company tax number, a malformed carrier, one transaction missing at reconciliation — each needs a defined response, and errors here flow straight into the accounts.

This guide explains how to plan an e-invoice integration in terms a non-engineer can follow, and what to confirm before acceptance.

What role the e-invoice plays inside your system

Taiwan’s e-invoice regime, put simply, moves what used to be a paper process into digital form: a merchant issues an invoice and uploads it to the Ministry of Finance’s integrated service platform, consumers can assign invoices to a carrier and use it to look them up and check them against the periodic invoice lottery that Taiwan runs on uniform invoices, and merchants then handle archiving and filing according to the rules.

For a system, this means an invoice is not finished the moment it is issued. It involves round trips in at least three directions:

Sending out. Issuing and uploading the transaction data in the required format.
Sending back. Voiding, allowances, and returns all have to be reported as subsequent adjustments.
Reconciling. Your own order records, the payment provider’s settlement records, and the invoice records all have to tie out against each other.

The third one is the most underestimated. A payment succeeds but issuance fails; an invoice is issued but the order was actually canceled. Without a mechanism that actively detects these inconsistencies, they usually surface at the month-end close. The reconciliation design on the payments side follows the same logic, so read it alongside the Taiwan payment gateway integration guide.

The specific format rules, time limits, and filing procedures are compliance details subject to change. Before development, rely on the official documentation from the Ministry of Finance and your chosen provider, and bring in an accountant where needed.

Two integration routes

Through a value-added service center or another provider with issuance capability. Your system calls the interface they supply to send transaction data, and they handle format conversion, upload, archiving, and the related procedures.

Direct integration. You manage invoice number ranges and allocation, assemble the data formats, and handle upload and the subsequent procedures yourself.

Dimension	Through a provider	Direct integration
Development effort	Concentrated on the interface integration	Must handle formats and procedural detail
Keeping up with rule changes	Updated by the provider	Tracked and implemented by you
Flexibility	Bounded by the provider’s feature set	Can be designed entirely to your needs
Long-term cost shape	Ongoing service fees	Development and maintenance capacity
Best suited to	Most small and mid-sized e-commerce and systems	High volume, with an accounting team

Neither is inherently better, and both are common in the market. Three questions get you to an answer: will your transaction volume grow large enough that service fees become a structural burden, does your team have anyone who can maintain compliance changes over the long run, and does your existing ERP or accounting system already have some of this capability? If the answer to the second is no, going through a provider is generally safer, because what needs maintaining is not the first integration but every rule change after it.

Whichever route you take, note one thing: do not hard-code invoice logic into the checkout flow. Keep it as a clearly separated module so that swapping providers or adjusting rules later has a contained blast radius. That is a basic principle of system integration and API development.

The scenarios you must handle

When writing requirements, each of the following needs its own description of who triggers it, under what conditions, and what happens on failure.

Issuance. The simplest case, but you still have to decide when it fires: at the moment payment succeeds, at shipping, or in a next-day batch? Different business models answer differently, and pre-orders and made-to-order goods deserve particular thought.

Voiding. Used when the transaction did not validly occur, with applicable time limits. The system should trigger it from the order cancellation action rather than relying on someone remembering to do it in the admin panel.

Allowances. The route used when an invoice has been issued and voiding is not appropriate; returns, partial refunds, and after-the-fact discounts may all go this way. What needs deliberate design is partial refunds and the accumulation logic for multiple returns against one order, which is where the arithmetic most often goes wrong.

Carriers and assignment methods. At checkout, a customer may choose a personal carrier (a digital identifier that stores their invoices), a company unified business number, or donation. These options are mutually exclusive and each has its own required fields: issuing to a company needs a validated unified business number, donation needs a selectable recipient organization, and a mobile barcode has to be format-checked first. Invalid input should be blocked at checkout rather than discovered when issuance fails and you have to go back to the customer.

Prizes and notifications. For customers using a carrier, the lottery check happens on the platform side; what the merchant has to handle is the completeness of its own issuance records. If you offer members a way to look up their invoices, confirm that the data source and status shown are current.

Failure and retry. Interface timeouts, temporary provider outages, and validation failures all need defined handling: record the reason, allow resending, and make sure resending cannot issue a duplicate. A duplicate invoice is more trouble than a failed one, because it then has to go through voiding or an allowance.

Mapping to orders and payments

Think of the three as a chain: order status, then payment status, then invoice status. The design has to answer each of these:

If payment succeeds but issuance fails, does the order still ship? Who gets notified?
When an order is canceled, is the void or allowance triggered automatically or does it need human confirmation?
When coupons, loyalty credits, shipping fees, or free gifts are involved, how is the invoice amount composed?
With split shipments, is one invoice issued or several?
Is there a daily automated reconciliation routine comparing orders, settlements, and invoices and reporting the differences?

That last one is strongly recommended. As long as any step can fail, inconsistencies will occur; the only question is whether you find them yourself or wait for somebody to report them. This style of automated reconciliation is the same design instinct as keeping logistics statuses in sync, so it is worth reading alongside the approach in the logistics and shipping integration guide.

Test environment and going live

Invoicing is one of the few features where incomplete testing produces an immediate, concrete cost.

Scenarios to run in the test environment should at minimum include: standard issuance, issuance to a company number, issuance to a carrier, donation, voiding, a full allowance, a partial allowance, multiple partial allowances, and the various failure and resend cases. List them and verify them one by one, using the test case format from How Software Acceptance Works.

When switching to production, confirm several things: that test identifiers have been fully replaced, that keys and certificates are stored properly rather than written into the code, that invoice number ranges are configured correctly, and that somebody watches the complete outcome of the first few real transactions on day one.

The first reconciliation cycle after launch is the real acceptance test. Compare that period’s orders, settlements, and invoices once and confirm nothing is missing. Only when that is done are you genuinely live.

Three common misconceptions

Assuming that issuing successfully means the job is finished. Issuance is the smoothest path; the hours go into exception handling and subsequent adjustments. Include them in the estimate, or the schedule will slip for exactly the reason described in Why Software Projects Run Late — underestimating integration and testing.

Scattering invoice logic across the codebase. One copy in checkout, one in the admin panel, one in the scheduled jobs, and a rule change inevitably misses one of them. Consolidating into a single module is a baseline requirement.

Leaving no path for human intervention. However complete the automation, exceptions occur. The admin panel has to let accounting look up, reissue, void, and export, or the only remedy when something goes wrong is editing the database directly.

There is also a staffing question that is easy to overlook: the invoice process cuts across marketing, customer service, accounting, and engineering. Marketing decides how discounts and free gifts combine, customer service fields complaints from customers who typed their company number wrong, accounting is responsible for filing and for the books being right, and engineering turns the rules into code. If requirements interviews only include one of those parties, whatever gets built will almost certainly jam at another. The more reliable approach is to bring accounting into the requirements meeting and have them describe how each adjustment scenario is actually handled today — that conversation usually surfaces the real rules faster than any specification document.

The difficulty of an invoice integration is not the technology; it is the completeness of the scenarios and the rigor of the accounting. Time spent during requirements writing each of the above down clearly saves far more back-and-forth after launch. For the details of the rules, rely on current official guidance from the Ministry of Finance and your provider, and have accounting and tax professionals confirm it.

If you are planning the invoice flow for an e-commerce site or an internal system, or your current issuance regularly needs manual repair, talk to NETVANA about your integration requirements. Software services are quoted individually rather than sold as fixed packages, and we clarify the scenarios and your existing systems before discussing scope; for what each service includes and delivers, see the software services overview.

Further reading: for design and reconciliation on the collection side, see the Taiwan payment gateway integration guide. If you are still choosing between a hosted store platform and a custom build, see Building an E-commerce Site. To connect several systems together, see A Guide to System Integration and API Development. For keeping shipping and logistics statuses in sync, see the logistics and shipping integration guide. And for building the pre-launch test list, see How Software Acceptance Works. Because shipments and returns both affect invoicing, see also Inventory Management System Development.