Automating Government E-Invoicing: Voids, Reissues, and Tax-ID Scenarios Explained

Many e-commerce teams assume government e-invoicing means "call the issue API once when the order is created," check the box, done. After running automated issuance on our own store, we learned that issuing is merely the easiest first step of the lifecycle. The real time sink comes after: amounts change and require void-and-reissue, customers add a company tax ID after the fact, refunds require credit notes, failed issuances need recovery — every one of these scenarios shows up in real operations, usually when you're busiest.

This article walks through the complete e-invoice lifecycle. Everything here is a process we run every day.

Automatic issuance: timing and idempotency are the two landmines

Tie issuance to "payment completed," not "order created." With convenience-store payment codes, the shopper might pay three days after taking the code — or never. With cash on delivery, the money only truly arrives after shipment. Issue invoices on order creation and you'll produce a pile of invoices with no underlying transaction, and month-end reconciliation will make you question your life choices.

The issuance action must be idempotent. Payment notifications get resent (covered in detail in Ten pitfalls of ECPay integration), and if your invoice issuance hangs off the payment notification without duplicate protection, one order will produce two invoices. Our approach: before issuing, check whether the order already has a valid invoice — if so, skip — and store the invoice number bound to the order.

Tax IDs and carriers: B2C and B2B are two different paths

Individual consumers use a carrier (mobile barcode or citizen digital certificate) or a member carrier, with lottery winnings notified by the platform — a simple flow. But mobile barcodes need format validation: one mistyped barcode makes invoice attribution fail, and the complaint still lands on you. The real trouble is the company tax ID (uniform business number):

• An invoice with a tax ID requires complete buyer information. Not just the eight-digit number — missing company name, address, or other fields make the issue API reject outright. Collect all the fields at the moment the shopper checks "I need a tax ID" during checkout; don't chase them afterward through support messages.
• "I need a tax ID" after the invoice is issued is a daily occurrence. Converting a personal invoice to a company invoice isn't an edit — it's voiding the original and issuing a new B2B invoice. Either build this flow into the back office so support can handle it in one click, or watch your engineers process it by hand several times a month.

Void, reissue, credit note: the invoice's second half

Amount change = void and reissue. When a customer changes flavor, quantity, or delivery method and the amount shifts, the invoice amount cannot be edited — only voided and reissued. We made it a one-click back-office action: one button voids the old invoice, reissues at the new amount, and records the link between the two, so support can handle it without filing a ticket.

Refunds go through a credit note or a void, depending on timing. A full refund within the same invoicing period can be a straight void; cross-period or partial refunds require a credit note. This is the most commonly missed piece — the system refunds smoothly while the invoice sits untouched, opening a books gap of "money refunded, invoice still standing" that accounting discovers at month-end, and you go back to file a stack of paperwork.

Failed issuance needs a retry path and a manual fallback. The invoicing service has occasional blips. Failed issuances should enter a retry queue; those that still fail need a list for manual issuance — not a silent disappearance into the logs.

One environment-configuration detail

Bind the invoice test/production environment switch to the same toggle as your payment gateway mode. A lesson we paid for: payments switched to production while invoicing still pointed at the test environment — every real order's invoice went into the sandbox. That particular feeling is not one we recommend experiencing. For how important it is to run a real order through the full flow before launch, see the complete checklist in End-to-end testing before launch.

A good invoicing system isn't judged by whether it can issue — it's judged by whether it can amend, refund, and recover.

If your store is still issuing invoices by hand, or your automation keeps misbehaving, take a look at our e-commerce build services — invoice automation including void-and-reissue and tax-ID scenarios is part of our standard delivery scope, because we use it ourselves every day.