How to Build Taiwan E-Invoice Integration: Value-Added Center vs Self-Hosted Turnkey

The 37 complaint emails that arrived on a Monday

An online course platform got 37 identical emails one Monday: "Where is the invoice for last week's payment?" Payment callbacks had succeeded and orders were updated, but the invoice API had no retry after a third-party timeout. Of 312 transactions, 37 produced no invoice, and 9 had already missed the statutory upload deadline. Under a Ministry of Finance notice, late or inaccurate transmission draws fines of NT$1,500 to NT$15,000, repeatable per occurrence. Invoicing is not a side effect of order completion. It is a legally time-bound pipeline that needs its own monitoring.

When this is worth building — and when it is not

Good fit now:

• You issue 300+ invoices a month and accounting still types them by hand
• Subscriptions or instalments need automatic issuance every cycle
• Returns are frequent, so allowances and voids get missed
• You serve B2C and B2B, needing carriers and buyer tax IDs in one flow

Not a fit yet:

• Under 100 a month: issuing manually is cheaper, payback exceeds two years
• Number ranges and provider delegation are not approved yet — no code can ship
• Pricing, tax categories or the legal entity are still moving
• You run Digiwin or SAP with a bundled invoice module — evaluate that first

Three alternatives, compared

Decision rule: under 5,000 invoices a month on a hosted store, use the built-in feature; 5,000 to 50,000, use a value-added center API; above 50,000 or with data-residency requirements, evaluate self-hosted Turnkey.

The full build, phase by phase (realistically 8–10 weeks)

• Week 1 — scenario audit. Confirm tax ID, business certificate and VAT registration. Deliverable: a Notion scenario list covering six cases — issue, void, allowance, refund, B2B triplicate, cross-period re-issue.
• Weeks 1–3 — number ranges (parallel). Apply to the National Taxation Bureau, then complete delegation and allocation on the platform. Deliverable: sandbox keys and the live range. This is the most common bottleneck, and it is administrative.
• Weeks 3–5 — core integration. Build a dedicated invoices table and state machine (pending / issued / void / allowance / failed). Every issuance goes through a queue monitored with Laravel Horizon. Deliverable: all six scenarios passing in sandbox.
• Weeks 5–7 — edge cases and admin. Validate carrier formats (a mobile barcode is 8 characters starting with "/"), donation codes, tax ID checksums, mixed tax categories, rounding. Deliverable: a Filament management screen with manual re-issue and resend.
• Weeks 7–10 — reconciliation and launch. A daily job compares successful payments, issued invoices and records stored on the government platform; gaps email accounting. Deliverable: reconciliation report, launch runbook, UptimeRobot and Sentry alerting.

Three budget tiers (real NT$)

Hidden costs teams forget:

• Provider setup fee: ECPay charges NT$3,600 pre-tax for new accounts, NT$0 on renewal
• Annual volume fee at ECPay: NT$3,600 for 5,000 invoices, NT$6,000 for 20,000, NT$12,000 for 120,000 — pre-tax, plus 5% VAT
• SMS notifications at NT$1.5 each; NT$20 per winning invoice printed at a convenience-store kiosk, billed monthly
• Running out of number ranges without a renewal in flight — in practice this happens at least once a year
• Annual maintenance: 8–16 hours a year for MIG format or provider API changes

What clients expect vs what happens

• Expected "one API, two days"; reality issuance is 20% of the effort, voids, allowances, refunds and cross-period re-issues are the other 80%.
• Expected "code done, we go live"; reality number range approval takes 5–15 business days and cannot be compressed.
• Expected "we'll just edit a wrong invoice"; reality an uploaded invoice can only be voided or offset with an allowance. Amounts are never edited in place.
• Expected "sandbox passed, production is fine"; reality test ranges behave differently. Validate with a small batch of real orders on day one.

Six traps and how to avoid each

• Issuing inside the payment callback transaction. Fix: the callback writes only the order and a pending record; issuance goes to a queue with three retries and an alert on final failure.
• No idempotency key, so a repeated callback issues two invoices. Fix: use the order number as the unique key with a database unique index, and check for an existing record first.
• Carrier and donation codes never validated in the front end. Fix: validate format and donation code existence at checkout, so errors surface there.
• Nobody notices the number range is nearly exhausted. Fix: a daily job pings finance and engineering on LINE when remaining numbers drop below 20%.
• Monitoring the API response but never the government record. Fix: reconcile daily and treat "issued but not stored" as a P1 incident.
• Refunds handled by voiding a cross-period invoice. Fix: always use an allowance across filing periods, with separate buttons and permissions in the admin.

Success metrics and the 90-day roadmap

• Day 30: issuance success rate at or above 99.5%, manual re-issues under 2%, at least 25 days with zero reconciliation variance. Tune retry strategy and exception alerts.
• Day 60: carrier adoption at 60% or higher, cutting paper costs; average allowance handling down from 15 minutes to 3. Improve the admin workflow.
• Day 90: monthly close shortened by four hours or more, zero late transmissions, and the number-range alert triggered once with a successful renewal. Feed the reconciliation report into bookkeeping.

Decision checklist

• ☐ Valid business certificate and active VAT registration
• ☐ Monthly volume already exceeds 300 invoices
• ☐ Invoices are currently typed by hand in a console
• ☐ A missed or duplicated invoice happened in the last six months
• ☐ Returns require voids and allowances
• ☐ Both B2C and B2B buyers are served
• ☐ A provider is chosen, or you want a recommendation
• ☐ Subscriptions or instalment billing are in scope
• ☐ Invoice data must flow back into an ERP or bookkeeping tool
• ☐ You accept a 5–15 business day approval window
• ☐ A finance contact will join acceptance testing
• ☐ Budget covers daily reconciliation, not just issuance

Seven or more checked: move into planning. Four or fewer: issue manually for three months, then reassess.

Frequently asked questions

Do we have to use a value-added center?

You can self-host Turnkey and connect directly, but you supply the server, the business certificate and ongoing XML MIG maintenance. Below roughly 50,000 invoices a month, the annual center fee usually costs less than the ops hours self-hosting consumes.

How quickly must invoices be uploaded?

For business buyers (B2B) the window is 7 days from the following day; for non-business buyers (B2C) it is 2 days. Late or inaccurate transmission can bring fines of NT$1,500 to NT$15,000, repeatable per occurrence.

For a refund, do we void or issue an allowance?

Within the same filing period and before filing, voiding and reissuing is usually acceptable; across periods you must issue an allowance. Build them as two actions with distinct permissions so support staff are not left to judge.

Are sandbox invoices real?

Sandbox uses test number ranges with no legal effect that are never stored on the government platform. Live ranges must be applied for at the National Taxation Bureau and then allocated and delegated — start two to three weeks early.

How painful is switching providers later?

If invoice logic sits behind one service layer with a unified interface, switching takes two to three weeks. If API calls are scattered across orders, refunds and admin screens, re-integration costs about as much as rebuilding.

Next step

ScriptWalker's E-Invoice Integration Module starts at NT$45,000, covering scenario audit, sandbox integration, an admin re-issue interface and daily reconciliation. We offer a free 30-minute consultation to check your number range status and current gaps before you decide to build. Get in touch:

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p