Understand Factur-X, electronic invoicing and mandatory customer data

Understand the different stages

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 records 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 the selected invoice and note the page or visual zone. If a genuine CrossIndustryInvoice file is obtained, fill the XML column from that file. Otherwise leave it unavailable and record the exact blocker. Add a source-data column pointing to the Tempolia record that should feed each value: issuing company, selected customer record, sales code, VAT code, invoice line, payment terms or model.

When retrieval fails, an explicitly unavailable XML column is 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 selected 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; for a one-cent difference, check the rounding rule instead of editing the amount.

Find each mandatory value in its Tempolia source

Seller data normally comes from the issuing-company record: legal name, address, country, legal identifiers and VAT number. Buyer data comes from the selected customer: 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 and mark values as present, missing, inconsistent or not applicable. 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.

Where to correct each error

• If seller identity is wrong, stop and ask the person who maintains the company record to correct it through the usual process.
• 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 issued document silently.
• If VAT category is wrong, consult accounting or the person responsible for VAT configuration before reissuing.
• If only transport fails while PDF and XML are coherent, investigate platform routing rather than changing monetary values.

Run the genuine Factur-X technical checks

To repeat the check, start with a prepared invoice generated by an active Factur-X model in dedicated training data in your subscription with the appropriate authorisation. 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 the PDF, XML, history and accounting lines.

If something goes wrong

• No XML link: check the model and generation method before comparing PDF and XML.
• XML cannot be parsed: keep the original file 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: no transmission status is available; check the environment and whether a submission occurred.

Separate document, transport, accounting and settlement controls

Work in order: check the issued invoice and its PDF/XML, validate the XML, read the platform history, then compare the accounting export and payment. Do not carry a status from one stage into another.

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 selected case, complete each stage for which an actual value or status is available and leave the others blank. Fill XML, transmission and later stages only from actual files or status rows. 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. Correct the appropriate source instead of repeatedly modifying the invoice text.