Factur-X, UBL and CII: understanding invoice formats

The hybrid standard uses a PDF/A-3 containing an XML file. The visual representation serves the reader; structured data supports automation. Profiles provide different levels of detail. The vendor and platform should confirm the profile and data required for your use.

A credit note must remain linked to its original invoice and consistent with structured data. Teaching example: a service is invoiced and later partly credited. We check the original reference, amounts, VAT and recipient, followed by returned status and accounting entry.

Acceptance testing checks document, data, technical rules and process. We separate these four checks to identify an anomaly’s cause precisely.

The difference concerns data structure and software readability. XML means extensible markup language. UBL means Universal Business Language; CII means Cross Industry Invoice. Factur-X combines a PDF representation and a CII XML file. We ask the vendor which format and profile the actual process accepts.

An ordinary PDF contains a visual representation, not necessarily the required structured data. Character recognition can help read a document but does not, alone, turn an emailed file into a regulatory process. We distinguish document, data and transmission. This avoids judging compliance from appearance alone.

Checks cover party identity, references, dates and amounts. SIREN identifies a French business using nine digits; SIRET identifies an establishment using fourteen. We distinguish legal entity, establishment and process recipient. A similar legal name is insufficient to assign an invoice to the right counterparty.

VAT must be consistent with lines and totals. We compare net amounts, tax and gross total. For a credit note, check the original invoice reference and correction direction. Rounding and discounts should be tested against the format’s business rules rather than changed arbitrarily to obtain validation.

Checks retain references needed for accounting reconciliation and payment. Ask how they travel between ERP, approved platform and accounting software. A technically accepted file may remain difficult to use if purchase-order or invoice references disappear. We include this requirement in the acceptance scenario.

An invoice must be structured and delivered to the correct recipient through the required process. The approved platform (PA), formerly called PDP, performs regulatory functions; PDP meant plateforme de dématérialisation partenaire. The public invoicing portal (PPF) provides directory and data-concentration functions. The electronic invoicing address serves routing beyond an email contact.

The test follows an invoice from the source tool to a response finance can use. We check recipient, status and retained references. For a rejection, the procedure specifies where to correct and how to retry without duplication. A file in an export folder does not demonstrate receipt or reconciliation.

Formats do not change a transaction’s tax scope. A B2C sale or international transaction may fall within e-reporting, while payment data has its own conditions. File, flow matrix and calendar must therefore be tested together. We avoid treating all documents as domestic B2B invoices.

Acceptance testing associates an expected result with each file and retains the actual outcome. We recommend a simple invoice, credit note, deposit and rejection as relevant. Record format, profile, tool version and test date. The record should allow replay after a connector or configuration change.

Finance validates business consistency; the vendor confirms technical capabilities and accepted formats. We connect these checks in the test record, with anomalies and resolutions. A PDF screenshot can complement the record but does not replace XML checks or the platform response.

The final test concerns team autonomy. An operator must identify a rejection, locate the source and retain correction evidence. We recommend attaching the procedure to the acceptance record. The control then remains usable during closing, absence or a change of software contact.

The accounting return must preserve counterparty identity, invoice reference and reconciliation amounts. We recommend following a test invoice through to its display in the accounting tool. Check that the viewable document matches imported data. Platform acceptance does not demonstrate that your environment retains information needed for matching. Record which reference links the source invoice, transmitted invoice, accounting entry and eventual payment, so finance can follow one transaction rather than four disconnected records.

A credit note must reach the correct invoice and entity. A partial payment must be explainable without changing the original sales amount. We test document transmission and reconciliation separately. Retain references before and after tool processing to locate breaks in ERP, connector or accounting import. Where the returned file omits a useful reference, ask the vendor whether configuration or mapping can preserve it before accepting manual rework as the operating solution.

The control procedure must remain readable to finance. It describes the expected document, essential data and action when a reference is missing. We recommend keeping teaching examples separate from actual documents and retaining the company’s test record. This makes controls easier to resume during closing, after configuration changes or when contacts change. A reproducible check should state where the evidence is stored and how a later operator can replay the same scenario.