e
ezPay E-Invoice Methodology 台灣電商：ezPay E-Invoice Methodology
Released已發布 industry ecommerce
Issue and manage Taiwan e-invoices via ezPay (加值服務中心) through mcp-ezpay-einvoice. Use when issuing B2B/B2C invoices, handling carrier codes (手機條碼, 自然人憑證), voiding within the same bimonthly window, or issuing allowances (折讓) across periods. Do NOT use for direct 財政部 API integration (see tw-einvoice-guide) or for UniversalEC-backed flows (see tw-ecom-invoice-universalec).
台灣電商技能：ezPay E-Invoice Methodology 分析與應用。
Assumptions前提假設
- Tax semantics: {tax_type="1" 應稅 with tax_rate=5, amt/tax_amt/total_amt consistent}
- Carrier validated client-side before API call: Y/N
- 統編 validated against company registry (if B2B): Y/N
- TODO: {anything that needs verification against ezPay merchant portal or MOF platform}
Output Format輸出格式
When completing an ezPay invoice task, produce this structure:
# ezPay Invoice Task: {one-line summary}
Gotchas注意事項
- 字軌 exhaustion silently blocks issuance. MOF assigns number ranges per bimonthly period; ezPay draws from them. If you don't request the next period's range in advance (via the ezPay merchant portal or MOF platform), the first issuance attempt after the rollover fails with an opaque error. Monitor remaining-number count weekly and request the next range at least 1 bimonthly period ahead. (TODO: verify the exact portal path and any ezPay auto-refill option against the current ezPay merchant portal.)
- Void window is same-bimonthly only; cross-period corrections need 折讓. Per the README, an invoice issued in March-April can be voided before roughly May 14. A March invoice discovered wrong in June cannot be voided —
void_invoicereturnsINV20002(void period has passed). The only correction path isissue_allowance+trigger_allowance. Agents who retryvoid_invoiceindefinitely never resolve the error. - 手機條碼 format is strict:
/+ exactly 7 alphanumeric characters.ABC1234(no slash),/ABC12345(8 chars), lowercase, or a scanned barcode with leading whitespace all fail. Validate client-side beforeissue_invoice— ezPay's error for invalid carriers is generic, and the invoice is not created, so you cannot recover by patching. Many POS scanners also need to be configured to emit the/prefix; test with real 手機條碼 barcodes, not typed input. - Missing
buyer_ubnon a B2B sale silently becomes B2C.category="B2B"withoutbuyer_ubnwill be rejected, butcategory="B2C"with a business buyer that SHOULD have had a 統編 issues a B2C invoice — which is lottery-eligible and taxed differently. When the buyer exists in your CRM as a company, enforcecategory="B2B"+buyer_ubnin your backend, not the UI. UI-only enforcement is bypassed by webhooks replaying a stale payload. - ezPay state can lag the MOF platform — reconcile against MOF, not ezPay.
query_invoicereturns ezPay's internal record. The 財政部電子發票整合服務平台 is where tax liability is established, and ezPay uploads in batches. A successfulquery_invoicedoes not prove the invoice is on the MOF platform. Run a daily reconciliation job that fetches the MOF upload status (per invoice or per batch) and reconciles against your DB. Trust neither ezPay's local state nor your own DB as the source of truth for tax filing. (TODO: verify exact ezPay-to-MOF upload latency from the ezPay merchant portal reporting dashboard.) - Pipe-delimited item arrays are positional — one misaligned field corrupts every item.
item_name="拿鐵|蛋糕",item_count="2|1",item_price="65|85",item_amt="130|85"must all have the same pipe count and the same order. A leading or trailing|, or a missing field on one line, shifts every subsequent item's price onto the wrong name. ezPay does not validate alignment — it stores whatever you send. Audit withquery_invoiceafter issuance on every flow change.
Tags標籤
taiwane-invoiceezpaytax-compliance