Your customer opens your invoice and finds the amount, the due date and the description of the work in seconds. Their accounting software opens the same file and needs someone to type those details in.
The invoice looks clear. The data is still difficult to use.
A normal PDF is built to preserve a page’s appearance. A person understands its labels and layout. Software may need to extract the text, work out which date means “due date”, and decide whether a number is a subtotal or the amount to pay.
A structured e-invoice gives those fields defined meanings. The receiving system can recognise an invoice number as an invoice number, rather than infer it from a position on a page. That structured exchange is central to the European Commission’s explanation of e-invoicing.
The two approaches can share a file. Factur-X, for example, combines a readable PDF with embedded XML invoice data. The person gets a familiar document; the receiving software gets the fields.
Imagine that invoice carries three dates: when the work happened, when you issued it and when payment is due. Good layout helps the customer tell them apart. Defined fields help the software do the same.
So when a customer asks for an e-invoice, ask which format their system accepts and how it should arrive. Agreeing that detail before the first bill is sent can save both teams another round of re-entering the same information.




