A Factur-X example, read field by field

The quickest way to see what a Factur-X invoice must contain is to read one. Below is a complete, valid example at the EN 16931 profile, the CII XML that lives inside the hybrid PDF, walked through field by field: the document header, the two parties, the lines, the VAT breakdown, the totals and the payment terms. Every field carries an official name in the European standard, a BT ("business term") number, and that is how validators and rejection messages refer to it. Download the file, open it in the viewer next to this page, and the format stops being abstract.

The example files, produced and validated with this site's tools:

• facturx-cii-exemple.xml, the XML walked through below;
• facturx-en16931-exemple-facture.pdf, the same kind of invoice as a hybrid Factur-X PDF.

More sample files, including a credit note and a deliberately broken XML for testing, are on the format guide.

The skeleton: one invoice, four zones

A CII invoice (rsm:CrossIndustryInvoice) always has the same shape:

The order matters: in CII the line items come first, the header-level blocks after them. A file that shuffles these blocks fails the schema before any business rule runs.

The profile declaration (BT-24)

<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

The specification identifier, BT-24, says which rulebook the file claims to follow; here the EN 16931 profile, the right default for a B2B invoice to France. A missing identifier fails immediately (rule BR-01), and a MINIMUM or BASIC WL identifier tells the recipient the file carries no line items, not enough for a French B2B invoice.

Number, type and date (BT-1, BT-3, BT-2)

<ram:ID>FAC-2026-0342</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
  <udt:DateTimeString format="102">20260610</udt:DateTimeString>
</ram:IssueDateTime>

BT-1 is your invoice number, in your own series. BT-3 is the document type from a UN code list: 380 is a commercial invoice, 381 a credit note; the code, not the title printed on the page, is what the receiving system books. BT-2 is the issue date; format="102" means YYYYMMDD, the only date format accepted here.

The seller (BG-4)

<ram:SellerTradeParty>
  <ram:Name>Dupont Services SARL</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID>12345678901234</ram:ID>
  </ram:SpecifiedLegalOrganization>
  ...
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="VA">FR12345678901</ram:ID>
  </ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>

Three identifiers do the work. The name (BT-27) is the legal name. The legal registration identifier (BT-30) is the company's registry number; this French seller uses its 14-digit SIRET. The VAT identifier (BT-31) carries schemeID="VA", and rule BR-CO-09 checks that it starts with a country code. The postal address (BG-5) must include the country code (BT-40); a missing CountryID is one of the most common schema failures in hand-built files. As a foreign supplier you fill this block with your own national identifiers and VAT number; nobody expects a French number on the seller side.

The buyer (BG-7)

<ram:BuyerTradeParty>
  <ram:Name>Martin Industries SAS</ram:Name>
  ...
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="VA">FR98765432109</ram:ID>
  </ram:SpecifiedTaxRegistration>
</ram:BuyerTradeParty>

Same structure as the seller. Note what this pure EN 16931 example does not carry: the buyer's SIREN in the legal registration field (BT-47). The European standard leaves it optional; the French business rules layered on top demand it for an invoice to a French company, and its absence is the most frequent rejection reason since September 2026. That is exactly the gap the validator surfaces when you switch the French rules on: this file passes EN 16931 and still needs the buyer's SIREN before a French platform accepts it. The SIREN lookup confirms the number your customer gives you.

The purchase order reference (BT-13) sits right after the parties: CMD-2026-0198 here. Optional in the standard, but your customer's accounts payable matches on it, so carry it whenever you have one.

The lines (BG-25)

Each IncludedSupplyChainTradeLineItem is one invoice line, and each repeats the same five things:

<ram:LineID>1</ram:LineID>
<ram:Name>Conseil en facturation electronique</ram:Name>
<ram:ChargeAmount>110.00</ram:ChargeAmount>
<ram:BilledQuantity unitCode="HUR">12</ram:BilledQuantity>
<ram:LineTotalAmount>1320.00</ram:LineTotalAmount>

In order: the line number (BT-126), the item name (BT-153), the net unit price (BT-146), the quantity with its unit (BT-129 and BT-130), the line net amount (BT-131). The unit code comes from a UN list: HUR is an hour, C62 a plain unit, DAY a day. Each line also declares its own VAT category and rate (BT-151, BT-152): lines 1 and 2 are standard rate S at 20 percent, line 3 is a book at 5.5 percent. The arithmetic is checked per line: price times quantity must equal the line amount, here 110.00 x 12 = 1320.00.

The VAT breakdown (BG-23)

<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>442.00</ram:CalculatedAmount>
  <ram:BasisAmount>2210.00</ram:BasisAmount>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>20</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

One block per VAT rate used on the invoice, two here: 20 percent on a basis of 2210.00 (lines 1 and 2), 5.5 percent on 130.00 (line 3). BT-116 is the basis, BT-117 the tax, BT-118 the category, BT-119 the rate. The rules recompute everything: each basis must equal the sum of the lines at that rate, and each tax amount must equal basis times rate. Rounding per line instead of per rate is the classic way to end up one cent off and rejected. If your invoice carries no VAT at all, this block is where the reason is coded: category AE for reverse charge on a cross-border service to France, with a zero rate.

Totals (BG-22) and payment (BG-16, BT-9)

<ram:LineTotalAmount>2340.00</ram:LineTotalAmount>
<ram:TaxBasisTotalAmount>2340.00</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">449.15</ram:TaxTotalAmount>
<ram:GrandTotalAmount>2789.15</ram:GrandTotalAmount>
<ram:DuePayableAmount>2789.15</ram:DuePayableAmount>

Five figures that must reconcile to the cent: the sum of the lines (BT-106), the taxable total (BT-109), the total VAT (BT-110, which must state its currency), the grand total (BT-112) and the amount due (BT-115). Here: 2340.00 + 449.15 = 2789.15, and 442.00 + 7.15 = 449.15. Above the totals sit the currency (BT-5, EUR), the payment means (BT-81, code 30 for a credit transfer, which makes the IBAN in BT-84 mandatory per rule BR-61), and the payment terms with the due date (BT-20, BT-9).

Read it, break it, validate it

Three ways to make this stick. Open the XML in the viewer and see the same fields rendered as a normal invoice. Run it through the validator twice, once plain and once with the French rules on, and watch the buyer SIREN requirement appear. Then edit a copy, change one line amount without touching the totals, and validate again: the report names exactly the reconciliation you broke. When you are ready to produce your own, the converter builds the same structure from the PDF invoice you already send.

Frequently asked questions

What are the BT and BG numbers used above?

They are the field names of the EN 16931 semantic model: BT is a business term (one field, like BT-1 for the invoice number), BG a business group (a block, like BG-25 for a line). Validators, rejection messages and the standard's documentation all refer to fields this way, which is why they are worth recognising.

Is this example CII or UBL, and does it matter?

CII, the syntax embedded in every Factur-X and ZUGFeRD file. UBL expresses the same EN 16931 model with different tags, and the CII to UBL converter swaps syntaxes without touching the content. The BT numbers are the same in both.

Would this example pass a French platform's checks as it is?

It passes EN 16931, and it is deliberately one step short of the French layer: the buyer's SIREN (BT-47) is not filled. For an invoice to a French business, add the customer's nine-digit SIREN as the buyer's legal registration identifier and state the operation category; the validator with French rules on confirms the rest, check by check.

Where is this XML inside the PDF version?

A Factur-X PDF is a PDF/A-3 with the XML attached inside it under the fixed name factur-x.xml; the PDF page is for people, the XML for systems, and the XML is authoritative. The extraction tool pulls it out of any hybrid file so you can compare the two layers. If a file like this just landed in your inbox from a French supplier, here is what to do with it.

Can I use these files to test my own software?

Yes, that is what they are for: the data is fictitious and every file was validated with the tools on this site. Feed the XML to your parser or your accounts payable import, and use the deliberately invalid sample on the format guide to check that your error handling actually fires.

How do I produce a file like this from my own invoices?

From a PDF, the converter extracts the data and rebuilds it as a valid Factur-X; from scratch, the invoice form asks for each block above in order. Both produce the EN 16931 profile by default, and both end with the same validation this example passes.

Published 30 September 2026. Sources: EN 16931 semantic model and its CII syntax binding (UN/CEFACT), Factur-X 1.07 specification (FNFE-MPE). GetFacturX is not an accredited platform (Plateforme Agréée); transmission over the French network, which foreign suppliers do not need, is operated by an accredited partner platform. This article is not tax or legal advice. Dates, frequencies and amounts are those known at publication and may change; check them before relying on them.