Your accountant spends every lunch break issuing invoices by hand
A supplement e-commerce brand takes about 180 orders a day on its own site. Payments run through ECPay; invoices are issued by logging into the platform's back office and typing them one by one. The accountant burns 90 minutes daily copying order numbers, tax IDs and carrier codes, then two more days at month-end reconciling "paid but not invoiced" against "invoiced but refunded." Last month: 11 invoices missed, 3 issued twice, and 2 flagged because they were uploaded after the 48-hour deadline. That is not a discipline problem. There is simply no path that runs payment success to automatic issuance to platform upload to order write-back. Building that path is what a Taiwan e-invoice integration is for.
Good fit vs. poor fit
Build it now if:
- You issue 300+ invoices a month from a system-driven sales channel (website, app, LINE storefront)
- You serve both B2C and B2B and must handle carriers, company tax IDs and donation codes separately
- Refunds, partial refunds and exchanges are frequent, so credit notes are routine
- You run or are adopting an ERP and want invoice data imported into journal entries monthly
- You sell across several channels and need one authoritative invoice source to avoid number collisions
Do not build it yet if:
- You issue under 100 invoices a month — manual entry in the provider's back office is cheaper
- You collect only cash or bank transfers, so no system event can trigger issuance
- Pricing and tax categories (taxable / zero-rated / exempt) are still undecided
- You have not yet obtained invoice number tracks from the National Taxation Bureau or completed provider delegation
- You plan to replace your ERP within the year — integrate once, after the new system is chosen
Alternatives matrix: four ways to do this
| Approach | Cost band | Upside | Downside |
|---|---|---|---|
| Self-hosted MOF Turnkey v3.0 | Software is free; server plus engineering upkeep runs NT$60,000+/year in labour | No platform fee, full data ownership | You own the XML MIG format, certificate renewals and scheduling monitors — unrealistic without an in-house team |
| Manual issuance in a value-added centre back office (ECPay, ezPay) | Annual volume tiers — see ECPay's official fee page | Fast to launch, almost no development | Human throughput caps out; misses and duplicates are caught only by eye |
| Value-added centre API integration (this article) | NT$90,000–165,000 build + platform annual fee | Issues automatically on payment success, automates voids and credit notes, enables reconciliation | Needs engineering time and a properly isolated test environment |
| Built-in ERP invoice module (Digiwin, Chanjet-class vendors) | Module licence + consulting, typically NT$150,000 and up | Shares a source of truth with journals and inventory | Real-time issuance from web or app still needs a separate integration; low flexibility |
The build, phase by phase: 5–7 weeks
| Phase | Duration | Deliverable | Tools |
|---|---|---|---|
| 1. Issuance rules audit | 3–5 days | Scenario matrix (B2C carrier / B2B tax ID / donation code / zero-rated), tax category mapping, void-vs-credit-note decision tree | Notion, Figma FigJam |
| 2. Number tracks and delegation | 5–15 business days, parallel to build | Number tracks allocated, provider delegation completed, sandbox keys issued | MOF E-Invoice Platform, ECPay merchant console |
| 3. Issuance engine | 2 weeks | State machine from payment-success webhook to issuance queue to invoice API to order write-back, with idempotency keys | Laravel Queue, Redis, PostgreSQL |
| 4. Voids, credit notes, lookups | 1 week | Single and batch voids, credit note issuance, invoice lookup and resend | Admin console, SendGrid |
| 5. Reconciliation and alerting | 4–5 days | Daily three-way report (orders / payments / invoices), 48-hour upload alert, failed-issuance retry report | Scheduled jobs, UptimeRobot, Slack webhooks |
| 6. Testing and launch | 1 week | Full-scenario walkthrough on test tracks, canary at 10% of orders, rollback script | Staging environment, GitHub Actions |
Full cost breakdown
| Line item | Amount (NT$) |
|---|---|
| Issuance rules audit and process design | 15,000–25,000 |
| Provider API integration (issue / void / credit note / query) | 35,000–60,000 |
| Admin invoice management and resend UI | 20,000–35,000 |
| Daily automated reconciliation and alerting | 12,000–25,000 |
| Accounting / ERP export format (CSV or XML) | 8,000–20,000 |
| Build total | 90,000–165,000 |
The recurring costs people forget (figures from ECPay's published fee schedule, all pre-tax, with 5% business tax added at settlement):
- One-time system setup fee: NT$3,600 for new users, NT$0 on renewal
- Annual service fee: NT$6,000 list price for 20,000 invoices/year, discounted to NT$0 for new users applying before 2026/12/31; renewal tiers include NT$3,600 for 5,000/year and NT$12,000 for 120,000/year
- SMS notification to buyers NT$1.5 each (email notification NT$0)
- Convenience-store ibon / FamiPort printing of winning invoices NT$20 each
- Payment processing is separate — credit card starts around 2.8%; see the ECPay service rate table for actual tiers
- Maintenance: 12–18% of build cost per year
What clients expect vs. what actually happens
| Client expects | What actually happens |
|---|---|
| Signing up with a provider means you can issue invoices | You still need number tracks allocated by the tax bureau (issued in two-month periods) plus delegation paperwork — 5–15 business days, and the single most common source of delay |
| An API integration reconciles itself | Successful issuance is not a balanced ledger. Order / payment / invoice mismatches stay invisible until you build a daily three-way report |
| Wrong invoices can be edited | Invoices cannot be edited. You void and reissue within the same period, or issue a credit note across periods |
| Transaction fees are the whole cost | Setup fee, annual volume tier, SMS charges, store printing charges and 5% business tax all belong in the annual budget |
| Someone clicks "upload" for us | Upload should be scheduled and automatic; the risk is a silent failure. B2C invoices must reach the platform within 48 hours of issuance, and 7 days when the buyer is a business — see the Ministry of Finance guidance |
Six traps and how to avoid each
- Running out of number tracks. Issuance stops dead at period end. Fix: Slack alert when remaining numbers drop below 15%, and allocate the next period in week one.
- Issuing before payment clears. Triggering on "order submitted" produces invoices for failed payments. Fix: the payment-success webhook is the only legal trigger.
- Duplicate issuance. Webhook retries and double-clicks create two invoices for one order. Fix: use the order number as an idempotency key with a database unique index; repeat calls return the existing invoice number.
- Unvalidated tax IDs and carrier codes. A mobile barcode missing a character fails at issuance time. Fix: validate in the browser and again server-side; on failure, issue without a carrier and notify support.
- Voiding across periods. Treating a cross-period refund as a void gets it rejected. Fix: let the system decide void vs. credit note from the issuance date — never leave it to a human dropdown.
- Production tracks used in staging. One QA cycle can burn hundreds of live numbers. Fix: force the test domain and test tracks in staging; production keys live only in production environment variables.
Success metrics and the 90-day roadmap
- Days 1–30 (stabilise): issuance success rate at or above 99.5%, 48-hour upload compliance at 100%, zero daily three-way reconciliation discrepancies. Run 10% of orders through the new path for two weeks before full cutover.
- Days 31–60 (reclaim labour): manual re-issuance under 1% of volume, daily accounting time down from 90 minutes to under 10, and "I never got my invoice" support tickets down 50%.
- Days 61–90 (connect accounting): credit notes plus voids held under 3%, month-end close shortened by 1–2 business days, invoice data auto-imported into the ERP as journal entries, carrier-registration rate tracked.
Decision checklist: 12 yes/no questions
- ☐ Do you issue more than 300 invoices a month?
- ☐ Have you missed or duplicated an invoice in the last three months?
- ☐ Have your invoice number tracks already been allocated?
- ☐ Does your payment provider send a reliable payment-success webhook?
- ☐ Are tax categories and product classifications finalised?
- ☐ Do you need carriers, tax IDs and donation codes simultaneously?
- ☐ Do refunds or exchanges exceed 2% of monthly orders?
- ☐ Does anyone actively check 48-hour upload status today?
- ☐ Does accounting spend more than 30 minutes a day on invoices?
- ☐ Do you need invoice data imported into an ERP or accounting package?
- ☐ Do you have a separate staging environment for test tracks?
- ☐ Are you confident you will not change payment providers in 12 months?
Seven or more checks and the integration typically pays for itself within six months. Fewer than four and your next step is process clean-up, not development.
FAQ
Can we start with the free MOF Turnkey and migrate to a provider later?
Yes, but migration means redoing delegation and track configuration, and your invoice history ends up split across two systems. Without engineers who can maintain servers and renew certificates for years, starting with a value-added centre is usually cheaper in total. The Ministry of Finance publishes an approved value-added service centre directory for comparison.
Do we really need an API? Isn't manual issuance fine?
Under 100 invoices a month, manual is entirely reasonable. Above 300, labour plus rework exceeds the amortised cost of integration. Rough formula: monthly volume times 0.5 minutes times 12 months times hourly rate — if the three-year figure exceeds NT$150,000, integrate.
Can a wrong invoice be deleted?
No. Once issued, a Taiwan e-invoice cannot be edited or deleted — only voided within the same period or offset with a credit note across periods. Design accordingly: put your effort into pre-issuance validation, not post-hoc correction.
Do we have to replace our accounting software?
No. Most projects keep the existing accounting system and add a standard export file (CSV or XML) for monthly import. Only when the accounting system cannot import at all does a middleware layer or system change come onto the table.
How much calendar time should we budget?
Five to seven weeks of build, but allow 5–15 business days for number tracks and delegation, filed in week one. In practice projects slip on paperwork far more often than on code.
Next step
ScriptWalker's E-Invoice Integration and Reconciliation System package covers the issuance rules audit, provider API integration (issue / void / credit note / query), an admin invoice console, daily three-way reconciliation with 48-hour upload alerting, and accounting export formats. It starts at NT$90,000 with standard delivery in 5–7 weeks. Book a free 30-minute consultation and we will use your current monthly volume, refund ratio and accounting workflow to calculate the payback period on the spot.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p