Designing an Efficient Online VAT Invoicing System: Architecture & Tax Rules
This article explains the financial background, product and technical design, logical architecture, amount calculations, invoice splitting rules, and asynchronous interface flows needed to implement a robust online VAT invoicing system that complies with Chinese tax regulations.
Financial Knowledge Overview
In response to national policies aimed at improving business efficiency, the Chinese tax authority announced in September 2020 that electronic invoicing should be widely adopted, with the goal of achieving full electronic VAT special invoices for new taxpayers by the end of 2020.
To meet this policy and better serve enterprise customers, NetEase Cloud Communication launched an online electronic invoicing feature in September 2020, allowing VAT ordinary invoices to be issued automatically without manual offline processes.
Traditional Invoicing Method
A new company must apply for invoices at the tax bureau, purchase tax‑control equipment from a service provider, install the device, and obtain an initial issuance from the tax authority before using invoicing software for offline paper or electronic invoices.
Tax‑control devices include the "gold tax disk" (provided by Aerospace Information) and the "tax‑control disk" (provided by Baiwang).
Invoice Information
Key data fields for an electronic ordinary VAT invoice include buyer information, order information, and seller information.
Buyer Information: For B‑side enterprises, include taxpayer name, identification number, address, phone, bank account, and ensure the name matches the tax registration number; for individuals, include personal ID name.
Order Information: Service name (product name + service type), unit price (non‑tax price = round(non‑tax amount/quantity, 8)), amount (non‑tax amount, subject to invoice limit), tax rate (varies by tax classification code), tax amount (tax = round((quantity×tax‑included unit price)×tax rate)÷(1+tax rate), 2 decimal places), total tax‑included amount.
Seller Information: Company name (must match contract), tax ID, recipient, reviewer, and invoicer (usually finance or tax staff).
Invoice Types
The system handles two main VAT invoice types: ordinary VAT invoices ("blue tickets") and VAT special invoices ("red tickets"). Both electronic and paper versions must be compatible.
Common Terms
Blue ticket : Normal invoice. Red ticket (negative invoice) is used to cancel or correct a blue ticket, reducing the seller's sales revenue.
If a VAT special invoice is cancelled within the same month and not yet certified, it can be voided directly; otherwise a red ticket must be issued with a notification from the buyer's tax bureau.
Product Design
Before designing the online invoicing product, select a third‑party invoicing platform, then map its APIs to the business flow and functional points.
Third‑Party Invoicing Platforms
The ecosystem consists of tax‑control device vendors (Aixinno, Baiwang), emerging third‑party platforms (Baiwang, Gaodeng), traditional invoice service providers, and established software vendors (Yonyou, Kingdee). Enterprises can choose a platform based on their needs, supporting either automatic synchronization or QR‑code invoicing.
Business Process
Analyze business requirements, design a suitable invoicing workflow, and coordinate closely with finance and tax teams to ensure compliance. After order payment, the online invoicing and refund flow includes status transitions such as real‑name authentication, historical data checks, and optional financial audit steps.
Technical Design
Key design questions include identifying system users, defining tenant data isolation, and determining external service dependencies.
Who are the system users?
What data must be isolated per tenant?
What external services does the system rely on?
Specific internal business challenges involve calculating invoice amounts, handling multi‑order merging, and splitting invoices when limits are exceeded.
What do the various amount fields represent and how are they calculated?
How should invoices be split for large or merged orders?
System Users
In a group‑company structure, the top‑level group contains subsidiaries, each with product lines that may be owned by different entities. The product line is treated as a tenant.
Tenant Isolation
Isolation rules include: unique order numbers per seller account, per‑invoice non‑tax amount limits, and mapping of tenant to seller account, invoice limit, order numbers, and allowed SKU combinations.
Logical Architecture
Invoice generation requires four essential elements: invoice subject, order information, product information, and actual invoicing capability. The system depends on four external services:
User Center – provides authenticated invoice subject data.
Order Center – supplies order IDs and purchased SKU quantities.
Product Center – provides SKU name, tax classification code, specifications, and tax‑included unit price.
Invoicing Provider – delivers the electronic invoicing capability.
Amount Calculation
Tax amount = round((quantity × tax‑included unit price) × tax rate) ÷ (1+tax rate), 2 decimal places.
Tax amount = round((quantity × non‑tax unit price × tax rate), 2).
Non‑tax unit price = round(tax‑included unit price / (1+tax rate), 8).
Invoice Splitting
Because each seller invoice has a non‑tax amount ceiling, orders exceeding this limit must be split into multiple invoices. The platform’s automatic split function works per order, but for merged orders a custom split logic is needed to avoid wasteful small invoices.
The tax bureau limits the number of invoices that can be obtained each month.
Blue Ticket Splitting : Abstract the process into a main flow (one or more orders) and sub‑flows (individual invoices). Apply rules such as limiting non‑tax unit price to the ceiling, dividing quantities accordingly, and ensuring each sub‑invoice respects the amount limit.
Red Ticket Splitting : Red tickets correspond one‑to‑one with blue tickets; their details are the negatives of the blue ticket details, and the remark must include the original invoice code and number.
Interface Sequence and Asynchrony
Read‑only services (order, user, product centers) can be called synchronously with fast‑fail circuit breaking. The complex blue‑ticket split and external provider interaction are asynchronous, with retry mechanisms and status tracking (pending, success, failure, in‑progress).
The online invoicing system has been launched and is available for use.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
NetEase Smart Enterprise Tech+
Get cutting-edge insights from NetEase's CTO, access the most valuable tech knowledge, and learn NetEase's latest best practices. NetEase Smart Enterprise Tech+ helps you grow from a thinker into a tech expert.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
