A machine-readable invoice identifies values by their business meaning and places them in a structure the receiving software understands. An ordinary PDF can show a quantity, price and total clearly to a person, yet still leave software to infer which text represents which value. Structured information reduces that interpretation problem when both systems follow compatible rules.
This does not mean that every PDF is unreadable by software or that every XML file is a suitable invoice. A PDF may contain extractable text, and a hybrid invoice may contain embedded structured data. The important question is whether the recipient can identify and process the invoice’s fields according to the expected specification, not whether a computer can open the file.
Read the same line in two ways
Imagine a fictional invoice displaying “12 notebooks at EUR 4.50 each; EUR 54.00 before tax”. A person can infer the relationships from the words and layout. Extraction software might locate all three numbers, but it still needs to distinguish quantity, unit price and line amount. A column heading placed on a previous page can make that inference harder.
A structured representation gives each value a defined role. The quantity is 12, the unit is an appropriate unit value, the unit price is 4.50 and the line amount is 54.00. The currency is recorded explicitly rather than inferred only from a symbol or the customer’s location. A compatible system can use these roles without recreating the page’s visual reasoning.
The first-invoice workflow therefore begins with confirmed information rather than document styling. Clear labels matter before a final structured file is generated, because a mapper cannot reliably recover the intended meaning from vague or misclassified source data.
Distinguish data structure from appearance
A PDF preview is valuable for human review. It helps a reader notice that a company name is wrong, a line description is unclear or the currency differs from the agreement. These are important checks, even when the final output also contains machine-readable data.
However, a visual hierarchy does not specify every relationship needed by an accounting system. A buyer reference printed in a notes paragraph may be obvious to a procurement officer but absent from the field an automated matching process expects. A tax reason shown as free text may need a defined representation in the target profile.
Likewise, a structured file can be readable in a text editor while still using the wrong fields or values. An XML element containing a buyer’s email does not make that email a valid participant endpoint. Software interoperability depends on agreed meaning and rules, not simply the presence of tags around text.
Understand the model, syntax and profile
A semantic model defines what invoice information means. A syntax defines how that information is carried in a message. A profile can constrain or specialise the information required for a particular workflow. Delivery is another layer: it determines how the finished document reaches the intended recipient.
The European Commission’s explanation of EN 16931 distinguishes its semantic invoice model from the specified UBL and CII syntax bindings. That relationship illustrates why asking only for “an XML invoice” leaves important questions unanswered. The version and profile expected by the recipient can affect the actual mapping and validation needed.
Keep these distinctions when asking a customer for format instructions. A system name, delivery network and document format may all appear in one email, but each answers a different question. Record them separately so the person preparing the final output can assess compatibility.
Check extracted and structured values alike
Extraction can help reduce typing, but extracted values remain draft suggestions until reviewed. If an OCR process reads a quantity of 1.5 as 15, a correctly formatted output can still carry the wrong commercial information. Check the source, the mapped field and the resulting arithmetic rather than trusting one successful processing step.
A structured document also needs validation against its intended specification and business rules. A required seller identifier might be absent, a code might be outside an allowed list, or a total might be calculated inconsistently. Being structured makes the data explicit; it does not guarantee that the explicit data is correct or accepted.
Human review remains useful for facts outside a validator’s knowledge, such as whether the customer approved the work or the bank instructions are authentic. Formal checks and commercial review address different failure modes.
Apply this distinction to the current creator
EInvoiceCreator stores labelled invoice fields and calculates supported totals locally. Its JSON export uses the application’s own schema, with an explicit indication that standards validation has not been performed. This is structured application data, not an implemented EN 16931, XRechnung or Peppol export.
The printable output is a readable document produced through the browser. It does not embed hybrid-invoice XML. The CSV contains line items and amounts, which can help with spreadsheet work but do not contain the full seller and buyer invoice record.
Use those outputs for the purposes they actually serve. If a customer requires a recognised structured format, the remaining work includes a suitable mapping, relevant validation and the requested delivery process. A useful preparation record and a clear human preview are starting materials for that process, not evidence that the final standard has already been implemented.