An invoice a person and a machine both read

Produce an invoice a person reads, carrying inside the same file the data accounting reads on its own.

Summary

An invoice has two audiences. A person looks at it and sees the lines, the amounts, the date. Accounting software wants the same figures sorted into boxes, so it can book them without anybody retyping. France is bringing this in for businesses step by step, and to the eye the file stays a perfectly ordinary invoice.

Technically

Written at the top level of a request, under "invoice"

invoice attaches the invoicing XML to the document as an embedded file, associates it through /AF, and states what it is: the profile of the standard it follows, its version, its /AFRelationship to the document, and when the data was last changed. The XML arrives alongside the request, in a form part carrying the name given here. An invoice wants the archiving standard that allows a file to be attached, so the request states "archive": "pdfa3b". The team has fixed the attached file's name at factur-x.xml.

Request schema

  • invoice — object, optional, absent by default.
  • invoice.xml — string, required. The name of the supplied part holding the XML. A name no part carries is refused.
  • invoice.profile — string, required, spelled as the standard spells it. Five values: "MINIMUM", "BASIC WL", "BASIC", "EN 16931", "EXTENDED".
  • invoice.version — string, optional, "1.0" by default. The version of the specification the XML follows.
  • invoice.relationship — string, required, with no default. Five values: source, alternative, data, supplement, unspecified. We write the value you send, unchanged: nothing here compares it with the invoice's profile, so what the file declares itself to be is yours to state and yours to answer for.
  • invoice.issued — string, required, in ISO 8601. When the invoice data was last changed, not when the PDF was created.
  • The request states "archive": "pdfa3b": with no archiving standard the invoice is refused, and under pdfa4 it is refused too, that part taking a file only if the file is itself archival.
  • The attached file is named factur-x.xml.

A whole request that creates a PDF

One name below stands for a font file: put the encoded file in its place, or send the file itself beside the description, as a supplied part of the same call. One page carries a real font already encoded, and its request posts as it stands. 

{
  "archive": "pdfa3b",
  "invoice": {
    "xml": "invoice_xml",
    "profile": "MINIMUM",
    "relationship": "data",
    "issued": "2026-08-08T09:30:00+02:00"
  },
  "output_intent": { "identifier": "sRGB", "info": "sRGB IEC61966-2.1" },
  "metadata": {
    "title": "Invoice 2026-014",
    "created": "2026-08-08T09:30:00+02:00"
  },
  "fonts": [{ "name": "body", "data": "PASTE_THE_FONT_FILE_BASE64_HERE" }],
  "items": [
    {
      "type": "text",
      "rect": { "llx": 60, "lly": 740, "urx": 535, "ury": 768 },
      "content": ["Invoice 2026-014 — total 5 100.00 EUR"],
      "font": "body",
      "font_size": 16
    }
  ]
}

The line that sends it, in three languages

The document as a whole

The numbers reading software shows A hundred letters in a single file What the document says about itself What the document says about itself, said once The notes a program leaves in the file for itself The notes a program leaves on one page The data a program hangs on a run of ink A file still readable decades from now The print standard the document claims The password that opens it, and what may be done with it The address relative links are read against The PDF version the file declares What a picture says about itself, and how it is read The attachments the document carries beside its pages The attachments shown as a portfolio Which attachments a page claims The identity card a single page carries The accessibility standard the document claims The standards the finished document is measured against

Where to go next

Every JSON key of a request, in one page The other forty-one settings of a request

See the prices See the examples