一张电子发票的生命周期：开具、传输、接收、入账与归档

The E-Invoice Lifecycle: Issuance, Exchange, Receipt, Posting and Archiving

An e-invoice is not a single “send” event. A dependable process connects the evidence of a transaction to invoice creation, validation, routing, the buyer’s review, accounting, payment and long-term retrieval. The exact route varies by jurisdiction, sector, contract and system. A tax platform is conditional in some regulatory models; it is not a universal gateway through which every invoice must pass.

One event chain, several distinct kinds of confirmation

Start with the business evidence: a purchase order, contract, shipment, signed delivery, timesheet or service acceptance. The seller’s system issues structured invoice data and validates it against applicable syntax, semantic and business rules. The message then travels through an agreed channel—direct integration, EDI, a portal, service provider or an interoperable network—to the buyer’s receiving system.

At least four confirmations must be kept distinct: (1) a transport receipt showing what happened to the message on the route; (2) a technical or rule-validation result; (3) a tax-authority result where the local regime requires invoice clearance or transaction reporting; and (4) the buyer’s business response, such as in process, queried, approved or rejected. None automatically proves that cash has reached the seller’s bank account.

The buyer’s response is a business signal, not a universal legal ruling

OpenPeppol’s Invoice Response specification describes a buyer-to-seller message about an invoice’s position in the buyer’s approval and payment process. It is optional for both sides under that specification, may be sent more than once, and follows the buyer’s business rules. The specification expressly says it does not change invoice content or commercial responsibilities and has no legal power of its own. It can still reduce manual status queries when both parties agree to use it.

Receiving an invoice, matching it to an order and receipt, approving it, posting it to the ledger and paying it are separate operational events. The system should state who sent each status, what it refers to, when it was created and what action follows. A single “complete” badge hides too much.

Exception handling and evidence

For a rejected validation, retain the failed rule, affected field, source version, correction and resubmission link. For a transmission timeout, check the message identifier before retrying and use duplicate controls. For an authority rejection, preserve the authority response and follow the locally valid correction or reissue procedure. For a buyer query, record the owner, missing evidence, due date and next status. Never overwrite the original invoice silently when a correction, credit note or replacement is required.

A practical evidence pack may link the source transaction, original structured payload, readable rendering, stable invoice and message identifiers, sender/receiver identity, timestamps, validation-rule version, delivery receipts, authority responses if applicable, buyer messages, approval, accounting entry, payment evidence, correction history and archive index. Treat this as an operational design checklist, not a universal statutory list.

Archiving is jurisdiction-specific

The archive must remain secure, searchable and readable for the period and in the manner required by each applicable jurisdiction. HMRC’s UK VAT guidance normally requires copies of issued and received invoices to be kept for six years and records to be producible in readable form. Canada’s CRA electronic-record guidance requires electronically kept records to remain readable for the relevant retention period and discusses backup recovery and audit trails. These are jurisdiction-specific examples, not a global six-year rule.

Before choosing a provider or retiring an old system, test that invoices, original data and linked evidence can still be retrieved, interpreted and exported. Document file formats, software versions, access controls, backups, migration procedures and restoration tests. Outsourcing storage does not by itself transfer the business’s record-keeping responsibilities.

Implementation checklist

Conclusion

Manage an e-invoice as a chain of linked events rather than one binary success flag. The common design challenge is to connect roles, identifiers, statuses and evidence. The local differences—clearance, post-transaction reporting, periodic reporting or no real-time tax platform—must be mapped explicitly before implementation. Ask not only whether a system can send an invoice, but what each confirmation proves, who owns exceptions and whether the entire trail will remain retrievable years later.

Checked against the cited primary sources on 19 October 2026. This article is general business analysis, not tax, legal or accounting advice.

Explore the e-invoicing series → · AI & Digitalisation → · Previous: Why e-invoicing matters