E-invoicing with a PDP or conversion service

1. A conformant container — a PDF/A-3 with embedded fonts and the attachment slot. This is Forme’s half, verified by veraPDF in CI.
2. Standards-compliant invoice XML — the EN 16931 semantic model, its ~170 business terms, and the several hundred business rules over them. This half comes from a PDP (in France, a Plateforme de Dématérialisation Partenaire), an e-invoicing service, or your own EN 16931 implementation.

​

The pipeline

your invoice data
      │
      ├──────────────► EN 16931 semantic model (JSON or CII XML)
      │                        │
      ▼                        │
Forme renders PDF/A-3b         │
(fonts embedded,               │
 veraPDF-checked locally)      │
      │                        │
      ▼                        ▼
   POST multipart: pdf + invoice ──► conversion service ──► Factur-X
                                                              │
                                                              ▼
                                            verify: veraPDF (PDF/A-3b)
                                                  + Mustang (EN 16931)

​

Step 1 — map your data to EN 16931

• process_control.specification_identifier (BT-24): the literal urn:cen.eu:en16931:2017, naming which rule set the invoice claims.
• A VAT breakdown by rate (BG-23): taxable amount, tax amount, and category code per rate. A display total like “tax: 863.75” is not enough; the standard wants the rate-by-rate decomposition so the receiver can reconcile it.
• A VAT category code per line (BT-151): S for standard rate, E exempt, and so on — per line, not per invoice.
• Structured party identifiers: country codes on every address, and a seller identifier the buyer can resolve (BR-CO-26 requires BT-29, BT-30 or BT-31 — a registration or VAT identifier, not just a name).

​

The jurisdiction layer

• Seller SIREN, exactly 9 digits (BR-FR-10), and a buyer electronic address for routing (BR-FR-12) — the example uses the SIREN with EAS scheme 0002 for both parties.
• Three mandatory notes (BG-1) with subject codes: late-payment penalties (PMD), the statutory €40 recovery indemnity (PMT), and the early-payment discount mention (AAB) (BR-FR-05). French invoices carry these sentences by law; the standard makes them data.
• A billing-mode code in process_control.business_process_type (BR-FR-08), B1 for ordinary goods invoicing.
• VAT rates from the French rate list (BR-FR-16) — the schematron rejects a rate that is not an actual French rate, so a demonstration invoice with US sales tax cannot pass a French pipeline. The example invoice is accordingly a French one, 20% VAT, with the PDF and the XML agreeing — a hybrid invoice whose two halves disagree is worse than either half alone.

​

Step 2 — render the PDF/A-3b

import { renderHtml } from '@formepdf/html';
import { standardFonts } from '@formepdf/fonts-standard';

const fonts = standardFonts().map((f) => ({
  family: f.family, data: f.src, weight: f.fontWeight,
  italic: f.fontStyle === 'italic',
}));

const { pdf } = renderHtml(invoiceHtml, { pdfA: '3b', fonts, lang: 'fr' });

pre-flight: veraPDF PDF/A-3b PASS

​

Step 3 — the conversion call

const form = new FormData();
form.append('invoice', new Blob([invoiceJson], { type: 'application/json' }), 'invoice.json');
form.append('pdf', new Blob([pdf], { type: 'application/pdf' }), 'invoice.pdf');

const res = await fetch(
  `${BASE}/v1.beta/invoices/convert?from=en16931&to=factur-x`,
  { method: 'POST', body: form, headers },   // headers: Authorization if your service needs it
);

if (!res.ok) {
  const { message } = await res.json();      // 400/500: { http_status_code, message }
  throw new Error(`conversion failed: ${res.status} — ${message}`);
}
const facturX = Buffer.from(await res.arrayBuffer());

​

Step 4 — verify what came back

returned file: veraPDF PDF/A-3b PASS
returned file: Mustang (Factur-X / EN 16931) PASS

​

Alternatives, honestly

• A PDP or e-invoicing API (as here): the service owns the XML generation and the regulatory keep-up. In France this is the mandated direction of travel anyway — invoices flow through a PDP.
• An EN 16931 library or service that only does XML — several exist across ecosystems (Mustangproject itself generates as well as validates, on the JVM). You then hold the XML and can use Forme’s one-pass embedding with no second service.
• In-house EN 16931 — a real project, not a weekend: the semantic model, the CII or UBL serialization, and ongoing schematron maintenance as the rule sets revise. Teams with heavy invoice volume and existing standards expertise do it; most don’t need to.

​

What Forme does and does not do