France, 1 September 2026: every French VAT-registered business must be able to receive e-invoices.

EN 16931 errors that tell you what to change

Your customer's German portal rejected the invoice with [BR-DE-15]-Das Element „Buyer reference“ (BT-10) muss übermittelt werden. Attestwire returns the rule, the business term, what the regulation requires, and the field to set, as JSON, in English. Open source, MIT, zero dependencies, or a hosted API with 100 documents a month free.

{
  "rule": "BR-DE-15",
  "field": "BT-10",
  "severity": "fatal",
  "message": "XRechnung requires a buyer reference (BT-10). For German public-sector buyers this is the Leitweg-ID; business buyers may supply any reference, but the field must be present.",
  "fix": "Ask your client for their Leitweg-ID (public sector) or an order/customer reference, and set buyerReference.",
  "example": "\"buyerReference\": \"04011000-1234512345-06\"",
  "xpath": "/ubl:Invoice/cbc:BuyerReference",
  "docsUrl": "https://attestwire.com/rules/BR-DE-15"
}

A Schematron failure tells you which assertion tripped. It does not tell you that the thing it wants is a number only your customer can give you.

import { validateInput,
         generateXRechnungUBL }
  from "@attestwire/en16931";
const { valid, errors } =
  validateInput(invoice);
const xml =
  generateXRechnungUBL(invoice);

curl -sX POST \
  -H content-type:application/json \
  -d '{"email":"you@example.com"}' \
  https://api.attestwire.com/v1/keys

Why this isn't a weekend job

Take the rejection at the top of this page. Everything you need is missing from that sentence. It does not tell you that BT-10 is the Leitweg-ID. It does not tell you that the Leitweg-ID belongs to your customer, not to you. So it does not tell you that the fix is an email, not a code change. The knowledge lives in a 200-page standard, a national CIUS, and one portal's habits. That is the part Attestwire has already done: 251 rules you can break, each with a page, an error payload, and a fix.

Run it in your own process — no account, no network call

@attestwire/en16931 is an open-source TypeScript implementation of the EN 16931 semantic model and its national restrictions. JSON in, conformant XML out — or an invoice in, a list of teaching errors out. It makes no network calls and needs no account, so it runs anywhere JavaScript runs. Generation targets XRechnung UBL and Peppol BIS today. There is no Factur-X or CII generation, and credit notes are not built yet. Validation covers the CII and Factur-X profiles as well, but it reads your JSON, not an XML file you already have.

published, still 0.x · v0.2.0 On npm and on GitHub. The shapes below are the shipped shapes.

npm install @attestwire/en16931

npm · GitHub · MIT licence

Here is the call that produced the error at the top of this page. The object is a complete, conformant XRechnung with one field taken out, so its length is information in itself: this is what the German CIUS actually demands.

import { validateInput } from "@attestwire/en16931";

const result = validateInput({
  profile: "xrechnung-ubl",
  invoiceNumber: "2026-000142",
  issueDate: "2026-08-09",
  currency: "EUR",
  invoiceTypeCode: "380",
  seller: {
    name: "Acme GmbH",
    vatId: "DE123456789",
    address: {
      line1: "Chausseestr. 1",
      city: "Berlin",
      postalCode: "10115",
      countryCode: "DE",
    },
    electronicAddress: { schemeId: "0204", value: "04011000-1234512345-06" },
    contact: {
      name: "Buchhaltung",
      phone: "+49 30 1234567",
      email: "rechnungen@acme.example",
    },
  },
  buyer: {
    name: "Stadt Bonn",
    vatId: "DE987654321",
    address: {
      line1: "Berliner Platz 2",
      city: "Bonn",
      postalCode: "53111",
      countryCode: "DE",
    },
    electronicAddress: { schemeId: "0204", value: "04011000-1234512345-06" },
  },
  lines: [
    {
      id: "1",
      description: "Consulting, August 2026",
      quantity: 10,
      unitCode: "HUR",
      unitPrice: 150,
      vatCategory: "S",
      vatRate: 19,
    },
  ],
  payment: {
    meansCode: "58",
    iban: "DE02120300000000202051",
    accountName: "Acme GmbH",
  },
  paymentTerms: "30 days net",
});

result.valid;      // false
result.errors[0];  // the object below

Every field in that error is load-bearing. rule and field are the identifiers your customer's tax adviser and their portal's rejection notice will use. message states the requirement, fix states the action, xpath points at the element in the generated document, and docsUrl resolves to a page on this site. It is the same URL whether the error surfaced in your CI, in a log line, or inside an agent's tool call.

251 rules are implemented and documented, across EN 16931 core, the German XRechnung CIUS and Peppol BIS 3, and every one of them is a rule your own invoice can break. A further 40 constrain the arithmetic this library performs for you — the VAT breakdown, the document totals, the line net amount — and no input can reach them, so they are counted separately and their pages say plainly that a finding there would be our bug.

That is the reference set: every rule of EN 16931, the XRechnung CIUS and Peppol BIS 3 that the JSON input model can express. What is left out is a list rather than a fraction, and it is published in full: validating XML you already have, credit notes, any Factur-X or CII output, the rules the generator controls, and four the reference schematron binds to true() and therefore does not test either. Read the list before you commit to us. Browse the reference too: each page says where our check is stricter or looser than the published one, so you can calibrate against us instead of guessing. Ask any compliance vendor for their equivalent list.

Or skip the install and call the API

Same engine, behind an HTTP endpoint, for when you would rather not run validation inside your own stack. Post an invoice, get back the XML or the teaching errors. The free tier is open right now: 100 documents a month, no card, one key per email address. Paid plans are $49 for 2,500/mo and $199 for 25,000/mo. The pricing page says which one fits you and what happens when you hit a limit.

curl -X POST https://api.attestwire.com/v1/keys \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com"}'

curl -X POST https://api.attestwire.com/v1/validate \
  -H "authorization: Bearer $ATTESTWIRE_KEY" \
  -H 'content-type: application/json' \
  -d @invoice.json

That answers with { "valid": false, "profile": "xrechnung-ubl", "errors": [ … ], "warnings": [] }, and the objects in errors are the same TeachingErrors as the library's: same rule, field, message, fix, example, xpath, docsUrl. The API passes your payload to the same function you would call locally and returns its result verbatim. The hosted API is not a different product; it is the same code behind an HTTP endpoint.

Full reference, the invoice model and the error catalogue: https://api.attestwire.com/docs.

The details, so nothing surprises you: quota is documents per calendar month, counted per key, resetting at 00:00 UTC on the 1st. A refused call does not consume a document. Upgrades run through Stripe-hosted Checkout: POST /v1/billing/checkout returns the URL to redirect to. Cancel any time in the billing portal, effective at period end. Full pricing and FAQ.

Three things to read before you integrate. Invoices are processed in memory and never stored (security). The terms spell out that this is a technical conformance check and not a compliance guarantee. And a GDPR Art. 28 DPA is available: email us your company details and it is in place.

Need more than 100 a month?

Upgrade yourself on the pricing page: one form, your API key, done. Above 25,000, email hello@attestwire.com and a person answers.

If Attestwire stops, your build doesn't

The library is MIT-licensed and on npm. The version you depend on keeps working offline, with no account and no calls home, and anyone can fork it. The hosted API runs the same code, so migrating off it is swapping an HTTP call for a function call. If the API is ever discontinued, every account gets at least 60 days' notice, and that is in the terms rather than a promise on a page. More on how this is built and run → about Attestwire.

Where Attestwire stops and your access point starts

Attestwire doesn't transmit invoices, and won't. No Peppol access point, no French PDP, no KSeF connection — that is a regulated, capital-intensive business with different economics. We build and check the document; your access point moves it. The library's output is shaped to hand straight to one, so this is a clean seam rather than a gap.

Two free tools you can use right now, no signup

They have plain functional names because most people arrive at them from a search engine mid-problem, not from this page.

• French E-Invoicing Checker live Look up any French company and find out whether it is registered with an approved e-invoicing platform in the official DGFiP directory. Every step is explained in English, because the directory itself is not.
• Is VIES Down? live When a VAT lookup fails, this tells you whether it was you or them. All 28 member state endpoints (27 plus Northern Ireland), polled every five minutes, with per-country uptime, latency and an error breakdown. Free badges and open JSON at /api/status.json, with no key. It exists because we needed it, and it is unrelated to buying anything. To be clear about what it is not: it does not validate VAT numbers for you, it tells you whether VIES can. Our own uptime is at status.attestwire.com.

The dates you're building against

Here is the calendar, so you can size the work. It is a calendar, not a countdown; nobody here benefits from you panicking in August. France is the near one: from 1 September 2026 every French VAT-registered business has to be able to receive e-invoices, with no size test, and issuing phases in for large and mid-size firms from the same date. If you are on the receiving side, Attestwire validates Factur-X and XRechnung CII today, and the free French E-Invoicing Checker tells you whether a given customer is registered on an approved platform. Verify any of these against the primary source. These dates have moved before, and they may again.