Understand Factur-X, electronic invoicing and mandatory customer data

Understand the evidence layers

The PDF serves human reading; XML serves automated exchange. They must describe identical parties, lines, tax breakdown, totals, currency and due date. Technical validation checks structure and profile; transport history checks submission and returns; payment proves settlement. None replaces another.

Construct the ten-field comparison without inventing the second column

Create a worksheet with one row for invoice number, issue date, currency, seller, buyer, line description, net amount, VAT amount, gross amount and due date. In the PDF column, copy the value exactly as displayed on invoice 18100016 and note the page or visual zone. In the XML column, leave “unavailable on current demo” until a genuine CrossIndustryInvoice artefact is obtained. Add a source-data column pointing to the Tempolia record that should feed each value: issuing company, AGAPE customer record, sales code, VAT code, invoice line, payment terms or model.

The empty XML column is pedagogically useful. It prevents a learner from confusing expected data with observed data and prepares a precise retest. Do not copy PDF values into the XML column, infer them from a caption or use an artificial HTML page. When XML later becomes available, record the element name or XPath and compare semantics, not only visual spelling. A structured identifier can be technically well formed and still refer to the wrong legal party.

Arithmetic control

For the actual EUR 300.00 gross invoice, recover net and VAT from the issued piece rather than assuming a rate. Verify net plus VAT equals gross and reconcile the VAT breakdown to invoice lines. If several VAT categories exist, compare every category separately. Check decimal precision and rounding at line, tax and document levels; a one-cent difference needs a documented rule, not a silent edit.

Trace every mandatory value to its authorised source

Seller data normally comes from the issuing-company record: legal name, address, country, legal identifiers and VAT number. Buyer data comes from AGAPE: legal identity, billing address, country, SIRET, VAT identifier and routing information where applicable. Commercial values come from invoice lines, sales codes and units. Tax category and rate come from the VAT configuration applied to each line. Currency, dates, payment terms and bank references come from invoice and company settings.

Review each source before a prepared retest. Mark values as present, missing, inconsistent or not applicable and assign an owner. A readable PDF may tolerate an omitted structured identifier because a human recognises the customer; automated routing will not. Conversely, a technically populated field is not trustworthy if it was copied into the wrong source solely to satisfy validation.

Source-correction decision tree

• If seller identity is wrong, stop and involve the company-configuration owner.
• If buyer identity or routing is wrong, correct the authorised customer record and preserve the former state.
• If a line or price is wrong before issue, correct the draft source and regenerate.
• If an issued document is wrong, use the approved fiscal correction flow; never replace the retained artefact silently.
• If VAT category is wrong, involve accounting or tax ownership before a new issue.
• If only transport fails while PDF and XML are coherent, investigate platform routing rather than changing monetary values.

Know what a genuine Factur-X technical test must prove

A proper retest starts with a prepared invoice generated by an active Factur-X model in an authorised demonstration environment. Retrieve the final PDF and extract its embedded or associated XML using a genuine application function or recognised extraction tool. Confirm that an XML document exists, that its root and namespace correspond to the supported CrossIndustryInvoice profile and that it passes the applicable syntax or schema validation used by the project. Preserve the original PDF, extracted XML and validation report together.

Technical validity is one layer. Perform the ten-field semantic comparison next, including parties, references, line quantities and units, allowances or charges, VAT breakdowns, totals, currency and payment terms. Then, and only then, test submission through the configured channel and retain acknowledgement and history. The same invoice reference must connect all artefacts.

Failure interpretations

• No XML link: model or generation prerequisite failed; document consistency is unproved.
• XML cannot be parsed: preserve the artefact and validation error; do not rewrite it manually.
• Schema passes but amount differs: structured source or transformation is wrong despite technical syntax.
• PDF and XML match but routing rejects: inspect identifiers, network rules and platform response.
• History is empty: transmission cannot be proved; check environment and whether a submission occurred.

Separate document, transport, accounting and settlement controls

Document generation establishes the invoice artefacts. Semantic comparison establishes that human-readable and machine-readable representations agree. Validation establishes technical structure. Platform history establishes external processing. Accounting export establishes journal translation. Payment and matching establish settlement. A single green status in one layer cannot prove the others.

Build a lifecycle table with columns for invoice issued, PDF retained, XML retained, technical report retained, submitted, acknowledged, accepted or rejected, accounted, paid and matched. For the present demo, complete only what can be observed: 18100016 and its source information. Mark XML, transmission and later stages explicitly according to actual evidence. This makes the gap actionable and prevents false completion.

When a correction is required, identify which layer failed. A missing buyer SIRET is a source-data issue; malformed XML is a generation issue; unknown recipient is often routing; rejected accounting account belongs to export configuration; unpaid balance belongs to customer follow-up. Route the issue to the proper owner instead of repeatedly modifying the invoice text.