Foundations / Guide

What is electronic invoicing?

How a structured e-invoice differs from a digital document and what happens between sender and recipient.

Electronic invoicing, in plain terms

Electronic invoicing is the exchange of invoice information in a structured electronic format that a receiving system can process. The key difference is not that a document was made on a computer. It is that the invoice has identifiable data fields, such as the seller, buyer, invoice number, lines, tax information and amounts, and that those fields can move between systems without relying on a person reading the page.

In the EU public procurement context, the European Commission describes an eInvoice as issued, transmitted and received in a structured format that allows automatic electronic processing. Other markets may use different formats and exchange arrangements, so the practical definition must be read alongside the relevant local rules.

What does not automatically count as a structured e-invoice?

A PDF generated by accounting software and attached to an email is a digital invoice, but the recipient may still need to read it, extract values or type them into another system. A scanned paper invoice has the same limitation. Optical character recognition can help capture values, yet extraction is a separate process and is not equivalent to sending an agreed structured payload.

A supplier portal can be part of an e-invoicing workflow when it creates structured data for the recipient. The visible form is only the entry method. The question is what the receiving system gets and can process. See the structured invoice and PDF comparison for a decision table.

Who participates in the exchange?

The supplier creates and sends the invoice. The buyer receives it and may match it to an order, receipt or contract before approval. Accounting or ERP systems hold the source and destination records. A service provider or exchange network may transform, validate, route or deliver the data. In some jurisdictions, an authority-facing platform or reporting process is also involved.

The same organisation may use different routes for different customers. A public buyer, a large private buyer and a small trading partner may each specify a different channel or profile. Format, transport and legal obligation are separate decisions.

What happens after the invoice is created?

A typical route is creation, field mapping, validation, addressing, transmission, receipt and processing. It does not end when the sender's software says “sent.” A message may reach a network but fail a buyer-specific rule, or arrive at the buyer yet wait for approval. The exchange overview shows the basic sequence; the detailed exchange guide explains statuses and exceptions.

  • Create the invoice from the underlying business transaction and verify its source data.
  • Map fields into the agreed semantic model and file syntax.
  • Check required content, calculations, identifiers and recipient rules.
  • Transmit by the channel the recipient accepts and retain traceable references.
  • Observe delivery, rejection, approval and reconciliation as distinct outcomes.

Why do businesses adopt it?

Structured data can reduce re-entry, make validation earlier and make high-volume processing more consistent. Those benefits depend on clean source data, compatible systems and a process for exceptions. E-invoicing does not by itself guarantee payment, remove the need for controls or make every trading partner follow the same workflow.

What should a business check first?

Start with the transaction: who is invoicing whom, in which jurisdictions, and through which buyer relationship? Ask the recipient what format and channel it accepts. Inventory your invoice fields, ERP capabilities and current rejection reasons. Then check the relevant authority's current requirements. The ERP integration checklist turns those questions into a project sequence, while the jurisdiction research page explains how to verify local rules.

Requirements and technical specifications vary by jurisdiction and use case. Verify current details with the relevant official source and trading partner.

Primary sources and further reading

These official resources support the standards and regulatory context. Check their current versions before implementation.