The essence of an e-invoice is not an electronic file. It is a legally traceable expression of a transaction at a particular point in time. The same transaction can create performance, commercial settlement, and statutory tax facts at different moments. An invoice connects these facts; it does not make them one fact.
Three facts behind one “invoice”
| Fact | Question | Typical evidence |
|---|---|---|
| Performance | What goods were delivered or what service was completed? | Goods movement, delivery, acceptance, service confirmation |
| Commercial settlement | What is owed, when is it due, and has it been paid? | Billing, commercial invoice, receivable, payment and clearing |
| Statutory tax | What has been legally issued, reported, validated, or accepted? | Official number, UUID/IRN, authority status and timestamp |
These facts may share amounts and references, but their numbers, dates, statuses, and correction rules are independent. The design question is therefore not “which field should fill the invoice?” but “which fact is being expressed, where is its authoritative source, and what must block the process when it is missing?”
Scenario 1: payment happens before delivery
An advance can create cash and a commercial obligation before performance. Some jurisdictions also require a tax invoice for the advance. The later delivery and final settlement remain separate events. Indonesia is a useful illustration: the tax authority explains Faktur Pajak for advances or instalments, so the commercial reference, official tax number, payment date, and delivery date need not be the same.
Scenario 2: billing and goods movement happen at different times
Future delivery exposes the separation most clearly. A business can agree the sale and issue a billing or fiscal document before goods move; the actual dispatch later creates another logistics and possibly tax event. Official guidance from Goiás, Brazil, describes a simple-billing NF-e followed by another NF-e at actual goods movement. Payment may also precede delivery.
Scenario 3: one transaction is fulfilled or settled in parts
One order can lead to several deliveries, milestone acceptances, billings, payments, and statutory invoices. Conversely, one settlement document can summarize several performance events. The relationship is often many-to-many, not one-to-one. Partial delivery, milestone services, progress billing, retention, and final settlement must preserve their own quantities, amounts, dates, and references.
Scenario 4: the business document exists before the legal invoice
A source billing record can exist while the statutory platform still shows draft, processing, rejected, or accepted. Legal issuance is determined by the applicable rule and authority response, not by the mere existence of a PDF. Malaysia illustrates this with MyInvois validation; India illustrates it with IRP registration and IRN. Platform acceptance does not mean the customer has paid or the goods have moved.
Scenario 5: invoice registration and transport are separate
For physical goods, the tax document and the transport document can be linked but remain different controls. India's IRN and e-Way Bill show this distinction: invoice registration and authorization or evidence for goods movement are not the same status.
Scenario 6: legal data, channel, and readable view are different layers
A structured invoice can be transmitted by email, Peppol, a portal, or another agreed channel and rendered as a PDF for people. Germany is a useful example: structured data is central to the e-invoice, while the transmission path and readable view are separate layers. Changing the channel or rendering does not change the underlying legal fact.
Scenario 7: corrections must preserve history
Once a statutory invoice has been accepted, a return, price change, cancellation, or correction should create an explicit linked adjustment according to local rules. It should not silently rewrite the original number, authority timestamp, amount, or status. The source transaction, original official document, correcting document, goods return, and cash refund each retain their own evidence.
Country differences are implementations of the same underlying problem
Countries differ in trigger points, platforms, identifiers, formats, and correction documents. The underlying problem is consistent: determine which business fact has occurred, record it at one authoritative point, connect it to the other facts, and block statutory processing when required data is missing or conflicting.
What a global system should retain
A robust system separately stores performance dates and quantities; billing number, amount, currency, due date and clearing; official e-invoice identifier and authority timestamps; transport references where applicable; and original-to-correction relationships. Each chain owns its status and failure handling. Readiness must validate the exact authoritative data that the statutory output will consume, without silently guessing from another field.
The hard part of e-invoicing is therefore not converting PDF to XML. It is preserving the meaning of performance, settlement, and tax facts across scenarios while keeping them reconcilable.
Official country references
- Indonesia: advance and settlement Faktur Pajak
- Brazil (Goiás): future delivery billing and goods movement
- India: Invoice Registration Portal FAQ
- Malaysia: MyInvois FAQ
- Germany: Federal Ministry of Finance e-invoice FAQ
Country rules evolve. Confirm the applicable scope and tax interpretation with official guidance and local advisers.